[6lo] Benjamin Kaduk's No Record on draft-ietf-6lo-rfc6775-update-17: (with COMMENT)

[Benjamin Kaduk <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-6lo-rfc6775-update-17: No Record

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-6lo-rfc6775-update/



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

Section 6.1 has:

   Registration Ownership Verifier (ROVR):  Enables the correlation
                   between multiple attempts to register a same IPv6
                   Address.  This can be a unique ID of the Registering
                   Node, such as the EUI-64 address of an interface.
                   This can also be a token obtained with cryptographic
                   methods and used as proof of ownership of the
                   registration.  [...]

I understand that the actual crypto is (currently) in draft-ietf-6lo-ap-nd, but
from the point of view of this document, the ROVR token (or "crypto-ID" in the
terminology of 6lo-ap-nd) behaves as a bearer token.  That is, I include it
with my EARO and my registration request is authenticated and associated with
that "identity"; there is not anything in this document that ties the crypto-ID
to the EARO.  From a very quick read of the other document, it sounds like the
6LR can optionally request validation that the 6LN using the crypto-ID actually
has control of the associated private key, and is expected to do so on the
first exchange, and so arguably the transport key+LLA are what associates the
crypto-ID with the EARO.

The conclusion from the above would be that this sort of ROVR is not itself
proof of ownership of anything, so it might be better to have text like "this
can also be a token obtained with cryptographic methods which can be used in
additional protocol exchanges to associate a cryptographic identity (key) with
this registration".

In several places in section 7 it is indicated that implementations that
support this spec should always use the new data structures even when talking
to RFC6775-only peers; this generally seems fine due to the way that reserved
fields are used.  I was not entirely sure if the same holds for the use of new
status codes in the EARO, though -- do things work out okay if (e.g.) "Moved"
or "Removed" are interpreted as a generic error?

In general the Security and Privacy Considerations seem well thought-out (in
the model where Layer-2 security is already in place), thank you!   (Key
distribution remains a hard problem, of course, and sharing such keys across
groups does reduce the security properties of the system, but this is not the
right place to go into detail on such issues.)

One final nit: what is the "port" involved in the Binding?  It does not sound
like it is an IP port...