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

From: "Chris Hall" <[email-masked]>
Date: Thu, 6 Dec 2012 13:21:33 -0000

I've been trying to adjust the error handling in Quagga bgpd to follow
this draft, without success.

If an update message arrives and there is a problem with one or more
significant attributes, then if (and only if) *all* the NLRI in the
update can be identified, then treat-as-withdraw is an excellent
alternative to crashing the entire session.

This much is clear, and clearly a step forward.  If only it were
possible to "parse" attributes individually....

....but since it is not: when faced with a broken set of attributes, I
do not see how the receiver can be certain that it has correctly and
completely identified all NLRI.

RFC4271 allows for an update to contain any and all combinations of
vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI
(also reachable and/or unreachable).  Given that one broken attribute
may obscure following ones, the receiver can be certain that it has
correctly and completely identified all NLRI if, and only if, it has
extracted *both* a complete MP_REACH_NLRI *and* a complete
MP_UNREACH_NLRI attribute.  Otherwise, the receiver must, in effect,
prove a negative: that one or both attributes were not sent.

The draft acknowledges the issue, and requires that "the MP_REACH_NLRI
or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very
first path attribute" (should that be "and/or" rather than "or" ?).
How is the receiver to know that the sender is following this new rule
?  Can it simply assume that to be the case ?  Apparently the answers
are: it cannot and may not, in that order -- since the draft also says
"... MUST still be prepared to receive these fields in any position".

If the receiver cannot know (or simply assume) that the new rule is
being followed, then given a broken set of attributes:

  * if there are vanilla IPv4 NLRI:

     - can it be assumed that there are no MP NLRI
       if none can be extracted ?

  * if there are no vanilla IPv4 NLRI:

     - can it be assumed that if MP_REACH_NLRI can be
       extracted then there will be no MP_UNREACH_NLRI ?

     - if the only attribute is MP_UNREACH_NLRI then
       everything is fine.

       But if any other attribute is present, if no 
       MP_REACH_NLRI can be extracted, should the
       receiver assume that one is missing (hidden by
       a broken attribute) ?

       The answer to that appears, currently, to be yes.
       But that excludes, forever, the ability to attach
       extra information to a withdraw update.

     - if neither MP_REACH_NLRI nor MP_UNREACH_NLRI
       can be extracted, can it be assumed that this
       is an empty UPDATE ?  Or is this a session-
       crashing-error ?

Of course, if the session is only carrying vanilla IPv4 Unicast, life
is easy.

But otherwise, it seems to me that in order to make use of the
"treat-as-withdraw" mechanism, the receiver of a broken set of
attributes has to make some significant assumptions about the
behaviour of the sender.  I do not know which, if any, of those
assumptions it is safe to make.

I am, of course, assuming that having received a broken UPDATE, it is
*essential* to avoid continuing with the session unless *all* NLRI
referred to in that UPDATE have been "treated-as-withdraw".

Chris

---

From: "Saikat Ray (sairay)" <[email-masked]>
Date: Thu, 6 Dec 2012 16:25:23 +0000

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Chris Hall
Sent: Thursday, December 06, 2012 5:22 AM
To: [email-masked]
Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-03.txt

I've been trying to adjust the error handling in Quagga bgpd to follow this draft, without success.

If an update message arrives and there is a problem with one or more significant attributes, then if (and only if) *all* the NLRI in the update can be identified, then treat-as-withdraw is an excellent alternative to crashing the entire session.

This much is clear, and clearly a step forward.  If only it were possible to "parse" attributes individually....

[SR] In which way is the attribute "broken"? If the receiver ever thinks/knows that it has lost the sync 
         (i.e., the knowledge of TLV to byte mapping) on the tcp stream, it must reset the session.
         So if an attribute is broken because of any length issue, the session needs to be reset.

....but since it is not: when faced with a broken set of attributes, I do not see how the receiver can be certain that it has correctly and completely identified all NLRI.

RFC4271 allows for an update to contain any and all combinations of vanilla IPv4 Unicast NLRI (reachable and/or unreachable) and MP NLRI (also reachable and/or unreachable).  Given that one broken attribute may obscure following ones, the receiver can be certain that it has correctly and completely identified all NLRI if, and only if, it has extracted *both* a complete MP_REACH_NLRI *and* a complete MP_UNREACH_NLRI attribute.  Otherwise, the receiver must, in effect, prove a negative: that one or both attributes were not sent.

The draft acknowledges the issue, and requires that "the MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if present) SHALL be encoded as the very first path attribute" (should that be "and/or" rather than "or" ?).
How is the receiver to know that the sender is following this new rule ?  Can it simply assume that to be the case ?  Apparently the answers
are: it cannot and may not, in that order -- since the draft also says "... MUST still be prepared to receive these fields in any position".

If the receiver cannot know (or simply assume) that the new rule is being followed, then given a broken set of attributes:

Of course, if the session is only carrying vanilla IPv4 Unicast, life is easy.

But otherwise, it seems to me that in order to make use of the "treat-as-withdraw" mechanism, the receiver of a broken set of attributes has to make some significant assumptions about the behaviour of the sender.  I do not know which, if any, of those assumptions it is safe to make.

I am, of course, assuming that having received a broken UPDATE, it is
*essential* to avoid continuing with the session unless *all* NLRI referred to in that UPDATE have been "treated-as-withdraw".

Chris

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 6 Dec 2012 18:07:38 +0000

Some length errors will not be detected as length errors, but as misinterpretation of subsequent bytes.

You must accept receipt of any legal combinations of NLRI and attributes, even if they seem weird.

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.

--
Jakob Heitz.

---

From: "Chris Hall" <[email-masked]>
Date: Fri, 7 Dec 2012 12:41:22 -0000

> 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

---

From: Enke Chen <[email-masked]>
Date: Fri, 07 Dec 2012 11:17:20 -0800

Hi, Chris:

> "... MUST still be prepared to receive these fields in any position".

When parsing the path attributes, the receiver knows definitely whether 
the MP_REACH_NLRI or MP_UNREACH_NLRI attribute is the very first path 
attribute.

If it is the first path attribute, life would be better w.r.t the error 
handling. If it is not (as is the case with the old code), it can be 
tricky and disruptive.  The situation will progressively improve with 
the continuous rollout of new code.

Another practical detail that helps error handling in some cases is that 
vendors are not encoding multiple NLRI fields in one UPDATE message (as 
least I am not aware of any that does).

-- Enke

---

From: Shyam Sethuram <[email-masked]>
Date: Fri, 7 Dec 2012 13:55:41 -0800

Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall <[email-masked]>wrote:

> 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

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.

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

> 'Total Attribute Length'... surely not ?!

IMO there's no scenario where this is needed or implied
by the draft.

shyam

---

From: Brian Dickson <[email-masked]>
Date: Fri, 7 Dec 2012 18:12:57 -0500

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

---

From: Jakob Heitz <[email-masked]>
Date: Fri, 7 Dec 2012 23:23:23 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Dickson
Sent: Friday, December 07, 2012 3:13 PM
To: Shyam Sethuram
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Chris,
On Fri, Dec 7, 2012 at 4:41 AM, Chris Hall <[email-masked]<mailto:[email-masked]>> wrote:

And, as far as I can

....

shyam

Chris

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

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

---

From: "Chris Hall" <[email-masked]>
Date: Sat, 8 Dec 2012 11:20:50 -0000

Shyam Sethuram wrote (on Fri 07-Dec-2012 at 21:56 +0000):
...
> what pairs of octets are really acceptable as Flags and Type.
 
Currently, for both known and unknown Types there are some (small)
restrictions on the Flags, and repeat Types are invalid.  However
strong these cross-checks are, the draft relaxes them.

For known Types there are known restrictions on the length.  The draft
relaxes all those cross-checks too.

...
> across MP_REACH so far and know that IPv4 NLRI length is 0.
 
Indeed.  If you have a messed up set of attributes and no NLRI in your
hands, then it's fair to assume that some NLRI have been lost, so
session-reset is the only way forward.

This is one of the few unambiguous cases.

...
> test for NLRI presence for the scenario you described is
> limited to plain IPv4 NLRI and/or MP_REACH_NLRI.
 
I suggest that failing to withdraw some routes is worse than failing
to install or update the attributes of some routes.

Suppose an MP_UNREACH_NLRI was sent, but is obscured by some broken
attribute.  If the code takes the view that MP_UNREACH_NLRI do not
matter, then routes which the sender knows should not be used, may
continue to be installed and advertised by the receiver -- and may
stay that way "forever".

Conversely, with an MP_REACH_NLRI the receiver may (a) not install a
new route (which is effectively "treat-as-withdraw"), or (b) not
update an existing route (which is bad, but may not actually matter).

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Sat, 8 Dec 2012 16:43:02 +0000

The goal of "treat as withdraw" is not to reinterpret a broken update message and continue the session, like nothing happened.

IMO, the goal is to limit the disruption caused by a session reset, while alerting a human to fix the problem that no machine can.

