Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

Some length errors will not be detected as length errors, but as misinterpretation of subsequent bytes.

You must accept receipt of any legal combinations of NLRI and attributes, even if they seem weird.

If you get a message length too long error, the most likely result will be that you misinterpret the 0xFF's as NLRI and get an NLRI length error.

--
Jakob Heitz.

On Dec 6, 2012, at 8:25 AM, "Saikat Ray (sairay)" <sairay@cisco.com> wrote:

> -----Original Message-----
> From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of Chris Hall
> Sent: Thursday, December 06, 2012 5:22 AM
> To: idr@ietf.org
> Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt
> 
> I've been trying to adjust the error handling in Quagga bgpd to follow this draft, without success.
> 
> If an update message arrives and there is a problem with one or more significant attributes, then if (and only if) *all* the NLRI in the update can be identified, then treat-as-withdraw is an excellent alternative to crashing the entire session.
> 
> This much is clear, and clearly a step forward.  If only it were possible to "parse" attributes individually....
> 
> [SR] In which way is the attribute "broken"? If the receiver ever thinks/knows that it has lost the sync 
>         (i.e., the knowledge of TLV to byte mapping) on the tcp stream, it must reset the session.
>         So if an attribute is broken because of any length issue, the session needs to be reset.
> 
> ....but since it is not: when faced with a broken set of attributes, I do not see how the receiver can be certain that it has correctly and completely identified all NLRI.
> 
> RFC4271 allows for an update to contain any and all combinations of vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reachable and/or unreachable).  Given that one broken attribute may obscure following ones, the receiver can be certain that it has correctly and completely identified all NLRI if, and only if, it has extracted *both* a complete MP_REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute.  Otherwise, the receiver must, in effect, prove a negative: that one or both attributes were not sent.
> 
> The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute" (should that be "and/or" rather than "or" ?).
> How is the receiver to know that the sender is following this new rule ?  Can it simply assume that to be the case ?  Apparently the answers
> are: it cannot and may not, in that order -- since the draft also says "... MUST still be prepared to receive these fields in any position".
> 
> If the receiver cannot know (or simply assume) that the new rule is being followed, then given a broken set of attributes:
> 
>  * if there are vanilla IPv4 NLRI:
> 
>     - can it be assumed that there are no MP NLRI
>       if none can be extracted ?
> 
>  * if there are no vanilla IPv4 NLRI:
> 
>     - can it be assumed that if MP_REACH_NLRI can be
>       extracted then there will be no MP_UNREACH_NLRI ?
> 
>     - if the only attribute is MP_UNREACH_NLRI then
>       everything is fine.
> 
>       But if any other attribute is present, if no 
>       MP_REACH_NLRI can be extracted, should the
>       receiver assume that one is missing (hidden by
>       a broken attribute) ?
> 
>       The answer to that appears, currently, to be yes.
>       But that excludes, forever, the ability to attach
>       extra information to a withdraw update.
> 
>     - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI
>       can be extracted, can it be assumed that this
>       is an empty UPDATE ?  Or is this a session-
>       crashing-error ?
> 
> Of course, if the session is only carrying vanilla IPv4 Unicast, life is easy.
> 
> But otherwise, it seems to me that in order to make use of the "treat-as-withdraw" mechanism, the receiver of a broken set of attributes has to make some significant assumptions about the behaviour of the sender.  I do not know which, if any, of those assumptions it is safe to make.
> 
> I am, of course, assuming that having received a broken UPDATE, it is
> *essential* to avoid continuing with the session unless *all* NLRI referred to in that UPDATE have been "treated-as-withdraw".
> 
> Chris
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr