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

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" <kotikalapudi.sriram@nist.gov> wrote:

> John Scudder asked the following question in an email to the
> authors of draft-ietf-sidr-bgpsec-protocol:
> 
>> From: John G. Scudder <jgs@juniper.net>
>> 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
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr