Subject: [sidr] bgpsec-spec S. 4.2 comments

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 2 May 2012 10:21:32 -0400

John Scudder asked the following question in an email to the
authors of draft-ietf-sidr-bgpsec-protocol:

>From: John G. Scudder <[email-masked]>
>Date: Wed, Apr 18, 2012 at 8:00 PM
>Subject: bgpsec-spec S. 4.2 comments
>
>A few misc questions/comments I noticed while perusing S. 4.2:
>
>  "A BGPSEC speaker MUST NOT generate an update message containing the
>  BGPSEC_Path_Signatures attribute unless it has selected, as the best
>  route to the given prefix, a route that it received in an update
>  message containing the BGPSEC_Path_Signatures attribute."
>
>What's the rationale for this MUST NOT? Certainly it's an assumption of the base
>protocol, but I assume it wouldn't need to be called out here unless it bore on
>some BGPSEC-specific issue. This is relevant in the context of draft-ietf-idr-add-
>paths, which allows non-best paths to be sent in BGP.
>

The authors have agreed that the above text in the bgpsec spec 
document (quoted by John) certainly seems problematic.
The authors agreed to make the following text substitution:
(there was also consensus on this at the SIDR Interim meeting April 30, 2012):

"If a BGPSEC router has received an _unsigned_ route from a peer and
if it chooses to propagate that route, then it MUST NOT attach any
BGPSEC_Path_Signatures attribute to the corresponding update being propagated."

It was also agreed that we further add (if not already clearly stated
elsewhere in the spec):

"If a BGPSEC router has received a _signed_ update,
and if it chooses to propagate that route, then the router SHOULD propagate
the corresponding update with BGPSEC_Path_Signatures attribute
(after adding its own signature)."

These substitutions would help keep the text unambiguous, and
also inclusive of (or at least not conflicting with) draft-ietf-idr-add-paths.

Sriram

---

From: Jakob Heitz <[email-masked]>
Date: Wed, 2 May 2012 11:06:37 -0400

that's also flawed.
You should be able to sign anything that you can.

Suppose you receive it from an ibgp peer that sourced it but didn't sign it.

--
Jakob Heitz.

On May 2, 2012, at 7:21 AM, "Sriram, Kotikalapudi" <[email-masked]> wrote:

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

---

From: "Sriram, Kotikalapudi" <[email-masked]>
Date: Wed, 2 May 2012 11:43:11 -0400

>Suppose you receive it from an ibgp peer that sourced it but didn't sign it.

What a BGPSEC router does when "originating" a new BGPSEC update
is covered in Section 4.1. You are right -- the router can receive
a prefix route (without an AS path) from an ibgp peer who sourced it, 
and the method of signing that (or any prefix being originated) is in Section 4.1.
 
The discussion here (and John's comment) is related to text in Section 4.2,
where we discuss what a BGPSEC router does when "propagating" a route advertisement. 
"Propagating" connotes here that the update (or route) was received from an eBGP peer.

Sriram

---

From: Randy Bush <[email-masked]>
Date: Wed, 02 May 2012 07:58:45 -1000

> The discussion here (and John's comment) is related to text in Section
> 4.2, where we discuss what a BGPSEC router does when "propagating" a
> route advertisement.  "Propagating" connotes here that the update (or
> route) was received from an eBGP peer.

not exactly.  4.0 says

   Sections 4.1 and 4.2 cover two cases in which a BGPSEC speaker may
   generate an update message containing the BGPSEC_Path_Signatures
   attribute.  The first case is that in which the BGPSEC speaker
   originates a new route advertisement (Section 4.1).  That is, the
   BGPSEC speaker is constructing an update message in which the only AS
   to appear in the AS_PATH attribute is the speaker's own AS (normally
   appears once but may appear multiple times if AS prepending is
   applied).  The second case is that in which the BGPSEC speaker
   receives a route advertisement from a peer and then decides to
   propagate the route advertisement to an external (eBGP) peer (Section
   4.2).  That is, the BGPSEC speaker has received a BGPSEC update
   message and is constructing a new update message for the same NLRI in
   which the AS_PATH attribute will contain AS number(s) other than the
   speaker's own AS.