Subject: [Idr] Thought on path attribute flag reset in draft-ietf-idr-error-handling

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Oct 2013 17:37:25 -0400

I was reviewing some implementation details about
draft-ietf-idr-error-handling earlier today.  One of the items in the draft
is the following:

:     If the "Optional bit" or the "Transitive bit" in the Attribute
:     Flags for an attribute conflicts with the Attribute Type Code,
:     then the error SHOULD be logged, and the conflicting bit in the
:     Attribute Flags MUST be reset to the correct value.  The UPDATE
:     message MUST continue to be processed.

This generally seems to be the right thing to do.  But then I thought about
the case where an implementation may choose to intentionally limit the
propagation scope of a path attribute by instead setting what should be a
transitive path attribute to non-transitive.

In internal discussions, one comment was "well, if you really mean to do
that, perhaps what you need is another path attribute".  This is perhaps
overkill.

The point of concern for this behavior is that most of our bad behaviors
over the years have been due to optional transitive issues.  I'm not aware
of implementations that intentionally downgrade path attributes to
non-transitive.  I work on an implementation that allows for path attribute
filtering.  (The wisdom of using such a dangerous feature is another
discussion.)

I'd like to hear the opinion of the working group on altering the text in
draft-error-handling to instead of "MUST be reset to the correct value" to
cover a behavior that permits not upgrading the transitiveness of the PA.
Perhaps something like the following text:

      If the "Optional bit" or the "Transitive bit" in the Attribute
      Flags for an attribute conflicts with the Attribute Type Code,
      then the error SHOULD be logged.

      If the conflicting "Optional bit" Attribute Flag would normally be
      clear (mandatory), the Attribute Flags MUST be reset to their correct
      values.

      If the conflicting "Optional bit" Attribute Flag would normally be set
      (optional), the "Optional bit" Attribute Flag MUST be properly reset
      to its correct value.  If the "Transitive bit" in the Attribute Flags
      would normally be set, but is not, the flag MAY be reset to its
      correct value.  This is to permit the downgrading of a transitive Path
      Attribute to non-transitive administratively.

      The UPDATE message MUST continue to be processed.

-- Jeff

---

From: Thomas Mangin <[email-masked]>
Date: Mon, 14 Oct 2013 23:06:59 +0100

Sent from my iPad

What you propose was what ExaBGP was doing up to a few days ago when I decided to simply log and ignore such messages ..

I tried to explain why with draft AIGP this behaviour would lead to an invalid transitive attribute 26 received via EBGP on a current OS to be able to reach its IBGP peer with AIGP enabled and possibly affect the routing of the autonomous system.

IMHO there is no excuse for such bad encoding - being liberal in what you accept does not mean that BGP should become the new HTML of networking - please not :) 

Not tearing the connection down as the invalid packet was generated a few ASN away is fair and increase stability. What you propose would make the network more vulnerable IMHO.

Thomas

---

From: <[email-masked]>
Date: Tue, 15 Oct 2013 09:32:50 +0000

Hi Jeff, all,

My 2 cents inlined.

>From: Jeffrey Haas >Sent: Monday, October 14, 2013 11:37 PM
>

Do you mean intentionally send an erroneous PA?
(IMHO, if it's not by the spec, that's an error.)

>that, perhaps what you need is another path attribute".

+1

>  This is perhaps overkill.

IMHO :s/overkill/overcostly

And we set our own cost bar so it looks like a process concern.

>From a design point of view, on eBGP sessions, I would rather call for treat as withdraw because:
- determining whether it's the speaker or the receiver which is wrong, does not seem trivial to me. And if it's the receiver, and it changes the message to fit its opinion, this opens the possibility of creating errors in multiple points in the network (all receivers having the same implementation). A point I tried to raise earlier http://www.ietf.org/mail-archive/web/idr/current/msg12053.html
- this gives an incentive to the source of errors to correct its erroneous behavior.

That being said, I'm quite sure that in the reality of operational networks, in some cases, some will prefer to keep the route (and correct the PA) in order to restore the connectivity.

So personally, on eBGP, I would call for "treat as withdraw" by default, and allowing the operator to change the behavior (e.g. attribute discard, attribute correction).

>      Attribute to non-transitive administratively.

FWIW, I'm not in favor of the spec allowing violation of the spec.

Bruno

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

_________________________________________________________________________________________________________________________

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,
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, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Oct 2013 12:08:14 -0400

> Not tearing the connection down as the invalid packet was generated a few ASN away is fair and increase stability. What you propose would make the network more vulnerable IMHO.

Perhaps my wording was unclear.  I'm saying "if it *should* be transitive
and isn't, give the user the option to leave it non-transitive".  

