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 <[email protected]> > > Sent: mardi 3 avril 2018 20:25 > > To: The IESG <[email protected]> > > Cc: [email protected]; Gabriel Montenegro > > <[email protected]>; [email protected]; > > [email protected]; [email protected] > > 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 _______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
