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

[Brian Dickson <[e-mail]>]

I see the high-level problem Chris describes, and think maybe it requires
discussing possible ways of removing doubt/ambiguity over successful
parsing of such MP_REACH and MP_UNREACH attributes.

For instance, on a given BGP session, negotiation on a per-(AFI,SAFI) is
done to establish which MP things are to be sent.
Perhaps it would be a reasonable additional requirement to have every
UPDATE include 2*N attributes for N afi/safi classes, where the 2 is REACH
and UNREACH?
Also, if IPv4 is negotiated as an MP type, should it maybe be required to
be done via MP and _not_ via non-MP (vanilla) type?

That way, only if all the REACH/UNREACH decode successfully, and
appropriate additional types are present (based on 4470 rules), it is
possible to validate that sufficient detail is available for the error
handling.

Thoughts?

Brian

On Fri, Dec 7, 2012 at 4:55 PM, Shyam Sethuram <[e-mail]> wrote:

> Hi Chris,
> On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall <[e-mail]>wrote:
>
>> Jakob Heitz wrote (on Thu 06-Dec-2012 at 18:08 +0000):
>> > Some length errors will not be detected as length errors, but as
>> > misinterpretation of subsequent bytes.
>>
>> The draft appears to be relaxing everything in sight, so there are
>> indeed few (if any) length errors per se left; or many other errors
>> for that matter.  Also, the relaxation means that almost any pair of
>> octets are acceptable Attribute Flags and Type.
>
>
> One attribute follows another. There's really no way to tell
> what pairs of octets are really acceptable as Flags and Type.
>
>
>> And, as far as I can
>> see, a final attribute which overruns the end of the attributes part
>> of the message (as defined by the 'Total Attributes Length') is also
>> acceptable.
>>
>
> You can reset the session at this point if you haven't come
> across MP_REACH so far and know that IPv4 NLRI length is 0.
>
>
>>
>> By "error" I assume we mean something which would today trigger a
>> session-reset.  By "acceptable" I mean "does not trigger a
>> session-reset" -- the result may or may not appear to be "malformed".
>> Given that most Type values are unknown, a broken length in an
>> attribute is likely to result in the rest of the attributes part of
>> the message being interpreted as a number of unknown attributes, the
>> last of which will probably overrun the end... all of which is
>> "acceptable" and only the last "malformed".
>>
>> For almost all cases of broken attribute(s), the draft requires: "the
>> UPDATE message containing the attribute MUST be treated as if all
>> contained routes had been withdrawn".
>>
>> Except, the draft does: "observe that in order to use the approach of
>> 'treat-as-withdraw', the entire NLRI field and/or the MP_REACH_NLRI
>> and MP_UNREACH_NLRI attributes need to be successfully parsed".
>>
>> It seems to me that "successfully parsing" MP_REACH_NLRI and
>> MP_UNREACH_NLRI attributes must include knowing when they are NOT
>> there.
>>
>> Suppose the code has "parsed" a set of attributes, one or more of
>> which is "malformed", and has managed to extract a valid
>> MP_UNREACH_NLRI attribute.  Should it "treat-as-withdraw" ?  The smart
>> money would be on there being an MP_REACH_NLRI somewhere amongst the
>> broken attributes... unless there were some vanilla IPv4 Unicast NLRI.
>> Also ambiguous is the case where an MP_REACH_NLRI has been extracted:
>> is there an MP_UNREACH_NLRI buried under the malformed stuff ?
>>
>> In short, as far as I can see, the draft requires:
>>
>>   * "treat-as-withdraw" for almost every conceivable case
>>     of "malformed" attribute(s).
>>
>>   * PROVIDED that MP_REACH_NLRI and MP_UNREACH_NLRI are
>>     "successfully parsed".
>>
>> which appear to be mutually exclusive in many cases :-(  The only (not
>> session-reset) case where there is no ambiguity is when *both*
>> MP_REACH_NLRI and MP_UNREACH_NLRI are present and valid -- which,
>> unfortunately, is not a very useful case in practice.  (There is also
>> no ambiguity if either MP_REACH or MP_UNREACH_NLRI is present but
>> invalid.  And no ambiguity if one or both of them is repeated.  But
>> those are session-reset cases.)
>>
>
> IMO, MP_UNREACH_NLRI does not enter the picture here. The
> test for NLRI presence for the scenario you described is limited
> to plain IPv4 NLRI and/or MP_REACH_NLRI.
>
>
>>
>
>
>> ....
>> > 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.
>>
>> Blimy.  That suggests reading beyond the various boundaries
>> established by the 'Message Length', 'Withdrawn Routes Length' and
>> 'Total Attribute Length'... surely not ?!
>>
>
> IMO there's no scenario where this is needed or implied
> by the draft.
>
> shyam
>
>
>>
>> Chris
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>>
>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr
>
>