--
Jakob Heitz.

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 9 Dec 2012 11:37:36 -0000

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

---

From: Enke Chen <[email-masked]>
Date: Sun, 09 Dec 2012 10:26:52 -0800

Hi, Chris:

As I replied before,  the receiver knows from parsing the path 
attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first 
attribute in an UPDATE message.  It does not need a new capability to 
make that determination.

-- Enke

---

From: Brian Dickson <[email-masked]>
Date: Sun, 9 Dec 2012 15:19:55 -0500

On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen <[email-masked]> wrote:

> Hi, Chris:
>
> As I replied before,  the receiver knows from parsing the path attributes
> whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is the first attribute in
> an UPDATE message.  It does not need a new capability to make that
> determination.
>

Hi, Enke,

Yes, BUT...

The specific attributes will be first, ONLY if the sender puts them in that
order. (This is restating the obvious for effect, sorry.)

What Chris is proposing is a negotiated option where the sender COMMITS to
observing the specified order in which to send the attributes.

Without that negotiated option, there is no method of influencing the
sender's behavior.

This is not to say that SOME senders won't use that order.

However, any implementation that supports this new option negotiation, and
either defaults to or exposes a "knob" for enabling it, will then need to
use the SPECIFIC order to be compliant.

Having this in an RFC, gives customers a specific thing to point the
implementors/vendors at, for requesting support for this.

The amount of logic needed to use this specific order, versus any other
deterministic, semi-deterministic, or random order, is pretty small.

The order is a good order, IMHO. And I think the cost of doing so as a
negotiated capability is well worth it, in order to better facilitate the
desired error handling, especially
inter-vendor/inter-implementation/inter-code-train. (And standardized is
much better than potential vendor-specific ways of signaling behavior or
defaults, of course.)

 Brian

>> ______________________________**_________________
>> Idr mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>>
>
> ______________________________**_________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/idr<https://www.ietf.org/mailman/listinfo/idr>
>

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 9 Dec 2012 21:51:04 +0100

Hi Enke,

I think the draft is pretty clear reg the MP_REACH_NLRI. However as
indicated in this thread what is not clear are the following cases:

- MP_UNREACH_NLRI is not mandatory so you never know if it was not
sent after some malformed attribute -> possible solution would be to
send empty UNREACH each time after MP_REACH. Otherwise if you are not
sure sender did not include MP_UNREACH you really can not
treat-as-withdraw so session will get reset.

- Sending vanilla IPv4 reach/unreach unicast NLRI is still allowed and
receiver has no way of knowing if sender did include those or not in
addition to new SAFIs in MP_REACH - here again lack of such assurance
will cause session reset even if first MP_REACH was parsed  ->
possible solution would be to depreciate vanilla IPv4 reach/unreach
unicast NLRI if MP capabilities were negotiated.

Thx,
R.

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 9 Dec 2012 22:34:56 -0000

On Sun, Dec 9, 2012 at 1:26 PM, Enke Chen <[email-masked]> wrote:
> attributes whether the MP_REACH_NLRI and/or MP_UNREACH_NLRI is
> the first attribute in an UPDATE message.  It does not need a
> new capability to make that determination.

Well, yes, there is no escaping the fact that... if the receiver can
see an MP_REACH_NLRI attribute and it is the first attribute, the
receiver can be pretty sure that the sender sent an MP_REACH_NLRI
attribute, and (what's more) they sent it first.

The capability, in this case, serves only to provide a warm feeling
that the sender is actually doing what they have committed themselves
to.

But that's not really the purpose of the capability...

...the difficulty/ambiguity I'm trying to get past is: what conclusion
can the receiver draw if they do *not* see an MP_REACH_NLRI attribute
anywhere, and the attributes are broken.  At present the receiver
cannot tell whether:

  a) the sender sent an MP_REACH_NLRI attribute which is
     buried under the debris of the broken attribute(s),

or:

  b) the sender did not send an MP_REACH_NLRI attribute
     at all at all.

The purpose of the capability is to allow the receiver to know that
the answer is (b), because the sender is promising to send
MP_REACH_NLRI and/or MP_UNREACH_NLRI before any other attribute(s),
and hence neither of those attributes can be obscured by some other
broken attribute.

[Well... I guess we have to consider the possibility that the sender
fails to live up to their promise -- in which case the answer could
still be (a) but the receiver would assume (b).  My feeling is that
this case is not worth worrying about...] 

Similarly MP_UNREACH_NLRI on its own, and in combination with
MP_REACH_NLRI.

Clearly, if an UPDATE contains only vanilla IPv4 Unicast in the body
of the message (ie, not in any NLRI attribute), then
"treat-as-withdraw" can be applied to all the NLRI no matter how
broken the attributes -- because the NLRI in the body of the message
are quite separate from the attributes.

Where the sender always sends any NLRI attributes as the first
attributes, they are effectively separated from the rest of the
attributes.  However, the receiver has to *know* that is what the
sender will do in order to take advantage of it -- since, otherwise,
the sender is allowed to send attributes in any order.

That's where the capability comes in.

Chris

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 9 Dec 2012 22:57:01 -0000

Brian Dickson wrote (on Sun 09-Dec-2012 at 20:20 +0000)
>
> What Chris is proposing is a negotiated option where the
> sender COMMITS to observing the specified order in which
> to send the attributes.
>
> Without that negotiated option, there is no method of
> influencing the sender's behavior. 

It would be straightforward for a BGP implementation to always use the
specified order, and always announce the "capability" -- this is
essentially unilateral.

The key thing is that receivers who understand the significance of the
capability can factor that into their error handling strategy.  (And
receivers who do not understand the capability can simply ignore it.)

> This is not to say that SOME senders won't use that order.

Indeed, in the absence of the capability, the receiver has to assume
that attributes may be sent in any order (as per current RFC)...

> However, any implementation that supports this new
> option negotiation, and either defaults to or exposes
> a "knob" for enabling it, will then need to use the
> SPECIFIC order to be compliant.

...or have some "knob" to force it to assume something else.

Chris

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 9 Dec 2012 23:07:17 -0000

Jakob Heitz wrote (on Sat 08-Dec-2012 at 16:43 +0000):
> The goal of "treat as withdraw" is not to reinterpret a broken
> update message and continue the session, like nothing happened.
> 
> IMO, the goal is to limit the disruption caused by a session reset,
> while alerting a human to fix the problem that no machine can.

I guess you are suggesting that it does not then matter if a broken
UPDATE message results in some NLRI being missed, and so not
"treated-as-withdraw", and hence the receiver continues with some
invalid or out of date routes, for some time.

Clearly session-reset is a less than perfect remedy.  But in proposing
an alternative treatment, perhaps "first do no harm" is as good a
guide as any.  I think that to achieve that, one needs to be sure that
*all* NLRI in a broken update can be identified if "treat-as-withdraw"
is to be applied.  

If the intention is to "treat-as-withdraw" any NLRI which is visible,
but continue the session in any case (so, accepting the risks of
invalid or out of date routes) then I think the draft should estimate
the risks and set out a justification for this being a less-bad remedy
than session-reset.

Of course, a major issue with session-reset is that the error may well
simply be repeated, creating a ghastly cycle session-reset/restart.
It could well be better to avoiding session-reset, and continue with
some invalid or out of date routes -- or a while, defined somehow ?  I
just don't know how to demonstrate that, or how to limit the downside
of accepting that risk, etc.

"Treat-as-withdraw" is an excellent and minimally disruptive response
in those cases where all NLRI can be identified.  But it is not the
only alternative to session-reset.  If there is doubt and uncertainty
about some routes, the receiver could deem *all* routes learned from
the peer in question to be "routes-of-last-resort", which it then uses
if and only if it had nothing else, but would not advertise them to
other peers.  This is just short of a "session-reset", and avoids
falling into a cycle of session-reset/restart.

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Sun, 9 Dec 2012 23:37:21 +0000

IMO, another goal is not to require any change to the peer.
Not even a little bit.

Changing the peer behaviour (even a little bit)
is an entirely different story.

On Sunday, December 09, 2012 3:07 PM, Chris Hall <mailto:[email-masked]> wrote:

> *all* NLRI in a broken update can be identified if
> "treat-as-withdraw" is to be applied. 
> 
> the risks and set out a justification for this being a less-bad
> remedy than session-reset. 
> 

-- 
Jakob Heitz.

---

From: "Chris Hall" <[email-masked]>
Date: Sun, 9 Dec 2012 23:44:51 -0000

> and MP_UNREACH attributes.

As I wrote earlier, given a new capability, it is possible to allow
for arbitrarily broken attributes but still reliably
"treat-as-withdraw" all NLRI in an UPDATE.

This finesses the question of why one would need to allow for
arbitrarily broken attributes, because in that scenario the degree of
broken-ness is moot.

To improve error handling -- in particular, avoid session-reset --
without requiring changes at the sender end, requires a deeper
analysis.

--------------------------------

