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

[CARLOS JESUS BERNARDOS CANO <[e-mail]>]

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
>