Last Call Review of draft-ietf-lisp-crypto-07
review-ietf-lisp-crypto-07-secdir-lc-lonvick-2016-09-29-00

  
  
    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

] 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