4-bytes Autonomous System Number

Last week I received a form from APNIC with a new AS numbers. When I had a look through papers I saw there something strange: AS 123456 (I replaced the original with this number). 6 digits. First I thought that there is a mistake or something, then I recall the new 4-bytes ASN. If for IPv6 the things seems to be moving slower, than for the new format of AS numbers, it seems that the things are going faster. So faster that by January 1, 2010 all BGP speaker must support this feature, according to Cisco. I didn’t understood if they refer in the document for their products or it is something that is mandatory globally. No matter how, the things are moving quite fast in this direction.

Since I have to implement a BGP configuration with this 4-Bytes ASN, I started to search with Google friend about the standards and I was surprised that there is not to much to search after. Of course there is the official RFC, some other documentation, but not real examples how to configure, troubleshoot and so on. That’s why I said it’s nice to put something together for a general understanding of what is and how does it work this 4-Bytes ASN. I assume here that reader has a basic understanding of what ASN and BGP is.

RFC 4893 is the reference for “BGP Support for Four-octet AS Number Space”. Currently the Autonomous System number is encoded as a two-octet (2-bytes) entity in BGP, meaning 16bits and this was defined in RFC 4271. The new system is using a four-octet (4-bytes) , meaning 32bits. Currently the ASN 2-bytes include a range from 1 – 65535, used in decimal plain text when configuring the BGP. The expansion from 2-bytes to 4-bytes give us 4,294,967,295 AS number which can be written in ASPLAIN or ASDOT format.

Why two formats? Mainly due to different opinions about how the 4-bytes number should be represented:

ASPLAIN representation

The RIPE NCC assigns and registers 4-byte AS Numbers in ASPLAIN format.
ASPLAIN defines the 4-byte AS Number as a basic 32-bit integer.
“2-byte only AS Numbers” refers to AS Numbers in the range 0 – 65535
“4-byte only AS Numbers” refers to AS Numbers in the range 65536 – 4294967295”
“4-byte AS Numbers” refers to AS Numbers in the range 0 – 4294967295
Advantages:
– IETF preferred notation
– continuation on how a 2-Byte AS number has been represented historically
– does not break AS-PATH REGEX
– APNIC reached consensus to adopt ASPLAIN for assignment and representation of 4-byte AS Numbers
– routers vendors appear to be supporting ASPLAIN, which will require no conversion from allocation to configuration
Disadvantages:
– long number to remember
– All existing 4-byte only assignments have been made in ASDOT

ASDOT representation

The full binary 4-byte AS number is split two words of 16 bits each. It is proposed to identify 4-byte AS Numbers using a syntax of <high
order 16 bit value in decimal>.<low order 16 bit value in decimal>:
“2-byte only AS Numbers” refers to AS Numbers in the range 0 – 65535
”4-byte only AS Numbers” refers to AS Numbers in the range 1.0 – 65535.65535
“4-byte AS Numbers” refers to AS Numbers in the range 0.0 – 65535.65535
Advantages:
– easy to read and remember
Disadvantages
-require conversion from ASPLAIN to ASDOT
-hard for regular expressions

What’s happening if in a BGP peering one router supports the new format and the other one only the old one.  The new reserved ASN 23456 is used for backward compatibility between 4-bytes and 2-bytes BGP speakers. So, if your router advertise BGP with a 4-bytes as number (doesn’t matter in which representation ASDOT or ASPLAN), the peer which does not support the new format, will translate the 4-bytes ASN into 2-bytes ASN 23456. A graphical representation of the AS path from 4-bytes to 2-bytes in BGP would be:
4bytes-2bytes-as

OK, I hope you understand the basics of 4-bytes ASN. For me, some challenge was to understand to transform the 4-bytes ASN from ASPLAIN to ASDOT. In every document that I saw on the Internet there was the same example: AS 65546 in ASPLAIN is 1.10 in ASDOT, but without no explanation. See below how I understood that the conversion takes place. If I understood it wrong, please let me know, to correct it here. After all I’m not an 4-byte ASN expert, I just try to help as much as I can.

So let’s take the number 65546.

1. 65546 / 65535 = 1 (integer) which will be the parte in front of the . (dot) in ASDOT representation.

2. 65546 – ( 65535 * 1) = 11 (see how much rest remains after 65353 going once in 65546)

3. 11 – 1 = 10 which will be the part after . (dot)

