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

[Dino Farinacci <[e-mail]>]

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

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.
>> 
>> The document is acceptable for an Experimental RFC. 

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:
>>    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 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] 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

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