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

[Benjamin Kaduk <[e-mail]>]

On Wed, Apr 04, 2018 at 08:56:50AM +0000, Pascal Thubert (pthubert) wrote:
> 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)
> > 
> > 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.
> "

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

> 
> > 
> > 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), ..."

Okay, thanks for clarifying.

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

Ah, that does make sense :)

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

Works for me.

Thanks,

Benjamin