I'm definitely not saying upgrade it to transitive if it shouldn't be, like
with aigp.

-- Jeff

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Oct 2013 12:16:59 -0400

Bruno,

> (IMHO, if it's not by the spec, that's an error.)

I think this depends on what level of pedanticness we should consider for
the PA.  If the spec says that it should be optional-transitive and it's
marked optional-only, the flags are not consistent with the spec but the
forwarding behavior in BGP is clear all the way back to RFC 4271.  More
importantly, an implementation that doesn't understand the attribute
couldn't enforce resetting the transitive bit appropriately.

> - this gives an incentive to the source of errors to correct its erroneous behavior.

This is potentially a valid argument, but not the discussion I had hoped to
have. :-)

The current behavior in the draft is to repair the flags to the expected
positions.  

*** This does mean that it is not possible to permit, by spec, a change in
the transitiveness of the flag without allocating a new PA code point. ***

Such behavior perhaps justifies further the idea that if we want the
behavior to be altered by specficiation it will require a new code point.
(IDR chairs take note of this as being an important side effect of error
handling as specified.)

> FWIW, I'm not in favor of the spec allowing violation of the spec.

At this point I'd also appeal to you as an operator to remind you that
deleting path attributes is also somewhat out of spec.  It's also been an
unfortunately popular knob. :-/

-- Jeff

---

From: Thomas Mangin <[email-masked]>
Date: Tue, 15 Oct 2013 17:34:00 +0100

> and isn't, give the user the option to leave it non-transitive".  

Thank you for the clarification.

> I'm definitely not saying upgrade it to transitive if it shouldn't be, like

AIGP is non-transitive. I was trying to convey the case of a purposefully malicious transitive attribute 26 created to be "bounced" by a non-AIGP EBGP edge router, just passing what it does not understand.
But it seems this "attack" scenario is hard to explain and now off-topic for this thread.

Thomas

---

From: <[email-masked]>
Date: Tue, 15 Oct 2013 17:14:13 +0000

Jeff,

>From: Jeffrey Haas [mailto:[email-masked]] >Sent: Tuesday, October 15, 2013 6:17 PM
>
>Bruno,
>
>forwarding behavior in BGP is clear all the way back to RFC 4271.

Yes it's clear in RFC 4271:
- if you don't recognize it, you can't check consistency with the spec. This close any further consideration (e.g. error handling behavior)
- if you recognize if it, RFC 4271 calls for sending a notification. (now Error-handling calls for flag correction)

So the level of pedanticness seems already set by RFC 4271

>  More
>> - determining whether it's the speaker or the receiver which is wrong,
>does not seem trivial to me. And if it's the receiver, and it changes the
>message to fit its opinion, this opens the possibility of creating errors in
>multiple points in the network (all receivers having the same
>implementation). A point I tried to raise earlier http://www.ietf.org/mail-
>archive/web/idr/current/msg12053.html

Cf above, looks to me that RFC 4271 already mandates this.

>deleting path attributes is also somewhat out of spec. 

Very fair point :-)

I would however try to argue that:
- this is a local knob, not a spec (yes, this is pedantic. But for a spec, saying that "it is not by the spec, but let's however consider that this is allowed" seems a bit strange to me, except may be for a specific list of recognized attributes. But this is more or less equivalent to changing the original spec to allow both options of the flags).
- the spec does (obviously) not enforce that all router support optional attribute. Hence the router may not be able to "validate" the attribute and check that it is not erroneous. Given RFC 4271 error handling, I don't want to have all my routers supporting attribute X to shutdown their iBGP sessions, just because they recognize the attribute and didn't like the flag.
- I would rather say that this is allowed to remove attributes. E.g. MED, communities, extended communities (especially Route Target from a CE). And in the general case, RFC 4271 states a SHOULD: "Paths with
   unrecognized transitive optional attributes SHOULD be accepted.  If a path with an unrecognized transitive optional attribute is accepted [...]"

> It's also been an unfortunately popular knob. :-/

"scalded cat fears cold water" (may be a French only idiom, sorry for this)

(I'm afraid that this does not seem limited to BGP nowadays.)

Bruno

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 15 Oct 2013 13:40:51 -0400

Bruno,

> - if you recognize if it, RFC 4271 calls for sending a notification. (now Error-handling calls for flag correction)

It's obviously been too long since I've gone to that level of minutae in the
spec.  You're correct, of course.  I've just been exposed to too many
implementations that have been increasingly less picky about this due to the
long discussions on error handling we've had over the years.

I thus withdraw my proposal.

> "scalded cat fears cold water" (may be a French only idiom, sorry for this)

It's not one that I've heard before, but it's good wisdom.  Now I'll have to
look up the French for it.  (Just don't ask me to pronounce it!)

-- Jeff