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

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]