91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320
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
* Andy Davidson:
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.
Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of dropping the session? It's a transient, optional attribute, so you can't rely on your peers to filter it. -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
On 11 Dec 2008, at 08:34, Florian Weimer wrote:
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. Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of dropping the session? It's a transient, optional attribute, so you can't rely on your peers to filter it.
Well I have never written written a BGP stack, so I have no code to change as per your suggestion ;-) but as I said on the original post, I'd like to see it as a configurable option, so that I can do the right thing when something breaks. 196629 withdrew the prefix some hours ago and their NOC are investigating. I have asked if they will share some info about the problem when they have chance so that we can understand how to stop this happening in future. They don't use confederations internally so the reason for the break is actually non-obvious. Best wishes Andy
Florian Weimer <fweimer@bfk.de> writes:
* Andy Davidson:
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.
Uhm, shouldn't you just ignore invalid AS4_PATH attributes, instead of dropping the session? It's a transient, optional attribute, so you can't rely on your peers to filter it.
No you can't rely on that. But still, RFC4271 doesn't seemt to allow ignoring it. Which must be a bug in the RFC, or my reading of it. Hopefully the latter. Great if someone could correct the interpretation below. IMHO, an optional transitive attribute with the partial bit set should not cause session tear-down, since the attribute is forwarded across one or more routers not handling it and therefore not filtering it. However, RFC4271 does not make such an exception for optional + transitive + partial AFAICS: 6. BGP Error Handling. This section describes actions to be taken when errors are detected while processing BGP messages. 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. [..] 6.3. UPDATE Message Error Handling All errors detected while processing the UPDATE message MUST be indicated by sending the NOTIFICATION message with the Error Code UPDATE Message Error. The error subcode elaborates on the specific nature of the error [..] 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). Which basically means that you can take down every RFC-compliant 4-byte ASN honouring router today by injecting a bogus AS4_PATH attribute into the mostly 2-byte-ASN-only Internet... Or did I miss something? I certainly hope I did. Bjørn
On Thu, Dec 11, 2008 at 01:28:46PM +0100, bjorn@mork.no wrote:
No you can't rely on that. But still, RFC4271 doesn't seemt to allow ignoring it. Which must be a bug in the RFC, or my reading of it. Hopefully the latter. Great if someone could correct the interpretation below.
IMHO, an optional transitive attribute with the partial bit set should not cause session tear-down, since the attribute is forwarded across one or more routers not handling it and therefore not filtering it.
However, RFC4271 does not make such an exception for optional + transitive + partial AFAICS: [..... copy/paste deleted .....] Which basically means that you can take down every RFC-compliant 4-byte ASN honouring router today by injecting a bogus AS4_PATH attribute into the mostly 2-byte-ASN-only Internet...
Or did I miss something? I certainly hope I did.
this was brought up in the IETF IDR mailing list today. i've attached the response from that thread that addresses your reading of the RFC. -- bill
participants (4)
-
Andy Davidson -
bill fumerola -
Bjørn Mork -
Florian Weimer