Reviewer: Alexey Melnikov Review result: Has Nits 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 security aspect of LISP is addressed not only in this draft but also in draft-ietf-lisp-rfc6833bis and in RFC7835. If I understood correctly, LISP-SEC builds on top of draft-ietf-lisp-rfc6833bis and it addresses a part of the threats mentioned in RFC7835. From my reading of the document it seems to address threats specified in Section 4 of this draft. I have a few questions about the document, which might or might not result in any change: 1) Use of SHA-1 versa SHA-256 in various places: 6. LISP-SEC Control Messages Details These specifications use Keyed-Hashing for Message Authentication (HMAC) in various places (as described in the following). The HMAC function AUTH-HMAC-SHA-1-96 [RFC2104] MUST be supported in LISP-SEC implementations. 6.5. Encrypting and Decrypting an OTK Implementations of this specification MUST support OTK Wrapping ID AES-KEY-WRAP-128+HKDF-SHA256 that specifies the use of the HKDF- SHA256 Key Derivation Function specified in [RFC4868] to derive a per-message encryption key (per-msg-key), as well as the AES-KEY- WRAP-128 Key Wrap algorithm used to encrypt a 128-bit OTK, according to [RFC3394]. 6.9. ITR Processing: Receiving a Map-Reply The key derivation function HKDF-SHA1-128 [RFC5869] MUST be supported. Without consistent configuration of involved entities, extra delays may be experienced. However, since HKDF-SHA1-128 is mandatory to implement, the process will eventually converge. Use of SHA-1 is generally not recommended these days, so I would like to understand why you chose to use it. Are there some backward compatibility issues or concerns about size of some fields? Also implementing just SHA-256 everywhere will make implementations simpler. As a side note, this is what I found in draft-ietf-lisp-rfc6833bis: 2. Implementations SHOULD use the 'HMAC-SHA256-128+HKDF-SHA256' as the Algorithm ID (Section 12.5) in Map-Register message (Section 5.6), and MUST NOT use 'None' or 'HMAC-SHA-1-96-None' as Algorithm ID (Section 12.5) in the Map-Register message (Section 5.6) 1: The KDF algorithm is identified by the field 'Algorithm ID' according to the table in Section 12.5. Implementations of this specification MUST implement HMAC-SHA-256-128 [RFC4868] and SHOULD implement HMAC-SHA-256-128+HKDF-SHA256 [RFC5869] . To publish an authoritative EID-to-RLOC mapping with a Map-Server using the Map-Register message, an ETR includes authentication data that is a MAC of the entire message using a key derived from the pre- shared secret. An implementation SHOULD support HMAC-SHA256- 128+HKDF-SHA256 [RFC5869]. There are some possible inconsistencies between this draft and draft-ietf-lisp-rfc6833bis. 2) In Section 7.7: 7.7. Message Privacy DTLS [RFC9147] SHOULD be used to provide communication privacy and to prevent eavesdropping, tampering, or message forgery to the messages exchanged between the ITR, Map-Resolver, Map-Server, and ETR, unless the OTK is encrypted in another way, e.g. using a pre-shared secret. Is this talking abou OTK key wrapping? If yes, then this sounds a bit misleading, considering that AES-KEY-WRAP-128+HKDF-SHA256 is "MUST implement". Best Regards, Alexey