Subject: Re: [Idr] Fwd: I-D Action:draft-chen-ebgp-error-handling-00.txt

From: Jeffrey Haas <[email-masked]>
Date: Wed, 13 Oct 2010 03:11:40 +0000

[I'm behind on my mail as usual.]

While I'm of somewhat mixed opinion on the the underlying assumptions of the
safety of trusting NLRI in UPDATE messages when something is wrong, this is
a clever approach.  At the very least I think that it is worth additional
exploration.

To address a specific point Jakob had made:

On Wed, Sep 08, 2010 at 07:29:01PM -0400, Jakob Heitz wrote:
> The problem is not enough redundancy in the update message.
> 
> To help, I would like to propose a "magic number" attribute.
> This would contain some constant bit pattern, like "0xAA55"
> and the remaining length of the update message. I propose that
> this attribute be added as the last attribute in the attribute
> list. It may also be added elsewhere for more redundancy, perhaps
> right after the MP_(UN)REACH.

In the case of the MP_REACH being the first attribute, if common
implementation practice was otherwise followed, the subsequent path
attribute SHOULD be the ORIGIN path attribute.  It is mandatory,
transitive, non-extended length with a known type and a value of one of
three different values.  This means we have a very clear bit pattern that we
expect to immediately follow reachability.  While this can't prevent
subsequent malformation of the UPDATE, it provides a reasonably good marker
for the end of NLRI.

To address the general issue of trusting NLRI in the presence of malformed
packets, how do you know that the NLRI sent in the UPDATE actually match the
malformed packet in question?  Something has already gone wrong - what's the
say that you're not using a stale pointer to an NLRI buffer that has just
been passed to an iovec write?  Solving this "trust, but verify" scenario
would go much further to addressing our issues, IMO.

-- Jeff