[lisp] Benjamin Kaduk's No Objection on draft-ietf-lisp-rfc6833bis-29: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-lisp-rfc6833bis-29: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lisp-rfc6833bis/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for the updates in the -28 and -29; they do resolve all my
Discuss points (and AFAICT the comment ones, too).  Just a handful of
remaining comments (mostly nits, though the last few are more
substantive).

We should probably normalize the spelling of "SHA256" vs "SHA-256" --
there is even one place where we write "HMAC-SHA-256-128+HKDF-SHA256"
with both forms in the same expression.

Abstract

   database designs.  Since these devices implement the "edge" of the
   LISP Control-Plane infrastructure, connecting EID addressable nodes
   of a LISP site, it the implementation and operational complexity of
   the overall cost and effort of deploying LISP.

nit: something seems off starting around "it the implementation".

Section 1.1

   1.  LISP-SEC MUST be implemented [I-D.ietf-lisp-sec].  This means
       that the S-bit MUST be set in the Map-Reply (Section 5.4), Map-
       Register (Section 5.6) and Encapsulated Control messages
       (Section 5.8).

nit: while this is (IMO) unambiguous, s/implemented/in force/ (or
similar) might be a more conventional way to refer to the behavior
presented in the second sentence.

Section 5.3

   "verifying Map-Request" through the mapping database to validate thge
   "piggybacked" mapping data.

nit: s/thge/the/

Section 6.1

It looks like in the process of cleaning up after "SMR-triggered
Map-Requests always go to the mapping system" we also (accidentally?)
removed a sentence about "for security reasons, an ITR MUST NOT process
unsolicited Map-Replies".  IIUC that sentence was here to motivate the
SMR/SMR-invoked-Map-Request processing, and so it no longer makes much
sense in this location, but it does still seem an important point to
make.  I could see this going in either Section 5.5 (defining the
EID-to-RLOC UDP Map-Reply processing) or Section 9 (security
considerations), though of course if you think it makes sense somewhere
else that would be fine, too.

Section 12.5

Please update the 'KDF' reference for HMAC-SHA256-128+HKDF-SHA256 to
point to RFC 5869 (not RFC 4868).

Also, please add a brief note that specifies the interpretation of the
KDF() arguments when the RFC 5869 HKDF is used.  This could be something
like:

% When HKDF [RFC5869] is used as the LISP KDF, the first argument to
% KDF() is used as the HKDF 'IKM', and the second argument to KDF() is used
% as the HKDF 'info'.

(If we were really excited we could rename 's' from being a "salt" to
being a "contextualization string", but I feel like the cost/benefit
analysis does not actually favor making that change.  I merely note it
because what we call a "salt" is different than what RFC5869 uses as
"salt", but there is not a strong requirement for consistency of
terminology across the entire RFC corpus.)