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

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

Hi Jen,

The updates look good to me. Thanks!

Carlos

On Wed, May 15, 2024 at 12:21 PM Jen Linkova <[e-mail]> wrote:

> 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
>