For the avoidance of doubt: the following all relates to a receiver
who cannot assume that the sender always sends NLRI attributes as the
first attributes -- ie, it applies to senders with currently RFC
compliant implementations (about whom the receiver has no special
knowledge), and hence to senders who do not send the above mentioned
new capability.

I start from the position that it is essential to identify all NLRI if
"treat-as-withdraw" is to be used.  In the general case this means
being able to identify the start of all attributes, and to be sure
that no attributes have been missed.  This rules out accepting
arbitrarily broken attributes.

For me, the first step in "parsing" attributes is to check the
"framing" (which is sort of the "lexical" level).  A set of attributes
passes the framing check if the sum of all attribute lengths is equal
to the 'Total Attributes Length'.  A set of attributes which does not
pass the framing check is, I suggest, too badly broken to allow all
NLRI to be reliably identified, and therefore cannot be handled as
"treat-as-withdraw".  This allows for all sorts of broken attribute
*except* for attributes with broken lengths.

Now, in the framing check, the 'Total Attributes Length' is,
effectively, a checksum -- but, not a very strong one.  However, it
may be considered sufficient to allow the attributes to be accepted,
such that any further errors can trigger "treat-as-withdraw", apart
from errors in the NLRI attributes. 

However, I am yet to be convinced of the value of accepting a
well-known attribute (eg. ORIGIN) if it has invalid Flags or does not
have (one of) the known valid Length(s).  I assume that accepting such
an attribute is designed to cope with for software issues at the far
end.  However, forming these attributes is very simple, well
exercised, and easily tested code.  It seems to me that this sort of
anomaly is more likely to be symptomatic of a framing issue than it is
to be a well-formed attribute which the sender has, for reasons
unknown, decided to send with unexpected Flags and/or Length.

Therefore, I think that the framing check should be augmented by some
"semantic" checks (eg ORIGIN must be not-Optional, not-Transitive and
must have Length == 1), to make up for (some of) the weakness of the
simple checksum.  This is partly because I feel the weakness of the
checksum is a potential problem -- but I confess this is not evidence
based.  It is also partly because I don't feel a strong need to allow
for such malformations in the well-known cases in any case -- this is
also not evidence based, but I have seen no evidence to the contrary,
either.

So, if one states the problem as:

  1) to qualify for "treat-as-withdraw" it must be possible to
     identify all NLRI attributes.

     And each NLRI attribute must be "well-formed".

     And repeated NLRI attributes are automatically cause
     for session-reset.

  2) for (1) the receiver must be able to identify all
     attributes -- because otherwise it cannot be sure of
     identifying all the NLRI ones.

  3) the test for being able to identify all attributes is
     that the attributes are properly "framed".

  4) the framing test may be augmented by various
     semantic constraints, at least for well-known
     attributes.

Then there is a debate to be had about each step in the argument from
(1) to (3), and the extent to which (4) should apply (if at all) and
which attributes it should apply to.

I believe this would resolve the ambiguity/contradiction in the
current draft, namely that:

  * "treat-as-withdraw" is mandated as a means to deal with
    arbitrarily broken attributes,

  * but cannot be used unless all NLRI can be identified,

  * which is not possible (in the general case) for
    arbitrarily broken attributes !

Resolution of the issue limits the degree of broken-ness which is
acceptable.  Note that semantic nonsense inside an Optional-Transitive
attribute would be handled as "treat-as-withdraw"... which for me is
the most important case.  (I'm pretty happy dropping a session with a
peer that cannot manage to construct a well-framed set of attributes,
but dropping a session because the peer has innocently passed on a
semantically invalid attribute does upset me.)

I understand that in the well-known RIPE/Duke incident, which raised
the profile of invalid Optional-Transitive attributes, the problem was
that some routers mangled things such that the framing-check above
would have failed.  Which is a shame.

Chris

---

From: Rob Shakir <[email-masked]>
Date: Sun, 9 Dec 2012 23:46:38 +0000

Chris,

In my opinion (and as per Jakob's comment earlier in the thread) you are looking at the treat-as-withdraw behaviour in the wrong way. I have written multiple messages about this previously, but let me reiterate some of the discussions.

The current BGP implementation of session reset optimises solely to make sure it maintaining single device RIB consistency, and knowledge of correct routing information being used by that local speaker. What this misses out is the other dimension to the correctness, which is that of whether services within the network as a system are functional. Where we pursue anything around the revised error handling functionality that is being discussed in this draft, we balance the correctness of the local device's RIB, against the functionality of the overall network system.

As such, I think we have to accept that the current protocol behaviour can be *very* damaging to network deployments and hence operators of real networks are prepared to tweak this balance somewhat. The requirements draft that I am continuing to edit tries to lay out a framework whereby one can limit the amount of time over which this inconsistency may affect the network through having means by which RIB consistency may be recovered. For example, these are:

- A more selective means by which ROUTE REFRESH can be achieved (e.g., one-time ORF, using rt-constrain to refresh a subset of routes, or building upon the Enhanced GR UPDATE-VERSION message) - which allows the individual speaker to recovery consistency of the RIB.
- Better ways to be able to do session reset (the observation being that the session-level error handling causes most problems due to forwarding outages during it) - which is answered by GR based on NOTIFICATION, and Enhanced GR.

It strikes me that your analysis is aiming to ensure 100% consistency at the device level - which I think is something that we have to accept is incompatible with overall network system robustness. Can I suggest that you contribute some text to the draft as to where there are caveats (i.e., where the treat-as-withdraw mechanism may fail), and note that these are positions where a device may wish to continue to implement session level reset behaviours, or additional risk may be faced by the device?

My view is that we should *not* have a capability to indicate this behaviour. I would like a means by which I am not reliant on 3rd party actions (be it my peers in the dfz, or l3vpn deployments, or all device vendors) to begin to address a risk within my network deployments.

Kind regards,
r.

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 00:12:32 -0000

Jakob Heitz wrote (on Sun 09-Dec-2012 at 23:37 +0000)
> IMO, another goal is not to require any change to the peer.

Sure.  It would be good to be able to improve error handling
unilaterally.  As discussed elsewhere, I think it is possible to do
that, subject to some limitations.

Without those limitations, the receiver is at risk of applying
"treat-as-withdraw", but failing to identify all NLRI in the message,
and hence continuing with some invalid and/or out of date routes.  IMO
that is best avoided.  There may be a good argument for rejecting the
limitations and accepting the risk of some invalid and/or out of date
routes -- I look forward to considering it.  

> is an entirely different story.

Hmmm.  Section 3 of the draft states:

  "To facilitate the determination of the NLRI field
   in an UPDATE with a malformed attribute, the
   MP_REACH_NLRI or MP_UNREACH_NLRI attribute (if
   present) SHALL be encoded as the very first..."

which looks like a change in peer behaviour to me... but my eyesight
is not what it was ?

Chris

> On Sunday, December 09, 2012 3:07 PM, Chris Hall
> <mailto:[email-masked]> wrote:
> 
> Jakob Heitz.=

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 10 Dec 2012 00:32:41 +0000

> which looks like a change in peer behaviour to me... but my eyesight

That is not required. It is a SHALL. If the peer does it, great. If not, nothing broke.
It's different to requiring a protocol change.

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 01:06:25 -0000

Jakob Heitz wrote (on Mon 10-Dec-2012 at 00:33 +0000):
> On Dec 9, 2012, at 4:12 PM, Chris Hall wrote:
....
> > which looks like a change in peer behaviour to me... but my
> > eyesight is not what it was ?

> That is not required. It is a SHALL. If the peer does it, great. If
> not, nothing broke.  It's different to requiring a protocol change.

Dunno where this is getting us, but RFC2119:

  1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean
     that the definition is an absolute requirement of the
     specification.

FWIW I loathe this use of SHALL -- MUST is more direct and obvious.

Anyway, clearly it would be best if improvements can be made to error
handling without requiring both ends to change.

Chris

---

From: Jeff Wheeler <[email-masked]>
Date: Sun, 9 Dec 2012 21:25:53 -0500

> unknown, decided to send with unexpected Flags and/or Length.

Here is an example from two weeks ago of some routes injected to the
DFZ with malformed attribute flags.  The result was that everyone
running OpenBGPd more than a few months old, and some networks with
Alcatel routers, and who knows what else, had their BGP sessions
resetting endlessly.
http://mailman.nanog.org/pipermail/nanog/2012-November/053754.html

BGP continues to be extended for purposes it was not intended to
serve.  MBGP is really terrible, and I am sure we all know that.
Capabilities have some caveats.  Secure BGP is genuinely scary.  Soon,
BGP will be used for MAC learning in datacenter and WAN networks.

Sadly there is no improved, more robust BGP, with better sanity checks
and/or more flexibility when handling faulty messages or buggy
software.  BGP must become more robust because people continue to
extend its use with more code, and more bugs.

On Sun, Dec 9, 2012 at 6:46 PM, Rob Shakir <[email-masked]> wrote:
> It strikes me that your analysis is aiming to ensure 100% consistency at the device level - which I think is something that we have to accept is incompatible with overall network system robustness.

I agree.  I hope vendors will think hard about what default
configurations they ship, but giving operators some knobs may save
them a lot of money and stress when things go bad at 2am and they have
got to find a work-around to their problem until their vendor TAC or
in-house experts can find out what is wrong.

BGP is mission-critical for everyone.  If it stops working, you start
losing money, instantly.  The BGP protocol is the single point of
failure that we all live with.  Increasing its robustness is highly
important.  It should be done with the goal of allowing operators,
without much knowledge, to potentially work around problems until they
can actually be solved.  This should be true whether malformed updates
are the result of wrong flags, length/type errors, or ascii-art
unicorns dancing in RPKI signatures.

-- 
Jeff S Wheeler <[email-masked]>
Sr Network Operator  /  Innovative Network Concepts

---

From: <[email-masked]>
Date: Mon, 10 Dec 2012 09:48:30 +0000

Hi all,

Some personal comments on the thread/subject 

1) When we see an error, we need to balance the risk of having a few NLRI unreachable (the ones in the erroneous UPDATE) and the risk of having all NLRI from that session unreachable. Some people assumes that a session can be shutdown because there will be another path for the NLRIs. Unfortunately, the alternate path may also suffer from the same issue. How much the alternate path may experience the same error MAY (SHOULD?) be a point to consider in the solution.

