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.sri...@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 <j...@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 _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
