Thank you Carlos and Bernie! The Security section already had some text about an on-link observer tracking IPv6 addresses belonging to a host. Based on this discussion we made the following changes: - 3 paragraphs are moved out of Security Considerations to a new Privacy Consideration section. - that text is updated so it now mentions DUID as an unique identifier which can be used for tracking - reference to Section 4.3 of [RFC7844] added. You can see the new text (not submitted to Datatracker yet) at https://wkumari.github.io/draft-wkumari-dhc-addr-notification/draft-ietf-dhc-addr-notification.html#name-privacy-considerations Please let me know if you'd like to see more changes. Thank you! On Tue, May 14, 2024 at 8:19 PM CARLOS JESUS BERNARDOS CANO <cjbc@xxxxxxxxxx> wrote: > > 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. >> >> - Bernie >> >> On 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 -- Cheers, Jen Linkova -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
