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

["Chris Hall" <[e-mail]>]

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.  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.

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.)
   
....
> 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 ?!

Chris