-----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-----