BGP Session Teardown due to AS_CONFED_SEQUENCE in AS4_PATH

Mon Jan 19 10:41:46 UTC 2009

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