Subject: [sidr] bgpsec confeds bug, with fix

From: "John G. Scudder" <[email-masked]>
Date: Wed, 1 Aug 2012 17:18:02 -0700

Randy, Sandy and I realized there is a problem with confeds. As written right now, the entering-the-confed marker is applied by the first router sending the route across an internal-to-the-confed boundary (let's call this router R). It can't be applied by the external peer router sending it to the confed in EBGP, since it has no clue (that's the nature of a confed), and it can't be applied by the border router within the confed (called router B) that's receiving it from that external peer, since it doesn't apply a signature (we only do that when sending routes across EBGP, or confed-EBGP). 

So, how does router R figure out it should apply the marker? In short, it can't. After discussing a few possible solutions, we came up with two alternatives:

Have router B do the AS aliasing hack, i.e. sign to itself with pcount=0, and apply the mark on that signature.

Equivalently, we could invent some new thing to go into the signatures that has the semantics of "this is a confed entry marker". 

--John

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 3 Aug 2012 14:51:37 -0400

I don't think there is a bug.
It seems to me that the solution as written now does indeed work if it can be assumed 
that every border router within a confed knows which peers
are confed-EBGP peers and which peers are regular (external to confed) EBGP peers.
That seems to be a necessary assumption anyway. 
(The modifications you propose also assume this.)

Let us consider this example:

----(B1----B2)----(B3----B4)----(B5----B6)---->

---------AS1------------AS2------------AS3-------->

where AS1, AS2 and AS3 form a confed, and
the update is propagating from left to right;
AS1 is the entry AS;
B1, B2 are border routers in AS1;
B3, B4 are border routers in AS2;
B5, B6 are border routers in AS3.

When B1 gets an update, it propagates it to B2 without adding a new signature.
B2 looks at the signatures backwards starting from the most recently added AS.
If the confed-entry flag is not set by any preceding AS (as expected at B2 in this example), 
then B2 sets the flag, adds AS1’s signature and forwards the update to B3.
B3 propagates the update to B4 (w/o adding a new signature).
B4 does the same check as B2 did.
B4 finds a flag already set (by AS1). 
So B4 simply adds AS2’s signature and propagates to B5.  
B6 happily strips all the confed internal signatures when
it propagates the update to a regular (external to confed) EBGP peer.

One special case is when the prefix is originated from within AS1 by B1.
It seems that this case can be handled easily enough as well. 
B1 originates and sends the update without any Signature-list Block to B2.
B2 sees no prior confed-entry flag, so it sets the flag, signs and propagates 
the prefix update to B3.  

So it all works correctly! Right?
Please let me know if I am missing something. Thanks.

Sriram
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of John G. Scudder [[email-masked]]
Sent: Wednesday, Aonfeds bug, with fix

ugust 01, 2012 8:18 PM
To: sidr wg list
Subject: [sidr] bgpsec c
--John

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 3 Aug 2012 14:12:55 -0500

> then B2 sets the flag, adds AS1’s signature and forwards the update to B3.

How is B2 supposed to know that the preceding ASes in the path aren't confed members? I.e., how is it supposed to know it is in charge of setting the flag? B1 knows this by configuration, but B2 doesn't. 

One other option does occur to me however, and I'm not sure why I didn't think of it before: for *every* crossing of a confederation member border, set the flag, so it has the semantics of "this is a confederation hop" rather than the current "entering a confederation" semantics. Then on exit, strip all contiguous flagged hops. This is predicated on the observation that it's hard for a router to know if its member AS was the confederation entry point, but trivial to know it's sending the route to another member AS. 

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 3 Aug 2012 14:27:26 -0500

On Aug 3, 2012, at 2:12 PM, "John G. Scudder" <[email-masked]> wrote:

> One other option does occur to me however, and I'm not sure why I didn't think of it before: for *every* crossing of a confederation member border, set the flag, so it has the semantics of "this is a confederation hop" rather than the current "entering a confederation" semantics. Then on exit, strip all contiguous flagged hops.

P. S. I prefer this to either of the other two suggestions I sent. It's less hacky than the pcount=0 option and more faithfully mimics the semantics of AS_CONFED_SEQ. 

--John

---

From: Randy Bush <[email-masked]>
Date: Fri, 03 Aug 2012 12:34:03 -0700

> One other option does occur to me however, and I'm not sure why I
> didn't think of it before: for *every* crossing of a confederation
> member border, set the flag, so it has the semantics of "this is a
> confederation hop" rather than the current "entering a confederation"
> semantics. Then on exit, strip all contiguous flagged hops. This is
> predicated on the observation that it's hard for a router to know if
> its member AS was the confederation entry point, but trivial to know
> it's sending the route to another member AS.

i think this works

randy

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Fri, 3 Aug 2012 16:28:51 -0400

John,

Thanks. I think we have converged on this -- yes, I have seen your latest email also.
Your newer suggestion is a slight variant of my suggestion but the basic
principle is the same, namely, the semantic of the flag is changed to
"this is a confed EBGP hop" or "signing update to a confed EBGP peer". 
That is the same semantic that I was essentially using.
Please see additional comments below (response to your questions/comments).

Sriram

> How is B2 supposed to know that the preceding ASes in the path aren't confed members? I.e., how is it supposed to know it is in charge of setting the flag? B1 knows this by configuration, but B2 do…

In the method I was suggesting, all border routers within a confed (i.e., B1, B2, …, B6) 
are configured to set the flag if they are forwarding the update to a confed-EBGP peer, 
except when they see that a flag was already set by one of the preceding ASes.
This is a slightly different but similar semantics of "this is a confederation hop" that you 
are suggesting below.
So we are converging to basically the same idea as I note below.

> One other option does occur to me however, and I'm not sure why I didn't think of it before: for *every* crossing of a confederation member border, set the flag, so it has the semantics of "this is…

Yes, I like this. In my proposal, a border router does not set a flag if a one was already set by
a preceding AS. That limits it to indicating only the entry AS in the confed. But I think your extension
of that idea is better. That is, remove the condition and let each of the border routers always 
set the flag if forwarding the update to a confed-EBGP peer. 
Let there be multiple contiguous flags.

Thanks!

Sriram

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 6 Aug 2012 15:15:55 +0000

Speaking as a regular ol' member

This also matches a thought that I just sat down to write up.  

Record the usual AS_PATH type in the signature attribute, meaning that the internally added AS_PATH elements get marked as AS_CONFED_SEQ and get stripped as such at the confed border, just as for current regular BGP.

This is isomorphic to adding the confed marker on every internal peering, but simply reuses existing confed semantics.  (Rather than "more faithfully mimics"  :-)  )  See also "reduce it to a problem that has already been solved."

I found the use of pcount=0 as part of the protocol behavior to be a pity, so a way of getting around that is attractive.

--Sandy
________________________________________
From: [email-masked] [[email-masked]] on behalf of John G. Scudder [[email-masked]]
Sent: Friday, August 03, 2012 3:27 PM
To: John G. Scudder
Cc: Sriram, Kotikalapudi; sidr wg list
Subject: Re: [sidr] bgpsec confeds bug, with fix

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

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 6 Aug 2012 08:25:40 -0700

In other words, instead of a single bit flag per signature, a one-byte type code taken from the AS_PATH segment type space? I like it! This would come closer to clearing concerns about being able to represent the structure of an AS_PATH in bgpsec. (Representing the semantics is another kettle of fish, see discussions of sets.)

The only hitch with this approach in representing AS_PATH semantics is that it doesn't capture segment boundaries. These are not important between AS_{CONFED}_SEQUENCE segments, but they are meaningful between AS_{CONFED}_SETs. If you want to go for 100% fidelity, it would also be necessary to be able to represent the boundaries between segments. 

(Granted we have decided that sets are not applicable in the bgpsec world. Nonetheless I offer it as a demonstration that segment boundaries can be meaningful in an AS_PATH.)

--John

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 06 Aug 2012 15:05:52 -0400

I also think this works.

Additionally, this has the benefit of being easy to write-up (I can 
easily construct the delta from the current text). :->

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 6 Aug 2012 15:23:21 -0400

I would like to see the receiver rules deal will peers outside the cluster
who set the "entering cluster" flag maliciously.

dougm
-- 
Doug Montgomery  Mgr. Internet & Scalable Systems Research / ITL / NIST

---

From: Matt Lepinski <[email-masked]>
Date: Mon, 06 Aug 2012 15:50:42 -0400

Doug,

Sounds reasonable. What would you like those receiver rules to say? Are 
you saying that if I am a receiver and I believe that I am not a member 
of a confederation and I receive an update that has any confederation 
marking then I tear down the session (or treat as withdrawal, or 
whatever IDR tells us we do with mal-formed update messages)?

I haven't checked, but I assume their are receiver processing rules in 
RFC 5065 for receiving an update with an segment of type 
AS_Confed_Sequence (when the receiver is not in a confederation). We 
probably want to do the same thing?

- Matt Lepinski

---

From: "Murphy, Sandra" <[email-masked]>
Date: Mon, 6 Aug 2012 20:18:34 +0000

speaking as regular ol' member

How about those who set the flag stupidly or by accident?

:-)