4. You obtain 1.10

As a general rule, you have an ASPLAIN number. You take 65535 and see how many times it goes, with integer in the ASPLAIN number (1 time, 2 times, 3 times…depending). This will be your decimal number before dot in ASDOT format . Then you multiple the 65535 with the integer obtained in the first step and you deduct from the ASPLAIN number. From the rest after the second operation, you deduct the the decimal you have in front of the dot. The rest in decimal that comes after the dot .

What confused me is that the number in the example was so close to the last 2-bytes ASN which is 65535.

Now for the last example, let me take a random higher number 194534 (the example from the first line) and to obtain the ASDOT format.

1. 194534 / 65535 = 2 (integer)

2 194534 – ( 65535 * 2) = 194534 – 131070 = 63464

3 63464 – 2 = 63462

4 ASDOT = 2.63462

An online converter from ASPLAIN do ASDOT you can find here: http://as4.nullroute.se/index.php

For some more detailed explanation I would like to ask you to download the Cisco and Juniper documents regarding 4-bytes ASN implementation in BGP.

If you have any useful information about this topic or if something is wrong in my post, please comment and share your knowledge.

Cisco Security Advisory: Cisco IOS XR Software Border Gateway Protocol Vulnerabilities

Official document on Cisco Security Advisory website

Summary

Cisco IOS XR Software contains multiple vulnerabilities in the Border Gateway Protocol (BGP) feature. These vulnerabilities include:

Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update.

The vulnerability manifests when a BGP peer announces a prefix with a specific invalid attribute. On receipt of this prefix, the Cisco IOS XR device will restart the peering session by sending a notification. The peering session will flap until the sender stops sending the invalid/corrupt update. This vulnerability was disclosed in revision 1.0 of this advisory.

Cisco IOS XR BGP process will crash when sending a long length BGP update message.

When Cisco IOS XR sends a long length BGP update message, the BGP process may crash. The number of AS numbers required to exceed the total/maximum length of update message and cause the crash are well above normal limits seen within production environments.

Cisco IOS XR BGP process will crash when constructing a BGP update with a large number of AS prepends.

If the Cisco IOS XR BGP process is configured to prepend a very large number of Autonomous System (AS) Numbers to the AS path, the BGP process will crash. The number of AS numbers required to be prepended and cause the crash are well above normal limits seen within production environments.All three vulnerabilities are different vulnerabilities from what was disclosed in the Cisco Security Advisory “Cisco IOS Software Border Gateway Protocol 4-Byte Autonomous System Number Vulnerabilities” on the 2009 July 29 1600 UTC.

Affected Products

The “Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update” vulnerability affects all Cisco IOS XR Software devices after and including software release 3.4.0 configured with BGP routing.

The other two vulnerabilities affect all Cisco IOS XR Software devices configured with BGP routing.

Workarounds

Cisco IOS XR Software will reset a BGP peering session when receiving a specific invalid BGP update.
There are no workarounds on the affected device itself. Co-ordination is required with the peering neighbor support staff to filter the invalid update on their outbound path. The following procedure explains how to help mitigate this vulnerability:

Using the peer IP address in the log message that was generated when the Cisco IOS XR Software device received the invalid update; capture the notification message hex dump from the CLI command show bgp neighbor and contact the Cisco TAC, who can assist with a decode. Details on how to contact Cisco TAC are contained within the “Obtaining Fixed Software” section of this advisory.

For illustrative purposes, the following example shows a log message generated by an affected device when it receives an invalid/corrupt update message:

RP/0/RP0/CPU0:Aug 17 13:47:05.896 GMT: bgp[122]: %ROUTING-BGP-5-ADJCHANGE : neighbor 192.168.0.1 Down - BGP Notification sent: invalid or corrupt AS path

These details can be captured and provided to Cisco TAC to decode the update message. show bgp neighbors [ip address of neighbor from above log message]:

RP/0/RP0/CPU0:CRS#show bgp neighbors 192.168.0.1        

<capture output and provide to Cisco TAC>

Working with Cisco TAC, the decode of the above will display the AS path in a manner illustrated below.

ATTRIBUTE NAME:  AS_PATH

 AS_PATH: Type 2 is AS_SEQUENCE
 AS_PATH: Segment Length is 4 (0x04) segments long
 AS_PATH: 65533  65532 65531 65531

