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

[Jakob Heitz <[e-mail]>]

I had previously suggested an "end of attribute list" attribute.

However, a goal of this draft is not to require any change to peers.
Anything that requires changes on both sides of a connection
is going to be radically different.

--
Jakob Heitz.



________________________________
From: [e-mail] [mailto:[e-mail]] On Behalf Of Brian Dickson
Sent: Friday, December 07, 2012 3:13 PM
To: Shyam Sethuram
Cc: [e-mail]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

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]<mailto:[e-mail]>> wrote:
Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall <[e-mail]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr


_______________________________________________
Idr mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/idr