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
