[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320
- Subject: 91.207.218.0/23 prefix in DFZ - AS3.21 / AS196629 - announced with AS_CONFED_SEQUENCE in AS4_PATH - propagated by 35320
- From: bjorn at mork.no (Bjørn Mork)
- Date: Thu, 11 Dec 2008 13:28:46 +0100
- In-reply-to: <[email protected]> (Florian Weimer's message of "Thu, 11 Dec 2008 09:34:27 +0100")
- References: <[email protected]> <[email protected]>
Florian Weimer <fweimer at 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