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

Thanks Bernie!

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

_______________________________________________
dhcwg mailing list -- [email protected]
To unsubscribe send an email to [email protected]