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

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 03 Apr 2018 11:24:38 -0700

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...

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 4 Apr 2018 08:56:50 +0000

Hello Benjamin

Thanks a bunch for your review; I'll keep a note to improve the text on Nonce in AP ND. 

Please see below:

> -----Original Message-----
> From: Benjamin Kaduk <[email-masked]>
> Sent: mardi 3 avril 2018 20:25
> To: The IESG <[email-masked]>
> Cc: [email-masked]; Gabriel Montenegro
> <[email-masked]>; [email-masked];
> [email-masked]; [email-masked]
> Subject: Benjamin Kaduk's No Record on draft-ietf-6lo-rfc6775-update-17:
> (with COMMENT)
> 
> 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.)
> 
> 
> 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.
> 
[PT>] 
[PT>] This is correct. Note that the ROVR does not have to be cryptographic or to be used as proof of ownership. Only AP ND does that. The original RFC 6775 places an EUI 64 in that field, and expects well behaved devices that will have globally unique MAC addresses and will not  attempt to take over addresses.
The central registrar in the 6LBR ensures first come first serve for address ownership, and maintains a state that has the ROVR in it. In the case of RFC 6775, it is used for Duplicate Address Detection, a second registration with a different EUI 64 denotes a collision, and the second registration is rejected.

> 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".
[PT>] 
[PT>] Works for me. 
The proof of the link between the ROVR and the address is actually that the ROVR is written on the 6LBR registry at registration time. What's left to be done is prove the ownership of the ROVR itself. The new paragraph would read as
"
Registration Ownership Verifier (ROVR):
        Enables the correlation between multiple attempts to register a same
        IPv6 Address. The ROVR is stored in the 6LR and the 6LBR in the state
        associated to the registration.
        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 which can be used in additional protocol exchanges
        to associate a cryptographic identity (key) with this registration
        to ensure that only the owner can modify it later.
        The scope of a ROVR is the registration of a particular 
        IPv6 Address and it cannot be used to correlate registrations of
        different addresses.
"

> 
> 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
[PT>] Yes. RFC 6775 section 8.2.5 has "In the case where the DAC indicates an error (the
   Status is non-zero), ..."

> right place to go into detail on such issues.)
[PT>] : )

> One final nit: what is the "port" involved in the Binding?  It does not sound
[PT>] Changed to "a physical port on a switch". This would apply to  a node that uses a L3 switch as sleeping proxy. 

Many thanks Benjamin, in particular for going all the way to checking AP ND operation.
Considering the limited change, I'll keep rev_18 (current draft attached) a bit more before I publish if that's OK with you.

Take care,

Pascal

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 4 Apr 2018 12:30:03 -0500

>         IPv6 Address and it cannot be used to correlate registrations of

This works for me, though the text from me does feel a bit long and
awkward.  (I have no better proposal at the moment.)

>    Status is non-zero), ..."

Okay, thanks for clarifying.

> [PT>] Changed to "a physical port on a switch". This would apply to  a node that uses a L3 switch as sleeping proxy. 

Ah, that does make sense :)

> Considering the limited change, I'll keep rev_18 (current draft attached) a bit more before I publish if that's OK with you.

Works for me.

Thanks,

Benjamin