2) Let's evaluate the case where we are not 100% sure we extracted all NLTI from an erroneous UPDATE.
In general, when a single UPDATE is faulty, the error is due to a specific attribute set by the originator. Then if we assume that both MP_REACH & MP_UNREACH are not present in the same update, then only the NLRIs from the originator are impacted. Given that this is the one who played with the attribute, this seems fair to me that the originator is the one who assume that risk.
This may call for not mixing both MP_REACH & MP_UNREACH in the same UPDATE message.

3) We need a short term solution which is local, i.e. not requiring change on peers, in order to be able to deploy it (soon).
That being done, if this turn out to be too limiting/risky, IMO we could also explore a more long term solution requiring a cooperation from the peer. GR based notification & enhanced GR are examples. IMO solutions requiring interop with peers are also deployable, especially within an AS, which is the aspects which concern me the most (i.e. loosing both iBGP client sessions).

4)
>exercised, and easily tested code.  

I could agree if and only if we are 100% sure to only kill the "far end" which is responsible for the error.
On the contrary, once the attribute has propagated, deciding to shut down the session could affect losts of NLRI on both the nominal and backup sessions. So I don't think a single (bit) error should have such consequences.

Regards,
Bruno

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: <[email-masked]>
Date: Mon, 10 Dec 2012 09:50:29 +0000

>From: [email-masked] [mailto:[email-masked]] On Behalf Of Jeff
>Wheeler
>

In that specific case, it was not a BGP protocol error, but a bug in the router receiving the UPDATE. i.e. draft-ietf-idr-error-handling would not change this.
However, this is an example that error in flags, including in well known attributes, may happen.

And in general, I agree with Jeff & Rob: BGP is mission critical to networks. Shutting it down for a wrong flag/bit should not be the first option.

>> It strikes me that your analysis is aiming to ensure 100% consistency at the
>device level - which I think is something that we have to accept is
>incompatible with overall network system robustness.
>

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 05:40:45 -0500

> However, this is an example that error in flags, including in well known attributes, may happen.

It is also an example of when more choices for fault handling would
have significantly reduced the operational impact on networks who had
the buggy routers.  If my customers who had OpenBGPd could simply
configure their router like, "bgp fault-tolerance attribute-malformed
treat-as-withdraw" they could have got themselves back online.

Because this is not allowed by the current BGP protocol, vendors have
disincentive to provide such flexibility, even though it could
sometimes help customers.  I understand why vendors do not want to
give their customers "too much rope" but as the uses for BGP continue
to expand, and more new code and new vendors continue to use it within
the network, vendors are likely to find that customers demand more
choices for handling malfunctions.

> And in general, I agree with Jeff & Rob: BGP is mission critical to networks. Shutting it down for a wrong flag/bit should not be the first option.

I would like to show a detailed example of a mistake that is not in a
TYPE or LENGTH field can make it impossible for the router to know
what prefixes are in an UPDATE.  Chris's post focused on "framing
errors" but these are unfortunately not the only kind of errors that
are serious.

Imagine if a route is originated with MPLS labels in the reachability,
and the bottom-of-stack bit is not set on any of the labels.  Do you
know what happens?  Receiving routers are not only unable to decide
what to do with this update, they can't even figure out what prefixes
the update is for, because the bottom-of-stack bit indicates to the
receiver where the prefixes actually begin.  In effect, the label data
is part of the framing.

I have made notes and illustrations on RFC3107 Pg3:
http://inconcepts.biz/~jsw/img/1120824-rfc3107pg3.jpg
Sorry this is hand-drawn and scanned into the computer but it is legible.

What should your router do if it can't even figure out what prefixes
are being updated?  It can't "treat as withdraw" but some option
better than close the session should be permissible.

I really think a wholesale modification to the BGP protocol will
eventually be necessary because of all the new uses for BGP.  Yes,
MP-BGP is allowing it to do new things, but not with the kind of fault
tolerance that customers should expect.  Improving the choices for
handling faults is clearly a good effort.  However, it is unfortunate
that there are so many kinds of bugs which require the router to make
potentially unsafe guesses.

Until there is a BGPv5 with an improved approach to length encoding
and more resilience against faulty implementation on one device
cascading to others in the network, we will continue to have
questionable solutions to bad problems.  I think it's important to
realize this so myopia about BGPv4's limits does not discourage anyone
from wanting to make it as robust as possible If The Operator decides
to configure his router using vendor-supplied robustness options.

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 13:26:56 -0000

Rob Shakir wrote (on Sun 09-Dec-2012 at 23:47 +0000):
....
> In my opinion (and as per Jakob's comment earlier in the thread) you
> are looking at the treat-as-withdraw behaviour in the wrong way. I
> have written multiple messages about this previously, but let me
> reiterate some of the discussions.

It seems to me that "treat-as-withdraw" is "safe" if, and only if, all
NLRI in a broken UPDATE can be identified.

I suggest that this can be achieved in two ways:

  a) if the sender always sends the NLRI attributes
     as the first attributes -- as per the draft,

     AND

     the receiver knows that is the case -- for which
     a capability would serve.

or:

  b) if the receiver requires (at a minimum) all
     attributes to be correctly "framed".

The advantage of (a) is that one no longer really cares how badly
broken the attributes are.  The disadvantage of (a) is that it
requires a small change to the protocol (a much smaller change than
the improved error handling, but nevertheless an extra change).

The advantage of (b) is that it can be applied without any change at
the sender end.  The disadvantage of (b) is that it will not accept
every conceivable form of broken attribute.

The advantage of "safe" "treat-as-withdraw" is that it does not
introduce any new inconsistency in the RIB -- "first do no harm".

I am not arguing that safety is essential -- I am trying to be precise
about how safety may be achieved, and what the compromises are in
doing so.  If those compromises are unacceptable, then we need to be
clear on the impact of removing the safety belt, so that it is clear
whether things are better or worse: under some circumstances we may be
thrown clear of the pile-up and avoid being burnt to a crisp, or we
may sail through the windscreen and kiss our backsides goodbye, while
on the other hand, an air-bag may be better all round; who can tell ?

> The current BGP implementation of session reset optimises solely to
> make sure it maintaining single device RIB consistency, and
> knowledge of correct routing information being used by that local
> speaker. What this misses out is the other dimension to the
> correctness, which is that of whether services within the network as
> a system are functional. Where we pursue anything around the revised
> error handling functionality that is being discussed in this draft,
> we balance the correctness of the local device's RIB, against the
> functionality of the overall network system.

Sure... session-reset is an extreme measure, and can be positively
destructive... cue sound of many babies being ejected with bathwater.

I'm happy to be counted as a fan of "safe" "treat-as-withdraw".  And
yes, that would preserve the correctness of the RIB, or at least avoid
incorrectness thereof.

In case (b) the safety of "treat-as-withdraw" means that there is an
error for which session-reset would continue to be the result --
namely a "framing" error.  For all other errors, case (b) avoids
session-reset -- hurrah !  Over time case (b) would be overtaken by
case (a), as more devices are upgraded to the new error handling.  So,
the residual session-reset cases would dwindle away.

If "framing errors" are determined to be a significant risk, then I
guess that's an incentive for the deployment of case (a).

But, "unsafe" "treat-as-withdraw" may still be better than
session-reset, which we are agreed is simply ghastly.  Inconsistencies
in the RIB may, as you say, be tolerable in the larger context of the
network, and treatable at an operational level -- getting away from
the tedious bits and stuff that I keep droning on about.

I note that the inconsistencies which may be introduced by "unsafe"
"treat-as-withdraw" are perhaps different to other inconsistencies: in
particular, the operator can no longer tell which routes are good and
which are bad.  In "unsafe" "treat-as-withdraw", each broken UPDATE
may or may not have contained some NLRI which should have been
withdrawn, or which are now out of date, but the receiver does not
know which (if any) NLRI are in that (inconsistent) state !

