Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes

From: [email-masked]
Date: Thu, 11 Dec 2008 14:47:58 +0000

I once worked with a BGP implementation which had a "neighbor ...  
permissive" command.

When configured, it would just log and ignore (= treat as withdraw) routes  
which were illegal in some "relatively benign way" for which the BGP RFC  
technically required a notification to be sent.

This proved useful to deal with upstream BGP bugs: rather than letting  
these bugs cause havoc and effect everyone by causing session to flap, the  
damage was more limited to a small set of routes (to give some breathing  
space while the upstream bug was addressed).

On Dec 11, 2008 9:11am, Kaliraj Vairavakkalai <[email-masked]> wrote:
> Dear Authors, IDR-list,
>
>
>
> I tend to suggest couple changes in the following RFCs:
>
>
>
> RFC-4893: In section "4.2.3. Processing Received Updates":
>
> --------
>
> Please consider Adding this text:
>
> If a NEW BGP speaker receives an Update message containing the path
>
> segment types AS_CONFED_SEQUENCE and AS_CONFED_SET [RFC3065] in the
>
> AS4_PATH attribute, it may discard the Update after logging the event
>
> 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.
>
>
>
>
>
> 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. ie 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.
>
>
>
> Thanks,
>
> Kaliraj
>
> _______________________________________________
>
> Idr mailing list
>
> [email-masked]
>
> https://www.ietf.org/mailman/listinfo/idr
>
_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr