[dhcwg] Re: Intdir telechat review of draft-ietf-dhc-addr-notification-11

[Jen Linkova <[e-mail]>]

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
<[e-mail]> wrote:
>
> Thanks Bernie!
>
> On Tue, May 14, 2024 at 12:16 PM Bernie Volz <[e-mail]> 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 <[e-mail]> wrote:
>>
>> 
>> Hi Jen,
>>
>> Thanks for the updates. Some quick comments inline below.
>>
>>
>> On Tue, May 14, 2024 at 8:48 AM Jen Linkova <[e-mail]> wrote:
>>>
>>> Hi Carlos,
>>>
>>> On Fri, May 10, 2024 at 7:51 AM Carlos Jesús Bernardos via Datatracker
>>> <[e-mail]> 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