January 2009 - Test - lists.nanog.org

BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
by Rob Shakir 21 Jan '09

21 Jan '09

Strict RFC 4893 (4-byte ASN support) BGP4 implementations are vulnerable to a session reset by distant (not directly connected) ASes. This vulnerability is a feature of the standard, and unless immediate action is taken an increasingly significant number of networks will be open to attack. Accidental triggering of this vulnerability has already been seen in the wild, although the limited number of RFC 4893 deployments has limited its effect. Summary: It is possible to cause BGP sessions to remotely reset by injecting invalid data into the AS4_PATH attribute provided to store 4-byte ASN paths. Since AS4_PATH is an optional transitive attribute, the invalid data will be transited through many intermediate ASes which will not examine the content. To be vulnerable, an operator does not have to be actively using 4-byte AS support. This problem was first reported by Andy Davidson on NANOG in December 2008 [0], furthermore we have been able to demonstrate that a device running Cisco IOS release 12.0(32)S12 behaves as per this description. Details: When a prefix is learnt from a BGP neighbour that does not support 4-byte ASNs, the AS4_PATH attribute is retained, and appended to UPDATE messages sent to other neighbours [1, 3]. RFC4893 specifies that AS_CONFED_SEQUENCE and AS_CONFED_SET are invalid in an AS4_PATH, the intention of which is to ensure that an AS with a mix of AS4-aware BGP speakers, and AS4-unaware BGP speakers does not propagate confederation AS paths outside of the confederation [1, 3]. Upon receiving an invalid BGP UPDATE message, a BGP speaker must send a NOTIFICATION message [2, 6.3], after a NOTIFICATION message, the BGP connection is closed [2, 4.5]. Analysis of the Reported Path: On 10th December 2008, a BGP update was propagated with illegal/invalid confederation attributes in the AS4_PATH. When this update was received by AS4 aware BGP speakers, the RFCs described above were interpreted literally and the session was torn down. Because the illegal attributes were learned on a transit session, an affected network can have global reachability impaired. Please note that the analysis of this path describes what we expect to have happened in this case, it has not been confirmed by any of the ASNs involved. 91.207.218.0/23 Path Attributes - Origin: Incomplete Flags: 0x40 (Well-known, Transitive, Complete) Origin: Incomplete (2) AS_PATH: xx xx 35320 23456 (13 bytes) AS4_PATH: (65044 65057) 196629 (7 bytes) In this data, the AS_PATH indicates that a prefix is announced by an AS4 speaker (as indicated by AS23456) and propagated through by AS35320. The AS4_PATH data shows that the AS4 originator is AS196629, the rest of this path is an AS_CONFED_SEQUENCE [3, 5]. It would appear that in this case, AS196629 peers with AS35320, which is AS4-aware on this border. The prefix is then propagated through AS35320, with the AS4 aware routers appending their ASN to the AS_CONFED_SEQUENCE. This is in contravention of RFC 4893 [1, 3]. The border which announces this route to AS35320's upstream does not appear to be AS4-aware. During normal announcements, the BGP speaker on a border with an upstream ASN that is not part of the confederation will remove the left-most AS_CONFED_SETs or AS_CONFED_SEQUENCEs that exist in the AS_PATH [3, 6.1] and replace them with the confederation identifier. However, due to the fact that both AS_CONFED_SET and AS_CONFED_SEQUENCE are invalid in an AS4_PATH, then no such action is taken on the border between an AS4 aware AS, and a non-AS4 aware AS. In addition, since the AS35320 border is not AS4 aware, then it does not update the AS4_PATH. This malformed UPDATE is then sent to AS35320's upstream, if there are no AS4-aware routers in the path between the AS35320 border, and an AS receiving this update, the AS4_PATH will not have been analysed. The first AS4-aware router to receive this update will reset the session towards the neighbour from whom it receives the update. The border which announces this route to AS35320's upstream does not appear to be AS4-aware; If it were a strict AS4 implementation it would reset the BGP session due to the malformed AS4_PATH, and a broken implementation that treats AS4_PATH as an equivalent of the AS_PATH would sanitise the AS4_PATH. This allows the AS4_PATH containing an AS_CONFED_SET to be passed to neighbouring networks. This escape of an AS_CONFED_SET from a network with only partial AS4 support is exactly the situation that RFC 4893 attempts to avoid by forbidding the presence of an AS_CONFED_SET in the AS4_PATH. In the ideal world the neighbouring network receiving an UPDATE containing this obviously malformed AS4_PATH would reset the session, preventing further propagation and isolating the broken network. Unfortunately the vast majority of networks do not support AS4 so pass on this malformed AS4_PATH to their neighbours. The first AS4-aware router to receive this update will reset the session towards the neighbour from whom it received the update. Cisco IOS Behaviour: In a lab environment, a Cisco 7200 running IOS 12.0(32)S12, which is able to support 4-byte ASNs, was peered with a Cisco 2811 running 12.4(19). When the BGP session to the upstream 2811 is established by the 7200, the following log messages are observed: *Jan 16 11:29:58.531: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Up *Jan 16 11:30:02.595: %BGP-6-ASPATH: Invalid AS path (65044 65048 65062) 3.21 23456 received from 193.239.32.2: Confederation found in AS4_PATH *Jan 16 11:30:02.595: %BGP-5-ADJCHANGE: neighbor 193.239.32.2 Down BGP Notification sent *Jan 16 11:30:02.595: %BGP-3-NOTIFICATION: sent to neighbor 193.239.32.2 3/1 (update malformed) 27 bytes E0111803 030000FE 140000FE 180000FE 26 FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF 0050 0200 0000 3540 0101 0240 020C 0205 3D25 2114 89F8 5BA0 5BA0 4003 04C1 EF20 02E0 1118 0303 0000 FE14 0000 FE18 0000 FE26 0202 0003 0015 0000 5BA0 175B CFDA The configuration on the 7200 is as follows: router bgp 65123 no synchronization bgp log-neighbor-changes neighbor 193.239.32.2 remote-as 15653 no auto-summary The BGP session will continue to be reset each time the invalid AS4_PATH is received. Possible Impact: During a BGP conversation, it is expected that a neighbour's UPDATE messages are sanitised by the immediate neighbour, during a 'normal' BGP conversation, if a BGP speaker receives an invalid UPDATE, it will teardown the session, and this invalid UPDATE will not propagate any further. In the case of optional transitive attributes such as AS4_PATH, this invalid update can be transited through many ASes, as the content of the invalid attribute in the UPDATE message is not examined. In a hypothetical scenario, an AS4 aware service provider (A) has a transit provider (T) that is not AS4 aware. BGP speaker B, a large distance from A has a bug affecting their equipment that introduces an AS_CONFED_SET in the AS4_PATH. Since B's updates are propagated through to A via T, A will tear down the session to T due to the malformed attribute. This is an out of proportion reaction as the update may affect only one prefix in a full BGP table. If this update is also propagated through A's other transit providers A may lose full-table visibility until one of their transit providers filters the route. Examining the UPDATE message to establish which route caused session teardown may be a non-trivial activity. Conclusion: Whilst this description may be applied to invalid data in any optional transitive element, it has a greater impact with AS4_PATH due to the large number of BGP speakers that currently do not examine any 4-byte ASN data in an UPDATE. There has been a discussion of this matter on the IETF IDR mailing list [4], however, due to availability of Cisco IOS containing AS4 support (12.0(32)S12), and an observation of this problem 'in the wild', we believe that it is of operational concern to those that are planning on deployment of AS4-aware platforms [5]. Any input from the operational community relating to this problem is much appreciated, either publicly, or privately. Regards, Andy Davidson, NetSumo (andy.davidson(a)netsumo.com) Jonathan Oddy, Hostway UK (jonathan.oddy(a)hostway.co.uk) Rob Shakir, GX Networks (rjs(a)eng.gxn.net) References: [0]: Andy Davidson - 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320, http://markmail.org/message/3ofvjyggayfxezna [1]: rfc4893: BGP Support for Four-octet AS Number Space [2]: rfc4271: A Border Gateway Protocol 4 (BGP-4) [3]: rfc3054: Autonomous System Confederations for BGP [4]: Kaliraj Vairavakkalai, Juniper Networks, [Idr] RFC-4893 handling malformed AS4_PATH attributes, http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [5]: http://as4.cluepon.net/index.php/Software_Support Thanks to Will Hargrave (LONAP) for assistance with this document.