I note also that Appendix A of the draft waxes lyrical on the subject
of "Why not Discard UPDATE Messages".  With "unsafe"
"treat-as-withdraw" the effect is to discard *part* of the UPDATE
message -- the part which may or may not (and you cannot tell which)
contain NLRI attribute(s) which have been obscured by earlier broken
attribute(s).

I do not know how to assess the possible impact of "unsafe"
"treat-as-withdraw"... but Appendix A appears to argue against ?

It is perfectly possible that I have my hands clenched firmly around
the wrong end of this stick.  If the risk of "unsafe"
"treat-as-withdraw" is understood and it is determined that the cure
is (generally) not worse than the disease, then I can let go (yay !). 

> As such, I think we have to accept that the current protocol
> behaviour can be *very* damaging to network deployments and hence
> operators of real networks are prepared to tweak this balance
> somewhat. The requirements draft that I am continuing to edit tries
> to lay out a framework whereby one can limit the amount of time over
> which this inconsistency may affect the network through having means
> by which RIB consistency may be recovered. For example, these are:
> 
> - A more selective means by which ROUTE REFRESH can be achieved
> (e.g., one-time ORF, using rt-constrain to refresh a subset of
> routes, or building upon the Enhanced GR UPDATE-VERSION message) -
> which allows the individual speaker to recovery consistency of the
> RIB.

That appears to require the receiver to know which NLRI are no longer
consistent, which is not entirely possible with "unsafe"
"treat-as-withdraw".

> - Better ways to be able to do session reset (the observation being
> that the session-level error handling causes most problems due to
> forwarding outages during it) - which is answered by GR based on
> NOTIFICATION, and Enhanced GR.

This would not help with "unsafe" "treat-as-withdraw", since the
session-reset has been avoided in any case.

However, it would help in case (b).  So, for "framing" errors a
session-reset is required if "unsafe" "treat-as-withdraw" is to be
avoided, but that session-reset would be mitigated along with all
other (residual) session-resets.

Mind you, changes in GR will require changes at both ends, and I
suspect rather larger changes than those required for case (a) "safe"
"treat-as-withdraw" -- but I guess those GR changes are more generally
a Good Thing.

....
> My view is that we should *not* have a capability to indicate this
> behaviour. I would like a means by which I am not reliant on 3rd
> party actions (be it my peers in the dfz, or l3vpn deployments, or
> all device vendors) to begin to address a risk within my network
> deployments.

OK... to try to summarise succinctly, I think there are two levels at
which "safe" "treat-as-withdraw" may be implemented, as above:

  a) where the sender sends NLRI attributes as required by
     section 3 of the draft...

     ...PLUS a capability... without which the receiver
     cannot *know* that the sender is being helpful, and
     has to assume otherwise.

     This can tolerate any (non-NLRI attribute related)
     aberrations.  

  b) without any change at the sender end,

     ...OR where the receiver does not *know* that the
     sender is being helpful.

     This can tolerate anything except "framing" errors (as
     defined elsewhere).

Ruling out (a) limits the choice to:

  i) case (b) "safe" "treat-as-withdraw"

 ii) "unsafe" "treat-as-withdraw"

Since "unsafe" "treat-as-withdraw" gives me the screaming hab-dabs, my
view would be that starting with case (b) is a reasonable compromise,
as a first step towards case (a).  

There is obviously an incentive to deploy improved error handling.
Let us assume (for a moment) that improved error handling includes the
case (a) sender behaviour.  Early adopters reap the benefit of case
(b) improved error handling immediately on the devices where new
software is deployed.  And they reap the benefit of case (a) improved
error handling for their iBGP just as quickly as new software is
deployed across their network.  For eBGP, availability of case (a)
improved error handling depends on the strength of the incentive --
but good coverage requires only that the relatively small number of
Transit Providers adopt reasonably quickly.

However, given some way of determining the (likely ?) impact of
"unsafe" "treat-as-withdraw", then one could assess whether that is
better or worse than session-reset (under some  circumstances ?) -- in
the (unlikely ?) event that some particularly dim BGP implementation
fails to correctly frame a set of attributes.  I wish I knew where to
start to untangle this problem.

Chris

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 11:13:26 -0500

> better or worse than session-reset (under some  circumstances ?) -- in

Why is the question not answerable by one of three options?
1# ignore
2# treat-as-withdraw
3# session-reset

1# IGNORE is hazardous but probably only to the prefixes in that update (or
withdraw) which means the scope of malfunction is relatively small.  If
someone announces a bad route to the DFZ, or a buggy switch announces wrong
L3VPN information, this will not "spill over" to any other prefixes, as
long as you honor any withdraw that happened to be in the same Message but
before the damaged UPDATE.

Yes, perhaps reachability to the affected prefixes will be gone.  There
could be a loop created and packets will have to expire due to TTL until
this loop is resolved.  But either way, I think the scope of the
malfunction is only prefixes that were in the bad UPDATE.  Even if they
weren't packed into the same UPDATE they will share the same Attributes and
so the sender is likely to make the same mistake.  The exception here is if
an MP_UN?REACH_NLRI Attribute is corrupt but the native NLRI in the outside
part of the Message are not damaged.  You would be ignoring them and
causing a little bit more RIB inconsistency.

2# TREAT-AS-WITHDRAW is hazardous.  Loops could be created in a native
forwarding path (IPv4/IPv6 with no labels) but in MPLS VPNs or when using
labeled-unicast, there will not be any loops.  Reachability may be lost but
if any undamaged path is available then it will be selected as best and
installed.

The great risk is, how do you guess what the prefixes are, if the framing
is wrong?  In my view, here is one way that is rather thorough for finding
MP NLRIs:

Beginning with or following the damaged Attribute (which one?), scan for
MP_REACH_NLRI:
*AttrFlags AttrType AttrLen* AFI SAFI NextHopLen NH *0x00* PfxLen Pfx
(PfxLen Pfx){0,}

You know what AFI, SAFI you are willing to support on this BGP session
because this was determined when the session established.  If you find 0x0e
AFI SAFI sequences you will hope the next octet is NextHopLen and then look
forward that many octets, hoping to find a 0x00 which is a handy reserved
field.*  If you found that 0x00 you can see if a PfxLen follows that is a
sane length for this AFI SAFI -- you know it won't be >= 33 for IPv4 or >=
128 for IPv6, for example.  After that you expect to skip the Pfx and keep
looking for more sequences like this until you run out of AttrLen.

* for information on this reserved field, see RFC4760 Pg4; for history,
RFC2283 Pg3 "Number of SNPAs"

So for updates to prefixes you might be able to find the MP NLRIs with a
good degree of confidence even if another Attribute is damaged.

With MP_UNREACH_NLRI you can similarly search for a known pattern and hope
to find the MP NLRIs.

If you DO get tricked by the damaged packet, you will cause yourself to
withdraw routes that had nothing to do with the malfunction.  This is
unfortunate just to avoid the chance of loops on what is hopefully a
limited number of prefixes.

If the MP_REACH_NLRI or MP_UNREACH_NLRI itself is damaged then you will
have a hard time finding the prefixes.  Maybe they won't even be there at
all, so no clever pattern match to look for them would be helpful.
 Whatever the sending side did to send this bad message is unknown.

For problems with native, non-MP Messages, you really do not have as much
context while you are looking for the NLRI.  It will be hard to find them
without false-positives.  Fortunately you still have the opportunity for a
fairly good sanity check if you simply look from the end of the Message
backwards, and do a bit of consistency checking.  This sounds
computationally-expensive but I think it actually isn't.  It would not be
very hard to write an implementation of this search and test its speed.

In any case, this code will not be executed except when damaged updates are
encountered, and at that point, you can compare the computational expense
of guessing around the problem, to the expense of resetting sessions over
and over and potentially creating work all through your network.

3# SESSION-RESET everyone understands what this behavior does.

If my analysis above is correct, you could easily make an argument for
un-safe ignore.  I think un-safe withdraw is a good OPTION because I
usually believe in giving vendors lots of flexibility to offer knobs to the
operator.  The vendor can certainly decide how robust his un-safe withdraw
checks will be.  Operators can turn the knob whatever way they want, but
probably IGNORE will be smart in almost all cases.  If I could only have
one of those two things I would rather have IGNORE.

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 16:18:39 -0000

Jeff Wheeler wrote (on Mon 10-Dec-2012 at 02:26 +0000):
> > exercised, and easily tested code.  It seems to me that this 
> > sort of anomaly is more likely to be symptomatic of a framing
> > issue than it is to be a well-formed attribute which the
> > sender has, for reasons unknown, decided to send with
> > unexpected Flags and/or Length.

> DFZ with malformed attribute flags.

Evidence :-) 

> The result was that everyone

It would seem that some BGP implementation(s) managed to send an
attribute with a Flags octet with a bit set in the LS part (which by
RFC it MUST not do) and some implementation failed to ignore that
(which by RFC it MUST do).  [I guess the originator is using the LS
bits for its own nefarious purposes.]

