Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
From: Matthew Lepinski mlepinski.i...@gmail.commailto:mlepinski.i...@gmail.com Date: Friday, July 24, 2015 at 1:31 AM To: George, Wes wesley.geo...@twcable.commailto:wesley.geo...@twcable.com Cc: sidr@ietf.orgmailto:sidr@ietf.org sidr@ietf.orgmailto:sidr@ietf.org Subject: Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12 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. WG] I agree with your interpretation. As Randy pointed out, this is probably a case of misinterpretation due to the fact that I'm not the target audience (implementers) and thus I missed something that would have been obvious to your target audience. Thanks Wes 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
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 wesley.geo...@twcable.com 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 sidr-boun...@ietf.org on behalf of Matthew Lepinski mlepinski.i...@gmail.com Date: Monday, June 15, 2015 at 12:41 AM To: sidr@ietf.org sidr@ietf.org 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
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 sidr-boun...@ietf.orgmailto:sidr-boun...@ietf.org on behalf of Matthew Lepinski mlepinski.i...@gmail.commailto:mlepinski.i...@gmail.com Date: Monday, June 15, 2015 at 12:41 AM To: sidr@ietf.orgmailto:sidr@ietf.org sidr@ietf.orgmailto:sidr@ietf.org 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
see skip-out logic in expression evaluation a friend just whacked me for being obscure by using compiler and language geekery. sorry. when evaluating A B, if A is false, there is no sense evaluating B. A | B, if A is true, there is no sense evaluating B. this sometimes surprises new programmers when B is, for example, a function with side effects. randy ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
David, Thanks a lot for raising this issue. Based on the discussion in Dallas, I was hoping that we could just go with the clean approach of including the MP_REACH_NLRI attribute in the signature. As you correctly point out, we can't sign MP_REACH_NLRI, because the Network Address of Next Hop field within MP_REACH_NLRI changes as an update message propagates through network. (I.e., if we sign what the -12 draft says we should sign, verification will often fail.) I have just submitted a -13 version of the document that pulls out the fields from MP_REACH_NRLI which aren't changed in transit (and thus can be safely signed). - Matt Lepinski On Mon, Jun 22, 2015 at 9:21 PM, David Mandelberg da...@mandelberg.org wrote: On 2015-06-19 14:00, Sandra Murphy wrote: Anyone who commented on draft-ietf-sidr-bgpsec-protocol-11.txt is encouraged to review this version and report if your comments have or have not been addressed. My comments have been addressed, but I have some questions about the way one of them was addressed: Is the MP_REACH_NLRI encoded with or without the attribute flags and type code? Don't the values of MP_REACH_NLRI's Length of Next Hop Network Address and Network Address of Next Hop change with each hop, making it infeasible for remote ASes to verify the origin's signature? MP_REACH_NLRI has a reserved field that MUST be set to 0, and SHOULD be ignored upon receipt. If a BGPsec speaker receives an update where reserved is non-zero, what should it do? With the current text, I could interpret SHOULD be ignored upon receipt as meaning either calculate the signature using the reserved field as received or calculate the signature using all zeroes in place of the reserved field. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ 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
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
On 2015-06-19 14:00, Sandra Murphy wrote: Anyone who commented on draft-ietf-sidr-bgpsec-protocol-11.txt is encouraged to review this version and report if your comments have or have not been addressed. My comments have been addressed, but I have some questions about the way one of them was addressed: Is the MP_REACH_NLRI encoded with or without the attribute flags and type code? Don't the values of MP_REACH_NLRI's Length of Next Hop Network Address and Network Address of Next Hop change with each hop, making it infeasible for remote ASes to verify the origin's signature? MP_REACH_NLRI has a reserved field that MUST be set to 0, and SHOULD be ignored upon receipt. If a BGPsec speaker receives an update where reserved is non-zero, what should it do? With the current text, I could interpret SHOULD be ignored upon receipt as meaning either calculate the signature using the reserved field as received or calculate the signature using all zeroes in place of the reserved field. -- David Eric Mandelberg / dseomn http://david.mandelberg.org/ ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
On Jun 18, 2015, at 5:15 AM, Christopher Morrow morrowc.li...@gmail.com wrote: I think this means you are asking for a WGLC, yes? Not necessarily. The draft went into wglc in January. Matt discussed his planned response to the comments received at IETF92. This version includes those changes. If so we can ship a note to the list (here) about that... On Mon, Jun 15, 2015 at 12:41 AM, Matthew Lepinski mlepinski.i...@gmail.com wrote: 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. Anyone who commented on draft-ietf-sidr-bgpsec-protocol-11.txt is encouraged to review this version and report if your comments have or have not been addressed. The chairs will be reviewing this version as well. --Sandy, speaking as a wg co-chair - Matt Lepinski ___ 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 signature.asc Description: Message signed with OpenPGP using GPGMail ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12
I think this means you are asking for a WGLC, yes? If so we can ship a note to the list (here) about that... On Mon, Jun 15, 2015 at 12:41 AM, Matthew Lepinski mlepinski.i...@gmail.com wrote: 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 ___ 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
[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 ___ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
