On Thu, Dec 11, 2008 at 01:28:46PM +0100, bj...@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
--- Begin Message ---
Hi Kaliraj,
There are well-known correctness problems with simply discarding an
UPDATE. This gets discussed on the list every few years, every time
some implementation bug crops up which causes a lot of NOTIFICATIONS.
To date, the WG has resisted the temptation to compromise the
protocol's correctness. You do have a good point that optional
transitives are especially problematic; however, the correctness
problem still exists if you start dropping UPDATEs, so this would seem
to be a case of cutting off the patient's head to cure the flu.
Now that you bring it up though, the text from RFC 4271 you quote is
kind of bizarre:
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).
Can anyone offer an explanation of what it's supposed to mean that the
attribute MUST be discarded given that the section also says that
you're going to send a NOTIFICATION and tear down the entire session?
Seems as though the clause "the attribute MUST be discarded" should
itself be discarded.
--John
On Dec 11, 2008, at 9:11 AM, Kaliraj Vairavakkalai wrote:
RFC-4271: section "6.3 UPDATE Message Error Handling"
---------
Please consider Changing this text:
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).
To:
If an optional attribute is recognized, then the value of this
attribute MUST be checked. If an error is detected, the update
MUST be discarded, and a warning logged locally containing details
like
the attribute (type, length, and value), peer-address, as-path (may
help
in determining the originator of the malformed-attribute) etc.
Motivation behind the suggestion:
---------------------------------
This suggestion is focused on error-handling of "optional transitive
attributes" recognized by a BGP speaker receiving them. Because any
errors in the semantics of the optional-transitive-attribute will be
caught by a BGP-speaker which could be far away from the place of
origination of the error(as the speaker who don't recognize the
opt-trans-attribute will just propagate them to their peers), it may
be
good idea to be more-lenient in the way the error is handled. i.e. I
feel tearing down the BGP session with the immediate neighbor must be
avoided. Because this affects the session between two BGP speakers
neither of whom are-responsible-for(originated) the
malformed-optional-transitive-attribute.
_______________________________________________
Idr mailing list
i...@ietf.org
https://www.ietf.org/mailman/listinfo/idr
--- End Message ---