Working cooperatively with your peering partner, request that they filter outbound prefix advertisements from the identified source AS (in this example 65531) for your peering session. The filters configuration methods will vary depending on the routing device operating system used. For Cisco IOS XR Software the filters will be applied using Routing Policy Language (RPL) policies or with Cisco IOS Software via applying route-maps that deny advertisements matching that AS in their AS-PATH. Once these policies are applied, the peering session will be re-established.

For further information on Cisco IOS XR RPL consult the document “Implementing Routing Policy on Cisco IOS XR Software” at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699.

For further information on Cisco IOS route maps with BGP, consult the document “Cisco IOS BGP Configuration Guide, Release 12.4T” at the following link: http://www.cisco.com/en/US/docs/ios/12_2sr/12_2srb/feature/guide/tbgp_c.html.

Cisco IOS XR BGP process will crash when sending a long length BGP update message
While the long length BGP update message can be caused by any number of attributes, then most common would be the AS Path. Limiting the number of AS numbers in the AS Path Attribute should mitigate this vulnerability. The following shows an example of filtering on AS paths within Cisco IOS XR Software:

route-policy maxas-limit
# Check number of AS Numbers in AS Path attribute.
# If greater than 100 drop the update.
# If less than 100 pass the update.
  if as-path length ge 100 then
        drop
  else
        pass
  endif
end-policy

router bgp 65533
 neighbor 192.168.0.1
  remote-as 65534
   address-family ipv4 unicast
     policy maxas-limit in
     policy maxas-limit out

For further information on Cisco IOS XR RPL consult the document “Implementing Routing Policy on Cisco IOS XR Software” at the following link: http://www.cisco.com/en/US/docs/ios_xr_sw/iosxr_r3.0/routing/configuration/guide/rc3rpl.html#wp1118699.

Cisco IOS XR BGP process will crash when constructing a BGP update with a large number of AS prepends
There is no workaround for this vulnerability, other than reducing the number of AS path prepends configured within Cisco IOS XR.

I must admit that after reading the document above, a big question sign appeared in my head about the BGP functionality on IOS XR and if we can rely on this in a working environment. I’m sure that Cisco will mitigate this issues as the currently workarounds are just a temporary solution.

Juniper Training … Get a Free First Look

Today in the morning, I received a notification in my Inbox about a new person following  me on Twitter. As I took a look on Jonah Manning’s (that’s the name of the person following me) twitters, one subject caught my attention immediately: “Training … Get a Free First Look”.

