Subject: [secdir] SECDIR review of draft-ietf-lisp-crypto-07

From: Chris Lonvick <[email-masked]>
Date: Sat, 24 Sep 2016 09:37:43 -0500

Hi Dino, Brian, and All,

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

The document is acceptable for an Experimental RFC.

I don't follow LISP so I'm not sure if there is an actual mechanism for 
a device receiving a map request packet to decline an offered cipher 
suite. If there is, I didn't see it explained in the draft. You should 
address this in a future draft. This will be needed for when new cipher 
suites are added and a receiving device does not have the capability to 
handle the new cipher suite, or the case where an old cipher suite has 
been administratively disabled; like if it's been compromised and 
shouldn't be used. There are several ways to do this.

There are a few nits in the draft you may want to take care of. First, 
Section 6 talks about setting the R bit to 0.
Current:

    The 'R' bit is not used for this use-case of the Security Type LCAF
    but is reserved for [LISP-DDT 
<https://tools.ietf.org/html/draft-ietf-lisp-crypto-07#ref-LISP-DDT>] security.  Therefore, the R bit is
    transmitted as 0 and ignored on receipt.

Proposed:
    The 'R' bit is not used for this use-case of the Security Type LCAF 
but is
    reserved for [LISP-DDT 
<https://tools.ietf.org/html/draft-ietf-lisp-crypto-07#ref-LISP-DDT>] 
security. Therefore, the R bit SHOULD be transmitted
    as 0 and MUST be ignored on receipt.

A few other things I found:
s/assymmetric/asymmetric/
s/Soon as an ETR or RTR/As soon as an ETR or RTR/
s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and 
finally key-id 3/

Best regards,
Chris

---

From: Chris Lonvick <[email-masked]>
Date: Sat, 24 Sep 2016 09:41:49 -0500

Cut-n-pasted wrong. Resending.
Thanks,
Chris

On 9/24/16 9:37 AM, Chris Lonvick wrote:
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> I don't follow LISP so I'm not sure if there is an actual mechanism 
> for a device receiving a map request packet to decline an offered 
> cipher suite. If there is, I didn't see it explained in the draft. You 
> should address this in a future draft. This will be needed for when 
> new cipher suites are added and a receiving device does not have the 
> capability to handle the new cipher suite, or the case where an old 
> cipher suite has been administratively disabled; like if it's been 
> compromised and shouldn't be used. There are several ways to do this.
>

---

From: Dino Farinacci <[email-masked]>
Date: Sun, 25 Sep 2016 14:37:45 -0700

> Cut-n-pasted wrong. Resending.

Thanks Chris, glad you did since I didn’t see the original.

>> Hi Dino, Brian, and All,
>> 
>> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.
>> 

Okay, great.

>> I don't follow LISP so I'm not sure if there is an actual mechanism for a device receiving a map request packet to decline an offered cipher suite. If there is, I didn't see it explained in the 

Yes, there is. If the Map-Reply this is returned contains no Security LCAF that means to the ITR that it either needs to go unencrypted encapsulating packets to the ETR or try another cipher text.

>> draft. You should address this in a future draft. This will be needed for when new cipher suites are 

Understand the need. We intentionally wanted to support this.

>> added and a receiving device does not have the capability to handle the new cipher suite, or the case where an old cipher suite has been administratively disabled; like if it's been compromised and shouldn't be used. There are several ways to do this.

We have this in section x of the draft. Is it not sufficient?

   If an ITR, PITR, or RTR sends a Map-Request with the Security Type
   LCAF included and the ETR or RTR does not want to have encapsulated
   traffic encrypted, they will return a Map-Reply with no RLOC records
   encoded with the Security Type LCAF.  This signals to the ITR, PITR
   or RTR not to encrypt traffic (it cannot encrypt traffic anyways
   since no ETR public-key was returned).

>> There are a few nits in the draft you may want to take care of. First, Section 6 talks about setting the R bit to 0. 
>> Current:
>> ] security.  Therefore, the R bit is
>>    The 'R' bit is not used for this use-case of the Security Type LCAF but is 
>>    reserved for [LISP-DDT] security. Therefore, the R bit SHOULD be transmitted 
>> s/followed by key-id 2, an finally key-id 3/followed by key-id 2, and finally key-id 3/ 
>> 
>> Best regards,
>> Chris

All fixed. I did not submit -08 because I wanted to see if you thought the paragraph above was sufficient. A diff and txt file in enclosed.

Thanks again,
Dino

---

From: Chris Lonvick <[email-masked]>
Date: Sun, 25 Sep 2016 20:27:28 -0500

Hi Dino,

>     since no ETR public-key was returned).
That text just says that if the cipher suite is declined then there will 
be no encryption. I was interpreting that to mean that the receiver just 
isn't going to accept any attempt at encryption. If it's just meant to 
be for that particular cipher suit then you'll need to add a line to 
that paragraph to say that the ITR, PITR, or RTR can attempt a different 
cipher suite if it is administratively configured to do so. However, 
that could get to be very inefficient if the ITR has to make 6 attempts 
before understanding that the ETR just isn't going to accept any 
encryption request - if it's so configured, or if it just doesn't 
support the feature whatsoever. So even if you allow the sender to make 
offer after offer, it would still be a good idea to have a way for the 
receiver to entirely decline encrypting packets from the sender.

