91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320

Andy Davidson andy at nosignal.org
Wed Dec 10 18:24:20 UTC 2008


Hi,

Further to my email two and a half hours ago, 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 a software point of view, I agree that a configurable option to  
reject the route but keep the session, reject the route and drop the  
session, accept the route but log/send trap, etc. would be nicer, but  
this is an implementation thing and probably beyond the scope of this  
list.

For now, does anyone have contacts at 196629 or 35320 who can explain  
the implementation and fix the behaviour ?

Andy




More information about the NANOG mailing list