I followed the link and this lead me to an document (http://forums.juniper.net/t5/Networking-Now/Training-Get-a-Free-First-Look/ba-p/23149) which explains that Juniper is renewing it’s learning classes and they need beta testers for this. In the following lines I will use some lines from the link posted above, so please don’t sue me for copyright infringement, rather let me know if there is a problem and I’ll remove them.

So, what’s going on Juniper:
“When we write new training classes (or even significantly revise existing ones), we conduct various kinds of reviews to ensure that the training teaches the correct audience the correct skills in the correct way.  Sometimes, we get input from members of the “target audience” prior to writing the training (or even while writing the training), to find out what they really want to know, or to find out if a particular example is going to work well.  However, one of the biggest tests of a new class is the beta class.”

What is a beta class?
“A beta class is the first real-life test of a new class”

Where will them take place?
“It is conducted in our (n.a. Juniper’s) Sunnyvale offices using student guides and labs that are candidates for final release, and it is taught on a schedule that imitates the final class.  This is where we find out whether the four-day class really is four days, whether that slide on the second day really does explain four-byte AS numbers well enough, and whether that lab really does explain the topic accurately.  This is our opportunity to double-check that the class includes the correct material for the target audience, that it teaches that material well, and that there are no missing “building blocks” of knowledge.”

What they will teach you?
“… we have many kinds of classes (introductory, intermediate, and advanced) on many different topics (routing, VPNs, MPLS, security, management, etc.)”

How much does it cost?
“Participants in the beta classes are allowed to attend the class for free (however, all incidental expenses, including travel, are the participants’ responsibility)”

As you can see this beta classes are free, but unfortunately  for some of us, network engineers, will cost some money (at least for me since I’m in Europe) to attend, due to travel expenses and accommodation. Anyway the lucky ones, which are interested in seeing what’s the deal with Juniper and have some know-how about networking can attend this classes for free. To take advantage of this offer, you have to register. Please find out how to do that at:  http://forums.juniper.net/t5/Networking-Now/Training-Get-a-Free-First-Look/ba-p/23149, the paragraph before last one.

OK, if you cannot participate in this program, but you still want to get familiar with Juniper, there is a good news, as you can find online some classes. And the best part, some of them are completely free, you just need an Internet connection and you’re good to go. You can find this online classes here: http://www.juniper.net/us/en/training/technical_education/

Cisco Security Advisory: FWSM Crafted ICMP Message Vulnerability

Summary

A vulnerability exists in the Cisco Firewall Services Module (FWSM) for the Catalyst 6500 Series Switches and Cisco 7600 Series Routers. The vulnerability may cause the FWSM to stop forwarding traffic and may be triggered while processing multiple, crafted ICMP messages.

There are no known instances of intentional exploitation of this vulnerability. However, Cisco has observed data streams that appear to trigger this vulnerability unintentionally.

Cisco has released free software updates that address this vulnerability.

Successful exploitation of the vulnerability may cause the FWSM to stop forwarding traffic between interfaces (transit traffic), and stop processing traffic directed at the FWSM (management traffic). If the FWSM is configured for failover operation, the active FWSM may not fail over to the standby FWSM.

Workarounds

There are no workarounds for this vulnerability. Access control lists (ACLs) that are deployed on the FWSM itself to block through-the-device or to-the-device ICMP messages are not effective to prevent this vulnerability. However, blocking unnecessary ICMP messages on screening devices or on devices in the path to the FWSM will prevent the FWSM from triggering the vulnerability. For example, the following ACL, when deployed on a Cisco IOS device in front of the FWSM, will prevent crafted ICMP messages from reaching the FWSM, and thus protect the FWSM from triggering the vulnerability:

access-list 101 permit icmp any any echo
access-list 101 permit icmp any any echo-reply
access-list 101 permit icmp any any traceroute
access-list 101 permit icmp any any packet-too-big
access-list 101 permit icmp any any time-exceeded
access-list 101 permit icmp any any host-unreachable
access-list 101 permit icmp any any unreachable
access-list 101 deny   icmp any any
access-list 101 permit ip any any

The advisory is posted at the following link: http://www.cisco.com/en/US/products/products_security_advisory09186a0080af0d1d.shtml

Some personal observation regarding this vulnerability. I didn’t understood what they mean by “crafted” ICMP packets. In the advisory is posted that “There are no known instances of intentional exploitation of this vulnerability“, then what kind of ICMP packets would kill FWSM? Any usual “ping” (ICMP echo request / echo reply) or it has to be some packet with a special pattern?

If a special pattern is needed then there is a known exploitation of this vulnerability, but due to the fact that Cisco didn’t want any kiddie to try this, they didn’t release the information about what kind of ICMP traffic will foce FWSM to stop forwarding the traffic. In case that any ICMP packet might have an impact for FWSM functionality, then there is a big problem with this hardware.

Also their solution regarding ICMP blocking, cannot be applied in any case. I mean from my point of view as network engineer is OK, but from business impact may be bad, due to the fact that every user or manager use “ping” to check a running service, server or application. Imagine what will happen when 50% of the users will call for support that services are not running :)

UPDATE: Thanks to the comment of João Sena Ribeiro I noticed that the phrase (strikethrough) is a little bit confusing, as I put it in the context that I don’t  know what “ping” command will brind down the traffic through FWSM. If there is a known exploit for this (even if Cisco says there is none for the moment), a special pattern can be included also in a simple ICMP echo-request / echo-reply communication, causing the FWSM to hangup. So, if there is no solution for this vulnerability, I would like to block all ICMP traffic, but for the reasons already explained this would not be a good solution.

Fluke Networks acquired AirMagnet

FlukeWith its acquisition of wireless LAN design, management and security vendor AirMagnet, Fluke Networks is positioning itself to be a vendor of choice for enterprises that are trying to manage hybridized networks with both wired Ethernet and wireless LAN technology.

“The bottom line is that enterprises are going to have hybrid networks for a really, really long time,” said Paul DeBeasi, senior analyst with Burton Group. “I’m having a lot more phone conversations with enterprises that are looking at new deployments where they want to just go all wireless for network access. What that really means is wireless LAN for access and wired Ethernet used for backhaul and also for switch trunks and data center connections.”

READ FULL STORY ON SearchNetworking.com