6 9

Traffic metrics and cost analysis....
by Murphy, Jay, DOH 21 Jan '09

21 Jan '09

Hey all, Can anyone point to a good power-point template/presentation for metric and cost analysis for routing? I will not plagiarize unless; I am given copyright permission :-). Seriously, anyone have one handy, I am under the press to complete a presentation before Friday morning. Thanks a million, Jay Murphy IP Network Specialist NM Department of Health ITSD - IP Network Operations Santa Fé, New México 87502 "We move the information that moves your world." Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.

1 0

expectations for bgp peering?
by mike 21 Jan '09

21 Jan '09

Hello, So I am just wondering what my expecations should be in a bgp peering scenario where I am multihomed with my own ASN and arin assigned ip space. At issue is the fact that my backup isp forced me to use ebgp multihop to peer with a router internal to their network and not the border router I am directly attached to, and secondly, that they say I am not allowed to prepend at all - they will do it for me, and from the looks of things they have established a route-map that just prepends their AS 6 times to my announcement. This smells of bad engineering. I have looked up the bgp report for my provider and they have 0 downstream AS's, and the week that this project has taken (and it's still not up and working) has left me with less than absolute confidence in the provider. I want to know if anyone has an opinion on ebgp multihop for external customers, and wether I should really have an expectation to be able to assign my prepends as suits my needs? Are there any conditions that could make this fail that I should be aware of? Mike-

6 6

Re: Inauguration streaming traffic
by Brandon Butterworth 21 Jan '09

21 Jan '09

