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

From: Matthew Lepinski <[email-masked]>
Date: Mon, 6 Jul 2015 19:26:11 -0400

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 <[email-masked]>
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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr
>

---

From: David Mandelberg <[email-masked]>
Date: Mon, 06 Jul 2015 19:54:46 -0400

The -13 revision addresses all of my questions, thanks.

On 2015-07-06 19:26, Matthew Lepinski wrote:
> 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 cant sign MP_REACH_NLRI, because the
> update message propagates through network. (I.e., if we sign what the
> -12 draft says we should sign, verification will often fail.)
>
> fields from MP_REACH_NRLI which arent changed in transit (and thus 
> can
> be safely signed).
>
> - Matt Lepinski
>
> On Mon, Jun 22, 2015 at 9:21 PM, David Mandelberg
> <[email-masked] [4]> wrote:
>
>> 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?
>>
>> Dont the values of MP_REACH_NLRIs "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 origins
>> 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".
>>
>> --
>> http://david.mandelberg.org/ [1]
>>
>> [email-masked] [2]
>> https://www.ietf.org/mailman/listinfo/sidr [3]
>
>
>
> Links:
> ------
> [1] http://david.mandelberg.org/
> [2] mailto:[email-masked]
> [3] https://www.ietf.org/mailman/listinfo/sidr
> [4] mailto:[email-masked]

---

From: "George, Wes" <[email-masked]>
Date: Fri, 10 Jul 2015 15:08:34 -0400

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jul 2015 13:25:18 -0700

see skip-out logic in expression evaluation

randy

---

From: Randy Bush <[email-masked]>
Date: Fri, 10 Jul 2015 13:35:40 -0700

> 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

---

From: Matthew Lepinski <[email-masked]>
Date: Fri, 24 Jul 2015 01:31:14 -0400

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-masked]>
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.
>
>   From: sidr <[email-masked]> on behalf of Matthew Lepinski <
> [email-masked]>
> To: "[email-masked]" <[email-masked]>
>  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.
>
> -- 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.
>

---

From: "George, Wes" <[email-masked]>
Date: Tue, 28 Jul 2015 09:19:30 -0400

From: Matthew Lepinski <[email-masked]<mailto:[email-masked]>>
Date: Friday, July 24, 2015 at 1:31 AM
To: "George, Wes" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
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