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

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

Brian Dickson wrote (on Fri 07-Dec-2012 at 23:13 +0000):
>
> 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.

My suggestion, for minimal change to the protocol, would be a new
capability which would carry the undertaking that:

  * when sending MP_UNREACH_NLRI and/or MP_REACH_NLRI
    they will be the first attribute(s), and will
    appear in that order.

  * the ORIGIN attribute will be the first attribute,
    or will follow any NLRI attributes.

    Which deals with the absence of one or both NLRI
    attributes.

A receiver in possession of this new capability knows that, once it
has seen completely valid versions of these leading attributes, it can
tolerate any malformation of the following attributes, or absence of
essential attributes, etc. and "treat-as-withdraw".

The ORIGIN attribute has the value 0x0X 0x01 0x01 0x0Y -- where X is
supposed to be 0 and Y MUST be 0, 1 or 2.  This pattern is,
effectively, and "end-of-NLRI-attributes" mark.

If the new capability also meant that this attribute would always be
output with extended length and guaranteed X = 0, then the receiver
would expect to see 0x10 0x01 0x00 0x01 0x0Y -- which is a little more
unique, and offer a little more assurance that the attributes so far
are completely valid.  (But this is not essential)

(The new capability could also mean that IPv4 Unicast will not appear
both in the body of the message and in NLRI attributes -- but that is
not essential, either.)

If the sender misbehaves, and sends any NLRI attribute after the
ORIGIN then:

  a) if it is not a repeat attribute then...

       ...accept, but turn off the capability ?

       ...treat as a repeat ?

  b) if it is a repeat attribute then...

       ...session-reset, as per draft ?

  c) if the extra attribute is hidden by a preceding
     broken attribute then...

       ...the change to the relevant NLRI is lost.

The last case is BAD: the receiver will "treat-as-withdraw" the NLRI
it can see, but not those it cannot.  The risk here may be deemed
ignorable -- but needs to be assessed.

For all code which deals with BGP updates -- BGP speakers or analysers
of BGP streams etc -- the only change here is the new capability;
UPDATE messages will have attributes in a particular order (and
perhaps take a particular form) but are entirely RFC4271 compliant.

That leaves the question of what the receiver does in the absence of
the new capability... but that's another story, for another day.

Chris