But, with all that being said, I'm figuring that we're getting outside 
the intent of your experimental specification. When you do get around to 
getting this onto a standards track, then you should make some decisions 
around how to convey capabilities between the sender and receiver so 
they can quickly and efficiently figure out what's going to work, or if 
it's just not, rather than making one offer after another. TLS and SSH 
have ways for a sender to offer a list from which the receiver can 
choose, if you're looking for examples. Another way is for the sender to 
proffer a version number which is associated with a select group of 
capabilities. From that, the receiver can make a choice, or efficiently 
decline all.

Best regards,
Chris

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Mon, 26 Sep 2016 03:11:56 +0000

Hi Chris, 

Thanks for the review. I’ve added one comment below.

> On Sep 25, 2016, at 6:27 PM, Chris Lonvick <[email-masked]> wrote:
> 
> Hi Dino,
> 
> That text just says that if the cipher suite is declined then there will be no encryption. I was interpreting that to mean that the receiver just isn't going to accept any attempt at encryption. If it's just meant to be for that particular cipher suit then you'll need to add a line to that paragraph to say that the ITR, PITR, or RTR can attempt a different cipher suite if it is administratively configured to do so. However, that could get to be very inefficient if the ITR has to make 6 attempts before understanding that the ETR just isn't going to accept any encryption request - if it's so configured, or if it just doesn't support the feature whatsoever. So even if you allow the sender to make offer after offer, it would still be a good idea to have a way for the receiver to entirely decline encrypting packets from the sender.
> 
> But, with all that being said, I'm figuring that we're getting outside the intent of your experimental specification. When you do get around to getting this onto a standards track, then you should make some decisions around how to convey capabilities between the sender and receiver so they can quickly and efficiently figure out what's going to work, or if it's just not, rather than making one offer after another. TLS and SSH have ways for a sender to offer a list from which the receiver can choose, if you're looking for examples. Another way is for the sender to proffer a version number which is associated with a select group of capabilities. From that, the receiver can make a choice, or efficiently decline all.

Thanks for the suggestions. In this effort we were intentionally avoiding the complexities and added security analysis requirements of a multiple round-trip method capabilities negotiation such as TLS. But maybe a capabilities declaration more along the lines of the version number you suggest might be appropriate.  I agree that at such time as the protocol was prepared for standards-track that this would be important to add.

Thanks,
Brian

-- 
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: Dino Farinacci <[email-masked]>
Date: Mon, 26 Sep 2016 09:47:29 -0700

Chris, if you are fine with Brian’s response, I can post the -08. Please ack. Thanks.

Dino

> On Sep 25, 2016, at 8:11 PM, Brian Weis (bew) <[email-masked]> wrote:
> 
> Hi Chris, 
>

