BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
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@netsumo.com), Jonathan Oddy, Hostway UK (jonathan.oddy@hostway.co.uk), Rob Shakir, GX Networks (rjs@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.
Comments below. Rob Shakir wrote:
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@netsumo.com), Jonathan Oddy, Hostway UK (jonathan.oddy@hostway.co.uk), Rob Shakir, GX Networks (rjs@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.
Rob, I'm sure you (and others) already aware of this, but for the archives' sake, when Andy first brought this up on nanog@ there was a corresponding discussion on the misc@openbsd.org mailing list: http://marc.info/?l=openbsd-misc&w=2&r=1&s=32bit+ASn&q=b And patched (in OpenBGPD) here: http://marc.info/?l=openbsd-misc&m=122894875212174&w=2 though I see it's now in CVS: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.sbin/bgpd/rde.c Regards, Tico
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I was indeed aware of the OpenBGPD discussion and patch, and I'm glad it has been worked around in what I believe to be a sensible way, however I disagree with the comment in the code that states that the standard does not specify how to handle this situation. I believe that RFC 4271* and 4893** currently require a teardown of the session in this case and indeed the person who committed the fix to OpenBGPD seems to agree in their commit message (although still kept the code comment.) This really needs to lead to more debate on the correct way to handle this situation and an updated standard, before implementers decide to fix this in their own different ways. The discussion on the IETF IDR mailing list[1] was promising, but looks to have died off before reaching a conclusion. There was mention of stripping the AS_CONFED_SET/SEQUENCE from the AS4_PATH, however several people pointed out this approach is not without issues. Dropping the UPDATE entirely is also discussed, but can lead to loops. Personally I favour treating receipt of an UPDATE with a malformed attribute as a withdrawal, although this was only briefly mentioned and its implications were never discussed in any detail... The reason for us publishing this report was to alert people to the fact that this problem is definitely in the wild, there are broken AS4_PATHs being announced, and, critically, Cisco's IOS releases to support RFC4893 are vulnerable to having their sessions reset as a result of their standards compliant implementation. At present our advice has to be that upgrading to an IOS version with RFC4893 support is extremely dangerous, and should be avoided at all costs (where this leaves Cisco shops who have been given 32 bit AS numbers by their RIR is somewhat unpleasant to consider.) It must be emphasized that this is due to no fault on Cisco's part, but rather a feature of the standard that must be corrected as soon as possible. [1] http://www.ietf.org/mail-archive/web/idr/current/msg03368.html * From RFC4271: Section 6: ~ "When any of the conditions described here are detected, a ~ NOTIFICATION message, with the indicated Error Code, Error Subcode, ~ and Data fields, is sent, and the BGP connection is closed (unless it ~ is explicitly stated that no NOTIFICATION message is to be sent and ~ the BGP connection is not to be closed). If no Error Subcode is ~ specified, then a zero MUST be used." Section 6.3: ~ "If an optional attribute is recognized, then the value of this ~ attribute MUST be checked. If an error is detected, the attribute ~ MUST be discarded, and the Error Subcode MUST be set to Optional ~ Attribute Error. The Data field MUST contain the attribute (type, ~ length, and value)." ** From RFC4893: Section 3: ~ "To prevent the possible propagation of confederation path segments ~ outside of a confederation, the path segment types AS_CONFED_SEQUENCE ~ and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH ~ attribute." - -- Jonathan Oddy Hostway UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdFjqWGqmTqbbikoRAmNuAJoCPqNUTYOW9lFUQXFfLAFgA/bIcQCeODVz Wo1MjYgtdDw1SmWhmHdzcWM= =AGvq -----END PGP SIGNATURE-----
Jonathan Oddy wrote:
dangerous, and should be avoided at all costs (where this leaves Cisco shops who have been given 32 bit AS numbers by their RIR is somewhat unpleasant to consider.) It must be emphasized that this is due to no
Suddenly makes one wonder if it would have been easier to take back any ASN's which weren't justified versus butchering the protocol. Jack
On Tue, Jan 20, 2009 at 01:01:03PM +0100, Mikael Abrahamsson wrote:
have been able to demonstrate that a device running Cisco IOS release 12.0(32)S12 behaves as per this description.
Has anyone looked into IOS XR behaviour, if it's the same as 12.0(32)S12?
Mikael, Pierfrancesco Caci was kind enough to provide me with some output from an XR box. It appears that IOS XR behaves in the same manner as Force10, and JunOS, whereby the session is not torn down, and the path is installed, albeit with a munged AS_PATH. The output below is for the prefix from 196629 which we originally analysed: Path #1: Received by speaker 0 3356 35320 3.21 23456 Given that XR box is an AS4-speaker, one would not expect to see 23456 in the AS_PATH, the prescence of this AS seems to be a symptom of the bug (and again occurs on Juniper/Force10). Kind regards, Rob -- Rob Shakir <rjs@eng.gxn.net> Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 After some lab work we have established that the source of the invalid AS4_PATHs discussed in [1] is likely a non compliant implementation of RFC4893 (AS4) in some versions of Juniper JunOS. We have observed the following behaviour with both JunOS 9.3R1.7 and 9.1R2.10, and suspect it may be present in all other JunOS versions since they introduced AS4 support in 9.1R1. Unfortunately we have limited resources so have not been able to test with other versions. When a mix of pre and post 9.1R1 JunOS devices are deployed within a network utilising confederations the AS4_PATH (if present) is used by the AS4 supporting devices to hold an AS_CONFED_SET/SEQUENCE. This behaviour is explicitly forbidden by RFC4893 [3]. If the egress router from the AS utilising confederations is not AS4-aware the confederation information is never removed from the AS4_PATH, and is passed onto the neighbouring networks with the repercussions discussed in [1]. As mentioned in both [1] and [2] this is especially critical as at present Cisco IOS will tear down sessions when receiving an AS4_PATH containing an AS_CONFED_SET/SEQUENCE. Lab setup: AS1.0 - obgp1 (OpenBGPD) AS64512 { ~ AS65001 - juniper1 (JunOS 9.1 or 9.3) (32 bit ASN support) ~ AS65002 - juniper2 (JunOS 8.4) (no 32 bit ASN support) } AS64513 - obgp2 (OpenBGPD) Where AS1.0 is an AS with a 32bit AS number, AS64512 is a Juniper network using confederations and with mixed AS4 support, and AS64513 is another network (doesn't matter what it supports.) On announcing a prefix from obgp1 we observe the following in the UPDATE from juniper1 to juniper2: AS_PATH: (65001) 23456 AS4_PATH: (65001) 65536 And at obgp2: AS_PATH: 64512 23456 AS4_PATH: (65001) 65536 This shows juniper1, which is AS4-aware, adding an AS_CONFED_SET to both the AS_PATH and AS4_PATH before announcing the prefix to juniper2. As juniper2 is not AS4-aware it does not strip the AS_CONFED_SET from the AS4_PATH before announcing it to obgp2, resulting in an invalid AS4_PATH attribute in the UPDATE to obgp2. Conclusions: ~ * If you use JunOS and make use of confederations you should ensure that your entire network either supports AS4 (9.1R1 or later) or doesn't (pre 9.1.) ~ * While the Juniper implementation is clearly non-compliant with the standard, and should be corrected, the number of versions in which this bug is probably present means that these versions will never be completely eliminated from use. ~ * The flaw in the standard can still be misused maliciously. We do not see that going forward it will be possible to completely eliminate the possibility of an AS_CONFED_SET appearing in an AS4_PATH. We believe that this problem requires a consistent response from the vendors, and that to facilitate such a response the standard must be revised. Even if vendors do implement their own workarounds the standard needs to be revised to ensure that future implementers don't fall into this trap. Regards, ~ Andy Davidson, NetSumo (andy.davidson@netsumo.com), ~ Jonathan Oddy, Hostway UK (jonathan.oddy@hostway.co.uk), ~ Rob Shakir, GX Networks (rjs@eng.gxn.net) [1] http://www.merit.edu/mail.archives/nanog/msg14345.html [2] http://www.merit.edu/mail.archives/nanog/msg14388.html [3] From RFC4893 section 3: ~ "To prevent the possible propagation of confederation path segments ~ outside of a confederation, the path segment types AS_CONFED_SEQUENCE ~ and AS_CONFED_SET [RFC3065] are declared invalid for the AS4_PATH ~ attribute." Thanks to Dan Goscomb (Goscomb Tech) for loan of a J2320 for the lab. Thanks to Will Hargrave (LONAP) for assistance with this document. - -- Jonathan Oddy Hostway UK -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJdKMZWGqmTqbbikoRAuDFAJ9WTlvAE/5KogtgShiBmXJo238kHQCfdSjG s3p8pIfX7JmPKC84/yxE67w= =53KL -----END PGP SIGNATURE-----
On Mon, Jan 19, 2009 at 03:58:17PM +0000, Jonathan Oddy wrote:
As mentioned in both [1] and [2] this is especially critical as at present Cisco IOS will tear down sessions when receiving an AS4_PATH containing an AS_CONFED_SET/SEQUENCE.
Hi, Whilst this is behaviour is RFC compliant, as previously described, it is sub-optimal operationally. I have raised this issue with Cisco TAC, and CSCsx10140 has been opened to track this problem. I would encourage those network operators who may be planning to deploy AS4-support and use Cisco equipment to open a SR with Cisco, tracking this bug, to try to ensure that both the IOS behaviour, and RFC are changed. Many thanks, Rob -- Rob Shakir <rjs@eng.gxn.net> Network Development Engineer GX Networks/Vialtus Solutions ddi: +44208 587 6077 mob: +44797 155 4098 pgp: 0xc07e6deb nic-hdl: RJS-RIPE This email is subject to: http//www.vialtus.com/disclaimer.html
Hi, Further to the initial research sent to NANOG, after discussions with a number of operators, we have compiled some recommendations on the handling of invalid AS4_PATH attributes. Any feedback on these recommendations is appreciated: As discussed on the IETF IDR list last month, there are concerns relating to the treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0]. Since the last post to that thread the situation has been made more urgent with the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there is no alternative error handling defined in RFC4893. As posted last Friday [1], and discussed on the IDR list, this strict implementation introduces a new attack vector by which a BGP session can be torn down due to a an attribute populated by a distant BGP neighbour. These malformed attributes have already been seen in the wild as a result of a error in Juniper's implementation of RFC4893. Following discussions with a number of operators, we have attempted to generate some recommendations relating to the behaviour that would be operationally most useful when treating the invalid data in the AS4_PATH optional transitive attribute. There are two cases to consider when an invalid AS4_PATH is received: (1) A path to the prefix is not already known from that neighbour. (2) A path to the prefix has already been learnt from that neighbour; In case (1) we recommend that the BGP speaker should discard the UPDATE and log the fact. The log entry should include the received AS_PATH and AS4_PATH to aid in debugging. In case (2) we recommend that the BGP speaker should treat the UPDATE as a withdrawal of existing path to the prefix. As per case (1) a log entry should be raised to indicate that this has occurred. It is quite possible that in both cases this behaviour may result in the BGP speaker no longer having a valid path to the destination. We foresee that this lack of a prefix in a BGP speaker's routing table may cause some operational load initially, however, we feel that this is acceptable, considering the alternate behaviours. Should a prefix be injected into the global table with an invalid AS4_PATH, and should the newly advertised (invalid) path be selected by all upstreams available to a given ASN then this ASN will lose reachability to the prefix. Whilst this can be abused we do not see this as more serious than the existing possibility of malicious injection and blackholing of a prefix by a 3rd party. As long as the rejection of paths due to invalid AS4_PATHs is clearly reported to the administrator the source of the problem can be clearly identified. We consider that attempting to extract a valid AS4 or AS_PATH from the invalid UPDATE is a mistake since this allows the propagation of invalid BGP data. In addition, incorrect implementation of this comparatively complex mechanism by a vendor may result in loops. By explicitly not installing prefixes with invalid AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by these invalid paths is avoided. The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects and it seems only by virtue of the fact that the implementations of many vendors do not strictly comply with the RFCs that this problem has not had the same impact for every vendor. At the current time, however, one cannot deploy a 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router into the global table, without risking teardown of a every session via which a global table is learnt. Further discussion of this issue would be much appreciated, as a common and consistent approach to rectifying the problem will benefit network operators far more than individual vendor implementing their own solution. Should a consensus be reached an update to the RFC is required in order to ensure that future implementations do not exhibit this harmful behaviour. Kind regards, Andy Davidson (NetSumo), andy.davidson@netsumo.com Jonathan Oddy (HostWay), jonathan.oddy@hostway.co.uk Rob Shakir (GX Networks), rjs@eng.gxn.net [0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html Many thanks to David Freedman (Claranet) for assistance in developing the recommendations in this document.
Hi, folks: We (IDR Chairs and co-authors) are working on updating RFC 4893 regarding the handling of the confed related segments in the AS4_PATH attribute. Expect to have the revised draft this week. Thanks. -- Enke Rob Shakir wrote:
Hi,
Further to the initial research sent to NANOG, after discussions with a number of operators, we have compiled some recommendations on the handling of invalid AS4_PATH attributes.
Any feedback on these recommendations is appreciated:
As discussed on the IETF IDR list last month, there are concerns relating to the treatment of AS_CONFED_SET/SEQUENCE in AS4_PATH as described in RFC4893 [0]. Since the last post to that thread the situation has been made more urgent with the release of Cisco IOS 12.0(32)S12, which responds to malformed AS4_PATH attributes by sending a NOTIFICATION to the neighbour, and tearing down the BGP adjacency. This behaviour seems to be required by RFC4721 section 6.3, as there is no alternative error handling defined in RFC4893. As posted last Friday [1], and discussed on the IDR list, this strict implementation introduces a new attack vector by which a BGP session can be torn down due to a an attribute populated by a distant BGP neighbour. These malformed attributes have already been seen in the wild as a result of a error in Juniper's implementation of RFC4893.
Following discussions with a number of operators, we have attempted to generate some recommendations relating to the behaviour that would be operationally most useful when treating the invalid data in the AS4_PATH optional transitive attribute.
There are two cases to consider when an invalid AS4_PATH is received: (1) A path to the prefix is not already known from that neighbour. (2) A path to the prefix has already been learnt from that neighbour;
In case (1) we recommend that the BGP speaker should discard the UPDATE and log the fact. The log entry should include the received AS_PATH and AS4_PATH to aid in debugging.
In case (2) we recommend that the BGP speaker should treat the UPDATE as a withdrawal of existing path to the prefix. As per case (1) a log entry should be raised to indicate that this has occurred.
It is quite possible that in both cases this behaviour may result in the BGP speaker no longer having a valid path to the destination. We foresee that this lack of a prefix in a BGP speaker's routing table may cause some operational load initially, however, we feel that this is acceptable, considering the alternate behaviours.
Should a prefix be injected into the global table with an invalid AS4_PATH, and should the newly advertised (invalid) path be selected by all upstreams available to a given ASN then this ASN will lose reachability to the prefix. Whilst this can be abused we do not see this as more serious than the existing possibility of malicious injection and blackholing of a prefix by a 3rd party. As long as the rejection of paths due to invalid AS4_PATHs is clearly reported to the administrator the source of the problem can be clearly identified.
We consider that attempting to extract a valid AS4 or AS_PATH from the invalid UPDATE is a mistake since this allows the propagation of invalid BGP data. In addition, incorrect implementation of this comparatively complex mechanism by a vendor may result in loops. By explicitly not installing prefixes with invalid AS_PATH or AS4_PATH into the routing table, the possibility of loops caused by these invalid paths is avoided.
The defined behaviour in RFC4893 and RFC4271 has significantly harmful effects and it seems only by virtue of the fact that the implementations of many vendors do not strictly comply with the RFCs that this problem has not had the same impact for every vendor. At the current time, however, one cannot deploy a 4-byte capable Cisco IOS device, or an OpenBGP (current stable release) router into the global table, without risking teardown of a every session via which a global table is learnt.
Further discussion of this issue would be much appreciated, as a common and consistent approach to rectifying the problem will benefit network operators far more than individual vendor implementing their own solution. Should a consensus be reached an update to the RFC is required in order to ensure that future implementations do not exhibit this harmful behaviour.
Kind regards, Andy Davidson (NetSumo), andy.davidson@netsumo.com Jonathan Oddy (HostWay), jonathan.oddy@hostway.co.uk Rob Shakir (GX Networks), rjs@eng.gxn.net
[0]: http://www.ietf.org/mail-archive/web/idr/current/msg03368.html [1]: http://www.merit.edu/mail.archives/nanog/msg14345.html
Many thanks to David Freedman (Claranet) for assistance in developing the recommendations in this document.
participants (6)
-
Enke Chen -
Jack Bates -
Jonathan Oddy -
Mikael Abrahamsson -
Rob Shakir -
Tico