Re: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
-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-
Re: BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH
-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.david...@netsumo.com),
~Jonathan Oddy, Hostway UK (jonathan.o...@hostway.co.uk),
~Rob Shakir, GX Networks (r...@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-
