Hi all

We were one of the AS's affected by this -- it took down both of our 
(otherwise very reliable!) OpenBSD 4.4 routers, and I spent much of this 
afternoon diagnosing and then working around the problem.

The problem is that the AS4_PATH value being transmitted for prefix 
91.207.218.0/23 contained a path segment of type AS_CONFED_SEQUENCE, which as 
RFC4893 declares to be an invalid value.

OpenBGPd checks this attribute, finds it to be invalid, and drops the entire 
BGP session.  On the face of it, this action seems to be a reasonable thing 
to do, but in practice it is only reasonable if all BGP speakers do this; in 
that instance the BGP speakers closest to the router emitting the faulty 
attributes would close the conversations, the faulty AS4_PATH would not 
propagate, the admins of those routers would then be under some pressure to 
fix the problem (since their BGP sessions would be down).

However, since most BGP speakers apparently do NOT examine the AS4_PATH it 
propagates out until it reaches a speaker who does examine it, and they then 
promptly terminate the BGP session with a BGP NOTIFICATION type 3 ("UPDATE 
message error") subcode 11 ("Malformed AS_PATH"). 

The intervening routers, which do not examine but do pass on the AS4_PATH 
attribute, are unaffected. Thus the problem manifests itself far from the 
real source, and as Peter says unless one is unreasonably left without any 
BGP session at all (and thus most likely no internet connection).

Since 32-bit ASNs are being retrofitted to the existing BGP4 system and the 
situation of AS4_PATH not being validated by the majority of BGP speakers 
will persist for some time, OpenBGPd's behaviour should probably be changed.

OpenBGPd 4.2 and 4.3 are affected. OpenBGPd 4.0 did not verify the AS4_PATH 
attribute and appears to be unaffected.

Here's my patch that modifes OpenBGPd to (silently) accept these malformed 
AS4_PATH attributes; this is recommended solely as a workaround for affected 
systems until a proper patch to OpenBGPd is developed:
  http://sowerbutts.com/tmp/bgpd-wrs.patch  

Here's the broken update we were seeing, viewed in wireshark:
  http://sowerbutts.com/tmp/broken-update.png

Thanks

Will Sowerbutts
Deus Ex Machina Ltd


On Wed, Dec 10, 2008 at 08:36:58PM +0000, Peter Bristow wrote:
>Hi All,
>
>The AS at the company I work for running (OpenBSD 4.2 and 4.3) as well as
>the AS run by a associate of mine (OpenBSD 4.4) experienced rather wild
>route flaps earlier today. Quoted from Andy Davidson's post to nanog.
>
>"It seems that the prefix causing OpenBGPd speakers to die is
>91.207.218.0/23, which is originated by a 4-byte ASN speaker.
>
>OpenBGPd is checking AS4_PATH to ensure that it contains only AS_SET and
>AS_SEQUENCE types, as per RFC4893.  When processing the UPDATE for
>91.207.218.0/23 it sees :
>
>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)
>
>RFC4893 is clear on the matter :
>
>"
>  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.
>"
>
>OpenBGPd is therefore dropping the sessions when this update is received.
> Unideal if this attribute is learned on multiple upstreams...
>
>The impact today is fairly limited as there are relatively few bgp speakers
>honouring the 4-byte ASN protocol extension rules, but as code that support
>these features creeps around the internet, the next time this happens the
>impact could be much greater, so we need to understand which implementation
>of which BGP software caused this illegal origination.
>
>Modifying the OpenBGPd software to permit AS_CONFED_SEQUENCE, AS_CONFED_SET
>in an as4_path causes the path to be accepted and the session is not torn
>down.  This isn't a great fix."
>From looking at the source this would appear to be
>'expected' behavior however it does leave you without any internet
>connectivity. I'm not as much of a BGP guru as I should be but what would be
>the impact of dropping the route/update rather than dropping the session?
>
>Pete Bristow
>

_________________________________________________________________________
William R Sowerbutts                                  [EMAIL PROTECTED]
"Carpe post meridiem"                               http://sowerbutts.com
         main(){char*s=">#=0> [EMAIL PROTECTED]@^7=",c=0,m;for(;c<15;c++)for
         (m=-1;m<7;putchar(m++/6&c%3/2?10:s[c]-31&1<<m?42:32));}  

Reply via email to