Re: [sidr] New Version: draft-ietf-sidr-bgpsec-protocol-12

[Matthew Lepinski <[e-mail]>]

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 <[e-mail]>
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 <[e-mail]> on behalf of Matthew Lepinski <
> [e-mail]>
> Date: Monday, June 15, 2015 at 12:41 AM
> To: "[e-mail]" <[e-mail]>
> 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.
>