With current change of the flag semantics to "this-is-a-inside-confed-hop", it would be difficult to cause damage by setting the flag outside the boundaries.  (Self-induced injury by a neighbor looks like the only case.)

This error was  discussed in the interim meeting - current confed processing checks for confed sequences in paths from outside-confed peers and reports the error.  Current error handling is to break the connection, but there's work in the idr to change error handling across the board, so that outcome may change.

The question was whether the bgpsec attribute handling needed to detect inappropriate confed syntax and match current bgp processing.  The reason to match current processing would be "there must be a <good> reason for current bgp to do this, let's just adopt the same".  More reduce-to-problem-already-solved.  Of course, with current bgp handling in flux, there's no guarantee that what we stipulate would continue to match.

--Sandy
________________________________________
From: [email-masked] [[email-masked]] on behalf of Montgomery, Douglas [[email-masked]]
Sent: Monday, August 06, 2012 3:23 PM
To: Matt Lepinski; [email-masked]
Subject: Re: [sidr] bgpsec confeds bug, with fix

dougm

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Mon, 6 Aug 2012 16:40:04 -0400

Sure, stupidity is indistinguishable from malus, without understanding
intent.

I wasn't proposing any specific reaction.

But if our behavior is now to strip backwards through consecutive confed
flags ... I want to make sure we are rock solid that I can't game that.

