Matt: I would prefer that the updated I-D get posted. That way, the document we are discussing is in the archive. It also makes it easy to use the datatracker diff tools.
The new Section 4.1 says: Conversely, if a BGPsec router has received a BGPsec update message (with the BGPsec_Path attribute) from a peer for a given prefix and it chooses to propagate that peer's route for the prefix, then it SHOULD propagate the route as a BGPsec update message containing the BGPsec_Path attribute. I agree with the point that is being made here, but there is an assumption that it possess a private signature key for the right algorithm suite. This point is made in another paragraph, but that paragraph does not contain a SHOULD. Therefore, I think this paragraph needs to say that it SHOULD propagate a signed BGPsec_Path attribute if it have the needed private key and certificate. Typo: s/Signature_ Blocks/Signature_Blocks/ Russ On Dec 6, 2015, at 11:56 PM, Matthew Lepinski wrote: > There was a discussion back in October in which the working group supported > significant changes to BGPsec-protocol. This was to address an identified > mis-match between what was stated (for security properties) and what was > actually achieved. > > To address these concerns, I have made substantial changes to Section 4 > (propagating update messages) and smaller changes to Section 5.2 (validation > algorithm). > > The security considerations text likely still needs to be modified, but it > would be helpful if someone in the group took a look at the new Section 4 and > provided feedback on whether the new text is in line with the conclusions > from this thread: > http://www.ietf.org/mail-archive/web/sidr/current/msg07291.html > > Thanks a lot, > - Matt Lepinski
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
