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

[Shyam Sethuram <[e-mail]>]

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
>