Thanks Bernie!
On Tue, May 14, 2024 at 12:16 PM Bernie Volz <bevolz@xxxxxxxxx> wrote:
FYI:Regarding the privacy issue (Client Identifier), you could reference RFC 7844 (Anonymity Profiles for DHCP Clients), section 4.3.- BernieOn May 14, 2024, at 6:11 AM, CARLOS JESUS BERNARDOS CANO <cjbc@xxxxxxxxxx> wrote:Hi Jen,Thanks for the updates. Some quick comments inline below.On Tue, May 14, 2024 at 8:48 AM Jen Linkova <furry13@xxxxxxxxx> wrote:Hi Carlos,
On Fri, May 10, 2024 at 7:51 AM Carlos Jesús Bernardos via Datatracker
<noreply@xxxxxxxx> wrote:
> Based on my review, if I was on the IESG I would ballot this document as YES.
Thank you! ;)
> - At the end of section 1, it is mentioned that the mechanism described in the
> document provides parity with IPv4, by allowing a device to inform the DHCPv6
> server about a self-configured or statically configured address. Apologies for
> my ignorance on this in advance, but, is there a mechanism in IPv4 to do so for
> statically configured addresses? If so, I think adding a reference would be
> useful. If not, maybe the text can be rewritten a bit, as I would find it a bit
> unclear.
We've just submitted -12 which now says:
"This operational practice relies on the DHCP server knowing the IP
address assignments. This works quite well for IPv4 addresses, as most
addresses are either assigned by DHCP [RFC2131] or statically
configured by the network operator. For IPv6, however, this practice
is much harder to implement, as devices often self-configure IPv6
addresses via SLAAC [RFC4862].
This document provides a mechanism for a device to inform the DHCPv6
server that the device has a self-configured IPv6 address (or has a
statically configured address), and thus provides parity with IPv4, by
making DHCPv6 infrastructure aware of self-assigned IPv6 addresses."
I hope it's more clear now, pls let us know if you think further
improvements are needed.[Carlos] Fine with me, thanks!
> - It is mentioned that the client MUST include the Client Identifier option in
> the ADDRESS-REG-INFORM messages. I think this might deserve some text regarding
> how this might imply (or not) a potential privacy issue for hosts implementing
> some kind of MAC address randomization and rotation of IPv6 self-assigned
> addresses, as an observer could easily track the addresses being used and match
> those to the same device.
We don’t think this is a concern, because on-link attackers do not
need to use the client identifier to match self-assigned addresses to
devices, they can use the MAC address for that purpose.
Privacy-sensitive clients that randomize their MAC addresses should
obviously randomize their DHCPv6 Client Identifiers too. We’re not
sure this document is the right place to say so, though?[Carlos] While I agree that this is not the document to specify how to use DHCPv6 Client Identifiers, I think adding notifications that can allow an on-link attacker to match a MAC-changing device with the addresses it might be using would deserve at least a reference to the documents that have tackled the privacy issues in the past (I think there is one specifically tackling the aspects of DHCPv6).
> - It is not completely clear to me if the spec requires a client to use the
> mechanism on ALL interfaces. I mean, can a client use it just on some
> interfaces, but not all, by having configuration policies indicating on which
> ones to use it? As I read the document, it seems to imply that if it is used on
> one interface, it MUST be used on all of them.
Oh very good point, I didn't realize we are not making that part
clear. No, as the registration messame must be sent from the address
being registered (section 4.2 does say that), and the registration
support is network-specific, the client should (must) enable this on
per-interface basis.
We have added the following text to Section 4.4:
"A client with multiple interfaces MUST discover address registration
support for each interface independently. The client MUST NOT send
address registration messages on a given interface unless the client
has discovered that the interface is connected to a network which
supports address registration."[Carlos] Great, thanks!
> - Minor nit (or maybe just nothing at it is just that I’m not a native English
> speaker): “to specify the address to being registered” -> I guess the “to”
> should be removed.
Yeah, a typo, fixed![Carlos] Thanks!
--
Cheers, Jen Linkova
-- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