So, we have two bugs, in a trivial operation which is common to all
attribute handling.  <sigh>

The evidence is clear: even trivially silly bugs happen.

What's more, such bugs can happen in code which is intended to improve
robustness.

So... the evidence suggests that adding more code, with the intent of
improving robustness, also adds opportunities for more bugs.

I wonder whether the requirement to ignore the meaningless bits has
improved or reduced robustness.  By tolerating meaningless rubbish,
the system manages to sweep under the carpet a failure at the sender
end.  If the rubbish was not tolerated, then one of these bugs would
never have made it out of the lab -- unless, of course, there was a
bug in the receiving code used during testing !  But the real lesson
here is not so much that fault tolerance fails to reveal faults, but
that *silent* fault tolerance does.

The draft goes further, and requires that some bits which *do* have
meaning should be ignored if their "true" value can be deduced from
other parts of the attribute.  In the light of the above, this doesn't
give me a warm feeling.  What's worse, the extra code required by the
draft is in exception paths, which 99.9...9% of the time are not
exercised.  The bugs in your example are on the main path for goodness
sake !

...
> BGP is mission-critical for everyone.  If it stops working, you
> start losing money, instantly.  The BGP protocol is the single
> point of failure that we all live with.  Increasing its
> robustness is highly important.

Amen to that.

The problem with any discussion of how to handle errors in attributes
is that it tends to start with the unspoken assumption that the
attributes in question have been correctly identified -- which means
that the discussion starts with a false or at least doubtful premise.

For example: we all know that a LOCAL_PREF attribute is neither use
nor ornament when received from an eBGP peer.  So, we honestly don't
care what the attribute says, or whether its length is correct, we can
just throw it on the floor and get on with the business of keeping the
network running.  Further, LOCAL_PREF is a well-known attribute, so we
know it's not Optional and it is Transitive, so it seems daft to worry
about the state of those bits (also the Partial bit).

BUT: to arrive at the octets which appear to be a LOCAL_PREF
attribute, unless it is the first attribute, we have stepped over one
or more earlier attributes, on the basis that each one's length is
correct.  So... what we seem to feel happy treating as a malformed
LOCAL_PREF, may actually be some part of some other attribute(s),
because some earlier attribute length is broken and we either did not
realise that, or we chose to ignore the problem (in the interests of
rubustness !).

There is no complete way to resolve this for all attributes.  For
"treat-as-withdraw", however, the key thing is to be able to identify
just the NLRI.  If any NLRI attributes are guaranteed by the sender to
be the first attributes, then the problem is finessed -- the receiver
doesn't need to care which attribute is malformed or how, it can just
"treat-as-withdraw" and move on, leaving the session running and
(presumably) the operational layer running round trying to resolve the
root cause.

Otherwise, we must consider ways to achieve an acceptable compromise
between (a) accurately identifying every attribute the sender sent,
and (b) the risk of proceeding with an incomplete set of attributes,
some of which are malformed in some way.  Noting that the goal is to
at least identify the NLRI attributes or be comfortable assuming that
one or both of MP_REACH_NLRI and MP_UNREACH_NLRI are not visible
because they are not there (and not because they are buried under a
heap of broken attribute(s)).

I'm sorry to keep harping on about this balls-aching detail, when the
real aim is to keep the network running... But, to resolve the broken
attributes problem we have to decide which part of each attribute to
trust, given that all parts may be broken.  As discussed elsewhere, if
the sum of the (apparent) attribute lengths is correct, then prima
facie we can identify all the attributes.  But, suppose we then find
(say) something which appears to be LOCAL_PREF, but whose flags or
length are incorrect, or which should not be there in the first place.
Now we must decide, on the balance of probabilities, whether this
really a broken LOCAL_PREF or actually a symptom of a more serious
problem, namely that the length(s) of some earlier attribute(s) are,
in fact, broken, and we have failed to correctly identify all
attributes.  If we have failed to identify all attributes, we may be
failing to find all the NLRI.  If we fail to find all the NLRI we may
me in more or less trouble network-state-wise.  It's a bleedin'
nightmare.

Anyway... bad cases make bad law, as they say.  So, the incident you
reference certainly says that there is no such thing as a bug which is
too trivial to make it out into the wild.  However, when faced with
deciding whether some anomaly is the symptom of a trivial bug, or the
symptom of something more serious, then (a) one might give the sending
software the benefit of the doubt, and assume it's not a trivial bug,
particularly as (b) assuming a trivial bug may well be the more
dangerous option.

> It should be done with the goal of allowing operators,
> without much knowledge, to potentially work around problems
> until they can actually be solved.  This should be true
> whether malformed updates are the result of wrong flags,
> length/type errors, or ascii-art unicorns dancing in RPKI
> signatures.

Well, perhaps what you really want is not some improved way for BGP to
automagically work around these issues, but for:

  * significantly better diagnostic information, so that
    the operator can properly assess a given problem,

  * knobs, switches and dials to patch up particular
    broken UPDATE messages, pro tem.

>From my (software) perspective, that's a more interesting challenge.
Certainly more interesting than trying to solve the intractable
problem of parsing the unparsable to some acceptable extent, TBD.  And
possibly more robust than layering more edge-cases onto the attribute
handling code !

Mind you, I suspect that operational remedies will also depend on the
accurate identification of all affected NLRI, which is the horse I
rode in on :-(

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 10 Dec 2012 16:30:58 +0000

If, at the time a bgp speaker detects a malformation in a received UPDATE, it has completely parsed at least one of:
. Withdrawn routes section
. NLRI
. MP_REACH
. MP_UNREACH
then it assumes that there are no more of these following.

A capability to say so adds nothing.
The router will behave exactly the same way.
Either way, human intervention is required to restore correct routing.

--
Jakob Heitz.

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 12:12:09 -0500

> accurate identification of all affected NLRI, which is the horse I

Yes, but I think removing the need to quickly identify the affected
NLRI, in order to get the network functioning again, is a good goal.
Most operators do not have the necessary knowledge to figure these
things out on their own.  Maybe the software can't exactly figure out
which NLRI are affected either, but it can still work around the
problem if IGNORE is one of the available options.

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 17:21:06 -0000

Jeff Wheeler wrote (on Mon 10-Dec-2012 at 16:13 +0000)
> On Mon, Dec 10, 2012 at 8:26 AM, Chris Hall

> 1# IGNORE is hazardous but probably only to the prefixes in that
>    update (or withdraw) which means the scope of malfunction is
>    relatively small.  ....

I haven't considered IGNORE because the draft appears to vote against
that pretty strongly.

....
> 2# TREAT-AS-WITHDRAW is hazardous....
....
> The great risk is, how do you guess what the prefixes are,
> if the framing is wrong?

Absolutely.

> In my view, here is one way that is rather thorough for
> finding MP NLRIs:
>
> Beginning with or following the damaged Attribute (which one?),
> scan for MP_REACH_NLRI: AttrFlags AttrType AttrLen AFI
> SAFI NextHopLen NH 0x00 PfxLen Pfx (PfxLen Pfx){0,}

....snip further description of scanning attributes to find
....MP_REACH_NLRI and MP_UNREACH_NLRI.

Well, that's an interesting idea :-)  If the only important thing to
extract from a broken set of attributes is the NLRI, then why not scan
for it and assume that there is sufficient redundancy to effectively
rule out false positives.  Interesting :-)

Chris

---

From: "Chris Hall" <[email-masked]>
Date: Mon, 10 Dec 2012 17:52:19 -0000

Jakob Heitz wrote (on Mon 10-Dec-2012 at 16:31 +0000);
> If, at the time a bgp speaker detects a malformation in a received
> UPDATE, it has completely parsed at least one of:

Sure.  The draft states that the 'Message Length', 'Withdrawn Routes
Length' and 'Total Attributes Length' must be consistent -- ie
correctly "framed".  And anything in the (vanilla IPv4 Unicast)
Withdrawn Routes and the NLRI sections must be internally consistent
prefixes.  So, if there is anything there, it can be parsed entirely
separately from the attributes.

> . MP_UNREACH

For the receiver to have parsed one or both of these, the sender must
have sent them before the first malformed attribute.

If the sender is unchanged (which I recall you were keen on) how is it
certain that either or both these attributes will precede the first
broken one ?

> then it assumes that there are no more of these following.

So, the presence, say, of an MP_REACH_NLRI attribute is deemed to
guarantee that no MP_UNREACH_NLRI will follow ?

I can quite believe that, in practice, few BGP implementations (if
any) send more than one of the above forms of NLRI in a single UPDATE
message.

But that is not a requirement of the RFC or the draft -- so the
receiver is not (strictly speaking) entitled to assume it.

What is the receiver supposed to do if it has not found any NLRI at
the point that it hits a malformed attribute ?

> The router will behave exactly the same way.

