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

["Pascal Thubert (pthubert)" <[e-mail]>]

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 <[e-mail]>
> Sent: mardi 3 avril 2018 20:25
> To: The IESG <[e-mail]>
> Cc: [e-mail]; Gabriel Montenegro
> <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]
> Subject: Benjamin Kaduk's No Record on draft-ietf-6lo-rfc6775-update-17:
> (with COMMENT)
> 
> 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.
> 
[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.


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

> 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.)
> 
[PT>] : )

> One final nit: what is the "port" involved in the Binding?  It does not sound
> like it is an IP port...
> 
[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