---

From: Chris Lonvick <[email-masked]>
Date: Mon, 26 Sep 2016 12:40:23 -0500

Hi Dino and Brian,

Yup - all looks good. I didn't mean to push too much on the point 
because I figured that it wasn't needed or wanted for being an 
experimental document. Good luck with it.

Best regards,
Chris

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 09:49:24 -0700

Chris, is it okay to post draft-ietf-lisp-crypto-08?

Dino

> On Sep 26, 2016, at 9:47 AM, Dino Farinacci <[email-masked]> wrote:
>

---

From: Chris Lonvick <[email-masked]>
Date: Tue, 27 Sep 2016 20:26:11 -0500

Resending - Looks like Dino didn't get this.

Best regards,
Chris

On 9/26/16 12:40 PM, Chris Lonvick wrote:
>>>>>>> I don't follow LISP so I'm not sure if there is an actual 
>>>>>>> mechanism for a device receiving a map request packet to decline 
>>>>>>> an offered cipher suite. If there is, I didn't see it explained 
>>>>>>> in the
>>>>> Yes, there is. If the Map-Reply this is returned contains no 
>>>>> Security LCAF that means to the ITR that it either needs to go 
>>>>> unencrypted encapsulating packets to the ETR or try another cipher 
>>>>> text.
>>>>>
>>>>>>>>> added and a receiving device does not have the capability to 
>>>>>>>>> handle the new cipher suite, or the case where an old cipher 
>>>>>>>>> suite has been administratively disabled; like if it's been 
>>>> That text just says that if the cipher suite is declined then there 
>>>> will be no encryption. I was interpreting that to mean that the 
>>>> receiver just isn't going to accept any attempt at encryption. If 
>>>> it's just meant to be for that particular cipher suit then you'll 
>>>> need to add a line to that paragraph to say that the ITR, PITR, or 
>>>> RTR can attempt a different cipher suite if it is administratively 
>>>> configured to do so. However, that could get to be very inefficient 
>>>> if the ITR has to make 6 attempts before understanding that the ETR 
>>>> just isn't going to accept any encryption request - if it's so 
>>>> configured, or if it just doesn't support the feature whatsoever. 
>>>> So even if you allow the sender to make offer after offer, it would 
>>>> still be a good idea to have a way for the receiver to entirely 
>>>> decline encrypting packets from the sender.
>>>>
>>>> But, with all that being said, I'm figuring that we're getting 
>>>> outside the intent of your experimental specification. When you do 
>>>> get around to getting this onto a standards track, then you should 
>>>> make some decisions around how to convey capabilities between the 
>>>> sender and receiver so they can quickly and efficiently figure out 
>>>> what's going to work, or if it's just not, rather than making one 
>>>> offer after another. TLS and SSH have ways for a sender to offer a 
>>>> list from which the receiver can choose, if you're looking for 
>>>> examples. Another way is for the sender to proffer a version number 
>>>> which is associated with a select group of capabilities. From that, 
>>>> the receiver can make a choice, or efficiently decline all.
>>> Thanks for the suggestions. In this effort we were intentionally 
>>> avoiding the complexities and added security analysis requirements 
>>> of a multiple round-trip method capabilities negotiation such as 
>>> TLS. But maybe a capabilities declaration more along the lines of 
>>> the version number you suggest might be appropriate.  I agree that 
>>> at such time as the protocol was prepared for standards-track that 
>>> this would be important to add.
>>>
>>> Thanks,
>>> Brian
>>>
>>>> Best regards,
>>>> Chris
>>> -- 
>>> Brian Weis

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 27 Sep 2016 18:28:56 -0700

Thanks. I will post -08. Thanks.

Dino

> On Sep 27, 2016, at 6:26 PM, Chris Lonvick <[email-masked]> wrote:
> 
>> Yup - all looks good. I didn't mean to push too much on the point because I figured that it wasn't needed or wanted for being an experimental document. Good luck with it.
>> 
>> Best regards,
>> Chris
>>