So, the receiver scans the attributes, and on the first malformed one
it stops.  Yes ?  Or, perhaps it ploughs on to the end stepping past
malformed attributes, and truncating the final attribute if it
overruns the 'Total Attributes Length'.  Yes ?

If there are any NLRI visible (and valid), then they can all be
"treated-as-withdraw".  Yes ?

Any NLRI that might be in the UPDATE, but are not visible because of
the malformed attributes, are simply ignored.  Yes ?

OK... if that is the procedure, the capability is redundant.  [I take
issue with the procedure, but won't rehearse that, again, here.]

However, the draft comes out strongly against simply ignoring the NLRI
in a broken update.  The draft also requires session-reset if the NLRI
found in the UPDATE are not 100% valid.  The procedure I understand
you to be describing (and correct me if I have misunderstood) does not
appear to be consistent with that.

> Either way, human intervention is required to restore correct

Sure.  I think the issue is how to avoid/minimise incorrect routeing
in the meantime.  Also, I kinda suspect that the human bean will be
greatly assisted if it is clear which NLRI have been affected (and
which definitely have not).

Chris

---

From: Jakob Heitz <[email-masked]>
Date: Mon, 10 Dec 2012 18:08:56 +0000

> certain that either or both these attributes will precede the first

It is not certain.
Once you have a malformed update, NOTHING is certain.
We limit the damage and call for human intervention.

> guarantee that no MP_UNREACH_NLRI will follow ?

No.

> receiver is not (strictly speaking) entitled to assume it.

It assumes the best it can to limit the damage.

> the point that it hits a malformed attribute ?

Reset the session.

> overruns the 'Total Attributes Length'.  Yes ?

It doesn't stop.
If the malformation is when reading NLRI in any of
the places, it resets the session.

> "treated-as-withdraw".  Yes ? 

No.
If an NLRI type attribute is completely parsed
and the malformation is not in a subsequent one
and the other conditions in the draft, then we treat as withdraw.

> the malformed attributes, are simply ignored.  Yes ?

yes.
Again:
Once you have a malformed update, NOTHING is certain.
We limit the damage and call for human intervention.

> which definitely have not). 

The human bean will not rely on ANY routes or information
from the broken session.

-- 
Jakob Heitz.

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 14:54:39 -0500

> certain that either or both these attributes will precede the first

Actually RFC4271 Pg24 says: "The sender of an UPDATE message SHOULD
order path attributes within the UPDATE message in ascending order of
attribute type.  The receiver of an UPDATE message MUST be prepared to
handle path attributes within UPDATE messages that are out of order."
The same text is also in RFC1771.

So the MP_UN?REACH_NLRI Attribute type codes are 14 and 15 which is
larger than most things like as_path, aggregator, and so on.

I have not tried to collect any data on what implementations are
actually doing.  I could collect some by packet dumping my BGP
sessions on an IXP in a few weeks when I have a chance to setup the
necessary equipment to make the dump.  It would be much more helpful
if someone who runs a large IXP route-server could do this analysis,
but if no such person volunteers and the data would be useful, I will
do some work on this around the holiday or in early-January.

> I haven't considered IGNORE because the draft appears to vote against

I think maybe some folks haven't imagined the failure modes of IGNORE
vs WITHDRAW, and what is actually possible to do with WITHDRAW
depending on the nature of the malformation.  Really, the
inconsistencies created by IGNORE are not too bad.  You would hope
Acme Router Co won't ship that as the default configuration of their
products and that networks won't just turn that knob on a routine
basis without understanding it.  However, in a pinch, it will actually
do only minimal damage to unrelated prefixes.

Honestly, if Messages would not pack so much unrelated changes
together, IGNORE would be fantastic.  Simply separating nominal BGP
withdraws from updates would make IGNORE quite safe.  I think many
people would argue that discouraging, or disallowing, a mixture of
withdraws and updates in a single Message will be costly, but in fact
it won't be.  You wouldn't even need to discourage or forbid this
though, vendors could choose to provide a knob to avoid mixing
withdraws and updates together with no changes to the BGP
specification.  This would be ideal but it's hard to imagine customers
actually requesting it as a feature, because vendors spent some years
convincing customers that larger TCP MSS was going to improve converge
performance, etc.

Anyway, at least vendors have this choice if they wanted to do it.
There are some consequences relating to the frequency of Message
transmissions but I do not think anyone really obeys that text because
it is stupid.

> rule out false positives.  Interesting :-)

I don't know what other way would be sensible.  The other attribute
information is not needed to effect a withdraw, only the NLRIs
themselves.

The troubling thing is that false positives could be created.  For
example, if you had a broken MP attribute toward the end of the
Message (and the RFC effectively recommends that it be put toward the
end, see above) then you can make a really big mistake and think that
some MP NLRI are native NLRI.  This means your Internet IPv4 RIB gets
withdraws from prefixes that happened to be updated or withdrawn in a
VRF within the same Message.  That is why I mentioned that BGP is
continually being extended to do new things that it is not good at.

So you can see, the false positive problem is worth thinking about
in-depth.  I am sure that's why the draft wants to move the MP
attribute to the beginning of the Message instead of the end.  It is a
smart idea if everyone would actually do it, but it isn't helpful if
the peer doesn't.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 10 Dec 2012 15:25:16 -0500

> information is not needed to effect a withdraw, only the NLRIs
It is unfortunate that UPDATE messages do not have any sort of identifier.

It would be nice to be able to have the receiver send a NOTIFICATION that
says, in effect, UPDATE #foo was garbled, please send JUST the afi/safi &
NLRI so I know what to ignore.

Maybe this could be handled via another UPDATE Attribute - the
identification for an UPDATE itself?
Then refer to this in the appropriate NOTIFICATION, type 3, new subtype,
with parameter identifying the problem UPDATE?

Then there is the question of the original UPDATE (generally on-the-fly
data). If the error happens soon enough, maybe the sender still has the
UPDATE in his/her outgoing TCP buffer?

Otherwise, this would mean having to hold onto UPDATEs for possibly longer
than desired.
(LRU for buffer management is so very convenient when it is available, of
course. Pack rat coding rules.)

And of course, this pushes the "ACK" further up the stack, from TCP to the
parent application (BGP). Again, maybe not that bad an idea, but definitely
non-trivial.

Thoughts?

(I think this is more reliable, but again requires changes to both ends.
The net benefit can be substantial, in terms of not having to "just guess"
when the UPDATE is already known to be busted.)

Brian

---

From: Jeff Wheeler <[email-masked]>
Date: Mon, 10 Dec 2012 18:16:04 -0500

> It is unfortunate that UPDATE messages do not have any sort of identifier.

My knee-jerk is that I am not very excited about your idea, but it is
useful to point out that LDP has message identifiers.  LDP needs to
keep more state around about pending LSP setup to support ordered
mode, merge, and downstream on demand, but there are also useful
diagnostic messages that will include the original message ID when
various fault conditions are observed.

> NLRI so I know what to ignore.

If this happens the NOTIFICATION should be responded to not with an
ordinary UPDATE but with one that is either a new Message Type or else
an UPDATE that has a very unambigious field which is sure not to be
confused or corrupted, signaling that this is a re-try of a previous
UPDATE and, if it can't be parsed, don't make that same NOTIFICATION
again.

But if your ultimate attempt is to ask the peer for the information
you need to effect a WITHDRAW, then you could just invent a way to
demand the peer send you that WITHDRAW.  The cool thing about that is,
then the peer can actually have knowledge of what route is broken.  It
could save that information to support investigation of the problem on
both sides of what may be an eBGP session.  At minimum, it could mark
the RIB entry so it knows that route is not advertised to you, and
this could be available on the CLI.

Now, I am not thinking that anyone will jump to implement your idea,
but my knee-jerk was "oh no!" and really, your idea has real serious
technical advantages.  Of course you observe that it has some
disadvantages too (more state on sender side.)  If one were inventing
"BGP 5" surely this ability would be sensible.  Maybe it is even a
sensible Capability for BGP today.  After all, the vendor can always
allow the operator to deactivate the Capability if they wish.

> with parameter identifying the problem UPDATE?

As long as the sender doesn't respond with another UPDATE that gets
confused and results in another NOTIFICATION in a loop.  But that is
fixable like I describe above.

> UPDATE in his/her outgoing TCP buffer?

The sender won't have the UPDATE in his TCP buffer because it is
basically guaranteed the receiver will already ACK that segment,
either before or when sending the NOTIFICATION, unless some deep TCP
stack tweaking is done to effect this.  Since the segment is ACK'd
then it will be free'd on the sender side, as there is no reason to
keep it around.  Also, extracting the *malformed* UPDATE NLRI out of
the TCP send buffer to then try to re-send it sounds like a good way
for both the sender and receiver to get confused.

But even if your specific notion of reaching into TCP is bad, your
concept is good and fooling around with TCP just isn't a very good way
to implement it.  The vendors can of course choose to implement it
however they please.

> Otherwise, this would mean having to hold onto UPDATEs for possibly longer

