Wes, Sorry for the delay. I completely agree with you that the text in 7.1 could be more clear. I appreciate your suggested change and I am happy to issue a quick revision to clarify this issue.
With regards to the validation algorithm (Section 5.2), I am not convinced there is a problem. The document currently states (at the beginning of 5.2 on page 26) that implements must have the same input/output behavior as the validation algorithm in the document. That is, my interpretation of the current text is that we don't want to mandate any particular algorithm (or rule out any potential implementation-specific optimizations), but we want every implementation to return "Valid" on the same inputs as any other implementation. I believe this means that implementations are free to "skip-out" after a failed signature verification or not as they see fit [and still be compliant with the spec either way]. That being said, I agree with you that from the point of view of a denial-of-service prevention, that we should be recommending that implementations "Skip out" after a failed signature verification. When I read the text in "Step III" on page 29 within Section 5.2, I interpret that text as indicating that implementations should skip the remaining signatures once they get a failed signature verification. If you interpret that text differently, please let me know, but in my reading of the document, I understand the 5.2 algorithm as saying implementations should "skip out" when a signature is bad. - Matt Lepinski On Fri, Jul 10, 2015 at 3:08 PM, George, Wes <[email protected]> wrote: > Matt - > > I finally got a chance to review the updates you put in for –12 and 13. > It has addressed most of the concerns I raised. Only thing I see missing is > this comment from my previous review. > > Section 5.2 - elsewhere in the document (7.3), you note that validation > should stop when an invalid signature is found. However, I see no mention > of that in the actual validation algorithm. That seems like good practice > even if there isn't a long chain of signatures to validate. > Additionally, 7.1's text "Thus, a BGPsec speaker MUST completely validate > all BGPsec update messages received from external peers." seems to > conflict with this recommendation because it says "completely". I think > it's a wording problem, i.e. We're not saying you MUST validate the > *entire* update, but rather you must validate ALL updates that you > *receive* until you encounter an invalid signature within a given update, > in which case you can stop and move to the next update. > > > Thanks, > > > > Wes > > > > From: sidr <[email protected]> on behalf of Matthew Lepinski < > [email protected]> > Date: Monday, June 15, 2015 at 12:41 AM > To: "[email protected]" <[email protected]> > Subject: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 > > I have submitted a new version of the BGPsec protocol specification. > > This version includes some minor fixes as well as all of the changes > discussed at IETF 92. (Minutes can be found here -- > http://www.ietf.org/proceedings/92/minutes/minutes-92-sidr) I believe > that all open issues with this document have been addressed. > > The only normative changes in the -12 version are the following: > -- BGPsec speakers MUST support the multi-protocol extension (RFC 4760) > -- BGPsec now signs the entire MP_REACH_NLRI attribute. (Recall that there > was an error previously where the AFI was not protected under the signature) > > I believe that this document is now ready to ship to the IESG. If you > disagree, please let me know what still needs to be addressed. > > - Matt Lepinski > > ------------------------------ > This E-mail and any of its attachments may contain Time Warner Cable > proprietary information, which is privileged, confidential, or subject to > copyright belonging to Time Warner Cable. This E-mail is intended solely > for the use of the individual or entity to which it is addressed. If you > are not the intended recipient of this E-mail, you are hereby notified that > any dissemination, distribution, copying, or action taken in relation to > the contents of and attachments to this E-mail is strictly prohibited and > may be unlawful. If you have received this E-mail in error, please notify > the sender immediately and permanently delete the original and any copy of > this E-mail and any printout. >
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
