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

[Chris Lonvick <[e-mail]>]

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