I guess there is no free lunch, but what costs does your idea have
other than spending some RAM to be capable of re-sending the NLRI from
a recent UPDATE, and a little bit of CPU to manage the structure
storing these recent UPDATEs?

> parent application (BGP). Again, maybe not that bad an idea, but definitely

Either it provides a fault tolerance mechanism at the cost of some
RAM+CPU and the sender evicts the information needed to re-send NLRI
after some timeout or memory limit has been reached, or else BGP
Advertisements become less of a simple advertisement and a little
closer to a request/response, except the response isn't anything more
than "understood," not like LDP where responses are requests for LSP
setup, etc.

Anyway, I think your idea is clever, but has about zero chance of
being liked by most people, because it is not that easy to implement
and the frequency of need for it to actually mitigate or prevent an
outage is extremely low.  If I were inventing "BGP 5" I would not
include the requirement for a sender to be able to re-transmit
information from an already-transmitted Message because this could
really be difficult on route-reflectors after major events, certainly
on ASBRs at IXPs or with many eBGP customers receiving DFZ, IXP
route-servers, and so on.  Instead I would just invent BGP 5 to have a
more robust Message structure and be done with silly errors that are
difficult to recover from.  By the time you go to the effort to
program your feature, you might as well just program a superior
Message structure and not have any CPU/RAM expense for
already-transmitted data.

Just my $0.02.

---

From: "Chris Hall" <[email-masked]>
Date: Tue, 11 Dec 2012 11:37:07 -0000

Jakob Heitz wrote (on Mon 10-Dec-2012 at 18:09 +0000):
> On Monday, December 10, 2012 9:52 AM, Chris Hall wrote:
....
> We limit the damage and call for human intervention.

OK.  That's the "mission statement".  As we get into the detail I
think I see where my disconnect is.

The draft gets very picky about NLRI and NLRI attributes.  The moment
it sees any malformation in those, it throws up its hands and hits the
session-reset button.  The draft allows repeat attributes of the same
type, except for NLRI attributes.  The draft uses a fair amount of
pencil explaining why simply discarding UPDATE messages is unsafe,
which suggests that "treat-as-withdraw" is the minimum requirement if
session-reset is to be avoided.

[BTW, why are repeat NLRI attributes deemed a cardinal sin
(session-reset, already) ?  If they are valid, the semantics are
entirely clear... here are some more prefixes to be
updated/withdrawn.]

The introduction to the draft states: "The goal ... is to minimise the
impact on routing ... while maintaining protocol correctness ....
removing the routes carried in the malformed UPDATE from the routing
system."

>From all that, I have been working on the assumption that "limit the
damage" implies, at a minimum, not proceeding unless all NLRI have
been identified, and can therefore be "treated-as-withdraw" -- or, at
least, not proceeding unless reasonable steps (TBD) have been taken to
identify all NLRI most of the time (also TBD).

As you say, with a malformed update "NOTHING is certain", so this is
Tricky, and the receiver has to take some view on what are reasonable
steps.  I have suggested verifying the attribute "framing" as a
minimum requirement for that.  It has also been suggested that, having
found a malformed attribute, the receiver should stop stepping through
attributes by attribute length, and scan octet-wise looking for NLRI
attribute(s).  However, if the sender is helpful, and places NLRI
attributes ahead of all others (as required by the draft) then the
receiver can stop worrying about trying to deal with attributes where
"NOTHING is certain", and can process the NLRI (effectively)
separately -- provided the receiver has some means of knowing the
sender is being helpful.

However, it seems that identifying all the NLRI is not as important as
I had understood it to be, so the receiver need take no special steps
to extract the NLRI.  So, if the sender is helpful, things will
generally work better, but otherwise it makes no difference to the
receiver.  I don't agree, but that seems to be the approach.

> > any) send more than one of the above forms of NLRI in a single
> > UPDATE message. 
> >

> It assumes the best it can to limit the damage.

What do you suggest that should be ?

In a world were "NOTHING is certain", does it matter if different
implementations make different assumptions ?  Or should the
specification require consistent behaviour in the face of uncertainty,
if nothing else, to avoid increasing that uncertainty ?

> > What is the receiver supposed to do if it has not found any NLRI
> > at the point that it hits a malformed attribute ?

> Reset the session.

We have established that the error-handling is not required to find
all NLRI.  That is, we are happy proceeding with a session where there
are some NLRI which we would prefer to have "treated-as-withdraw", but
could not.  In effect, we are prepared to tolerate a measure of
"UPDATE-discard" (Appendix A of the draft, notwithstanding).  I
suppose there is a difference between knowing that we have missed some
NLRI and not knowing whether we have found all NLRI.  However, given
the pain associated with session-reset, is there a good reason for
accepting one degree of "UPDATE-discard" and not another ?

> > So, the receiver scans the attributes, and on the first malformed
> > one it stops.  Yes ?  Or, perhaps it ploughs on to the end
> > stepping past malformed attributes, and truncating the final
> > attribute if it overruns the 'Total Attributes Length'.  Yes ?

> It doesn't stop.

So the parsing of attributes takes the Attribute Length of a malformed
attribute at face value.  Since "NOTHING is certain", it doesn't have
much choice.

If the final attribute overruns the 'Total Attributes Length' (or
there is an incomplete attribute header at the end) one thing is
certain, the attributes are badly broken -- the sender has been unable
to complete the simple task of correctly "framing" the attributes.  I
think the draft expects this case to be taken as a malformation of the
attribute.  The draft delegates the definition of malformation to the
relevant documentation for each Type of attribute.  If there is
intended to be a general or default way of dealing with this case,
then I think the draft needs to specify.

If the sum of the Attribute Lengths is exactly the 'Total Attributes
Length' (but some attribute is malformed) then "NOTHING is certain",
but it is possible/probable that all attributes have been identified.
[The degree of confidence may be increased if the Flags and Length of
known and well-known attributes are correct, and there are no repeated
attribute types, and perhaps other "semantic" information is taken
into account.]  This all matters rather more if one is trying to
identify all NLRI attributes, but not one jot or iota otherwise apart
from the diagnostics.

The draft has a binary approach to attributes, they are either
malformed or not malformed (well-formed).  Is there room for a
"semantic error" ?  That is, an attribute which is well-formed as far
as its Flags, Type, Length and, perhaps, internal structure are
concerned, but make no sense at all.  The result may still be
"treat-as-withdraw" (say) but the error does not cast doubt on the
attributes which follow.  The distinction would improve the
diagnostics.

So, it appears that the draft is taking a pretty relaxed view of what
is acceptable -- since "NOTHING is certain" why sweat it ?  I am
worried by the option to "attribute discard".  If things are not
certain, is "treat-as-withdraw" not the safer option ?  An
ATOMIC_AGGREGATE attribute, for example, is considered malformed if it
has any length other than 0.  Since nobody gives a rodent's posterior
about this attribute, it seems to make perfect sense to throw it on
the floor if it is malformed.  Except, except, the length of an
attribute also affects the attributes around it.  An ATOMIC_AGGREGATE
attribute with a length of (say) 700 octets is such obvious nonsense !
And that's to simply be discarded ?  Surely either the sender has
departed the reservation in something of a hurry, or some earlier
(possibly undetected) attribute error has thrown the parser off track
?  The balance of probabilities has to be that this is a symptom of
some problem deeper than a meaningless value for a meaningless
attribute... surely ?  If the attribute length is indeed invalid, then
the sum of all the attribute lengths is probably going to be wrong, so
this will decay into "treat-as-withdraw".  Nevertheless, I struggle to
see the point of applying "attribute discard" in any case of attribute
malformation.  IMO "attribute discard" will be appropriate for some
"semantic errors", only.

....
> > Any NLRI that might be in the UPDATE, but are not visible
> > because of the malformed attributes, are simply ignored.
> > Yes ?

> We limit the damage and call for human intervention.

Well, as above, this means it is OK to let (some, indeterminate) NLRI
fall into a state where they should have been withdrawn or are now out
of date.  So, why should session-reset *ever* be required ?
Damage-limitation-wise, avoiding session-reset is the big win... so
why not keep going no matter what, and let the human beans deal with
it... much better than falling into a cycle of
session-reset/restart/reset/... ?

>> ...  Also, I kinda suspect that the human bean will be
>> greatly assisted if it is clear which NLRI have been affected
>> (and which definitely have not). 

> The human bean will not rely on ANY routes or information

Well, even more reason to stop being picky at the protocol level, and
hence: "treat-as-withdraw" where you can, and "UPDATE-discard" the
rest ?

Chris

---

From: Jeff Wheeler <[email-masked]>
Date: Tue, 11 Dec 2012 08:52:24 -0500

On Tue, Dec 11, 2012 at 8:40 AM, Jeff Wheeler <[email-masked]> wrote:
> That part of the draft is limited to analyzing the reachability or
> fault state of individual prefixes.  It doesn't even consider that
> screwing up one prefix is potentially much worse than resetting the
> session just to maintain correctness.  Basically, it is a myopic

Oops, I meant to write, "screwing up one prefix is potentially much
BETTER than resetting the session."