> The Beeb's HD multicast feed is about 23Mbit/s to the host, and we received > it at quite decent (subjective) quality here on a JANET-connected university > site. This is full broadcast HD, exactly the same as we have on satellite. We don't consider it generally usable, it's part of IPTV services not general Internet distribution. I expect we'll make a 1.5Mbit/s stream, not really HD just what people flog as Internet HD, some time. > The interesting aspect of the HD stream was seeing how various systems coped > with the CPU load. It was good to have some HD content available that > encouraged people to install vlc, find out a little about multicast, and > system issues in receiving it. That's why I leave it there but unpublicised as users would try getting it down their adsl and annoy their ISP. > Thanks again Beeb :) /me doffs cap brandon

1 0

DNS Amplification attack?
by Wil Schultz 21 Jan '09

21 Jan '09

Anyone else noticing "." requests coming in to your DNS servers? http://isc.sans.org/diary.html?storyid=5713 I'm seeing them coming from the following addresses in my ns server logs. 69.50.142.110 69.50.142.11 76.9.16.171 66.230.128.15 66.230.160.1 -wil

9 10

Re: expectations for bgp peering?
by Scott Weeks 21 Jan '09

21 Jan '09

Apologies for top posting, but my response is a little long long... I wouldn't be too concerned about the multi-hop as there're many reasons why they might do that, but a week out and it's still not working? It's all about customer service. Are they giving you the appropriate level of service you expect for what you're paying? If not, vote with your dollars and move on... Usually, I get the circuit up and pingable to the IPs that will be doing the peering ahead of time. I then set a date for the BGP turn up. On my side, BGP is pre-configured and all I have to do is type 'no shut'. Most times everything comes up and we all go home happy. Sometimes I have to do a little troubleshooting. If they got the lower layers up ahead of time with you, set a date to turn up BGP and now it's a week later, I'd be worried about what type of customer service they'd give later on when trouble happens. And they don't allow you to prepend? In my book that'd be two strikes against them and this isn't baseball, so I wouldn't wait for the third strike. scott --- mike-nanog(a)tiedyenetworks.com wrote: So I am just wondering what my expecations should be in a bgp peering scenario where I am multihomed with my own ASN and arin assigned ip space. At issue is the fact that my backup isp forced me to use ebgp multihop to peer with a router internal to their network and not the border router I am directly attached to, and secondly, that they say I am not allowed to prepend at all - they will do it for me, and from the looks of things they have established a route-map that just prepends their AS 6 times to my announcement. This smells of bad engineering. I have looked up the bgp report for my provider and they have 0 downstream AS's, and the week that this project has taken (and it's still not up and working) has left me with less than absolute confidence in the provider. I want to know if anyone has an opinion on ebgp multihop for external customers, and wether I should really have an expectation to be able to assign my prepends as suits my needs? Are there any conditions that could make this fail that I should be aware of? Mike-

1 0

Re: "IP networks will feel traffic pain in 2009" (C|Net & Cisco)
by Matthew Kaufman 20 Jan '09

20 Jan '09

Alex H. Ryu wrote: > Probably IP v4 address runout may not affect for traffic amount that much. > Since people will use NATing for saving IP addresses, and IPv6 will be > slowly take some traffic for that matter. > > It's more of the cost of bandwidth, and the application people uses. > > As I said, "we'll see"... the people using NATing are still going to have to connect to something, somewhere, to get the data that makes up this traffic. The people buying boxes that move traffic around will be spending some of that money on either v6 capability or NATs or both, too. Matthew Kaufman

1 0

Re: Inauguration streaming traffic
by Scott Weeks 20 Jan '09

20 Jan '09

------- jay(a)west.net wrote: ------- From: Jay Hennigan <jay(a)west.net> We're a regional ISP, about 80% SMB 20% residential. We're seeing almost double our normal downstream traffic right now. Anyone else? ------------------------------------ Not much of a traffic boost here in Hawaii as it happened at 7am local time. Most folks caught the first part on TV and rushed to work, evidently. scott

2 1

Level3 NOC Contact
by Darryl Dunkin 20 Jan '09

20 Jan '09

Their support has been really giving me the run-around and is cluelessly sending me from department to department. Does anyone have a good NOC contact for them? I have one of their downstream customers hijacking some of my IP space and they don't really care as I am not a direct customer of theirs.

2 2

Single carrier multi-circuit asynchronous routing issue
by Aaron Millisor 20 Jan '09

20 Jan '09

I am curious to know if anyone has else has hit a problem like the one I am running into right now. I have two DS3 DIA's in my router, terminating on two separate routers at Sprint. We peer with BGP and I am prepending certain of my prefixes to balance the traffic load. src __________ dst 1.1.1.0 |----|- ds3 #1 -| sprint 1 |--( ) 2.2.2.0 ------- |me | ( internet ) ------- | | ( ) | | __________ ( ) |----|- ds3 #2 -| sprint 2 |--( ) If I were to prepend the network 1.1.1.0 to come in on 'sprint 1', but have a route to 2.2.2.0 via 'sprint 2' so that traffic comes in on one circuit but returns on the other, routing is broken. If I change my route so that packets directed to 2.2.2.0 return on the same circuit that the traffic is received on, everything works fine. Has anyone else run into an issue like this before? -- am

3 3