Subject: Re: [Idr] RFC-4893 handling malformed AS4_PATH attributes
From: "John G. Scudder" <[email-masked]>
To: Kaliraj Vairavakkalai <[email-masked]>
Cc: [email-masked], [email-masked], Quaizar Vohra <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>
Date: Thu, 11 Dec 2008 13:36:21 -0500
List-Id: Inter-Domain Routing <idr.ietf.org>

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
[email-masked]
https://www.ietf.org/mailman/listinfo/idr