While I realize it might be hard to be a receiver to over strip and then
generate a valid signed path ... I was concerned about gaming a receiver
to over strip and then maybe regenerate an unsigned path that had been
gamed.

dougm

On 8/6/12 4:18 PM, "Murphy, Sandra" <[email-masked]> wrote:

>With current change of the flag semantics to
>"this-is-a-inside-confed-hop", it would be difficult to cause damage by
>setting the flag outside the boundaries.  (Self-induced injury by a
>neighbor looks like the only case.)
>
>This error was  discussed in the interim meeting - current confed
>processing checks for confed sequences in paths from outside-confed peers
>and reports the error.  Current error handling is to break the
>connection, but there's work in the idr to change error handling across
>the board, so that outcome may change.
>
>The question was whether the bgpsec attribute handling needed to detect
>inappropriate confed syntax and match current bgp processing.  The reason
>to match current processing would be "there must be a <good> reason for
>current bgp to do this, let's just adopt the same".  More
>reduce-to-problem-already-solved.  Of course, with current bgp handling
>in flux, there's no guarantee that what we stipulate would continue to
>match.
>
>--Sandy

---

From: "Montgomery, Douglas" <[email-masked]>
Date: Tue, 7 Aug 2012 00:21:33 -0400

RFC5065 says if you receive a confed sequence/set from a peer that isn't
in your confederation, you treat it as a malformed AS-PATH and refer to
4271 rules for such.

It is an error for a BGP speaker to receive an UPDATE message with an
   AS_PATH attribute that contains AS_CONFED_SEQUENCE or AS_CONFED_SET
   segments from a neighbor that is not located in the same
   confederation.  If a BGP speaker receives such an UPDATE message, it
   SHALL treat the message as having a malformed AS_PATH according to
   the procedures of [BGP-4
<http://tools.ietf.org/html/rfc5065#ref-BGP-4>], Section 6.3 ("UPDATE
Message Error
   Handling").
<<<

Of course, we don't have a AS-PATH so to tie up these loose ends I think I
think we would need a sentence similar to 5065 but pointing to BGPSEC's
rules for malformed PATH-SIG attributes.

dougm

---

From: Matt Lepinski <[email-masked]>
Date: Tue, 07 Aug 2012 07:39:07 -0400

Sounds reasonable.