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

[bill fumerola <billf () mu org>]

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


> --- Begin Message ---
>
>
> From: "John G. Scudder" <jgs () juniper net>
>
> Date: Thu, 11 Dec 2008 13:36:21 -0500
>
> 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
> Idr () ietf org
> https://www.ietf.org/mailman/listinfo/idr
>
> --- End Message ---