Subject: [v6ops] Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Tue, 23 Feb 2021 14:13:32 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-v6ops-cpe-slaac-renum-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cpe-slaac-renum/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Section 3

   o  WPD-10: CE Routers MUST by default use a stable IAID value that
      does not change between CE Router restarts, DHCPv6 client
      restarts, or interface state changes. e.g., Transient PPP
      interfaces.  See Section 3.2 for further details.

The text in Section 3.2 goes into a bit more detail to clarify that this
is basically a pre-existing requirement from RFC 8415, but the short
text here is easy to misread as imposing a requirement to use a stable
persistent identifier, which would have lousy privacy properties.  RFC
8415 does acknowledge this issue to some extent, but the most applicable
text about it seems to be in Section 4.5 of RFC 7844, that clarifies
that the IAID needs to be consistent for the association *as long as the
link-layer address remains constant*, which is a very natural scope and
consistent with best practices for simultaneously changing identifiers
at different layers when needed for privacy improvement.  It would be
great if we could spend a few words here to clarify that this is not a
permanent identifier that could be abused for tracking, perhaps "(Per
[RFC8415] it is still expected to change when the link-layer address
changes.)", though I was hoping to have something shorter.

Additionally, while RFC 8415 is clear that the IAID is assigned by the
client, this text might benefit from noting (e.g.) which interface it is
used on, since the CE router will often be on both ends of different
DHCPv6 exchanges.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 17:27:36 -0300

Hello, Ben,

Thanks a lot for our comments! In-line....

On 23/2/21 19:13, Benjamin Kaduk via Datatracker wrote:
[....]
> at different layers when needed for privacy improvement. 

You're right that if the CE Router changes its link-layer address, it's 
probably because it's trying to its identity, and hence the IAID should 
also change.

(FWIW, to a large extent we phrased the text as is because I know of no 
CE Router that randomizes it's link-layer address, so in practice it 
would result in the same thing). Not surprisingly, I'm keen to improve 
the specification of this numeric id ;-), so how about:

      o  WPD-10: CE Routers MUST by default use an IAID
         value on the WAN-side that does not change between CE Router
         restarts, DHCPv6 client restarts, or interface state changes
         (e.g., Transient PPP interfaces), as long as the underlying
         link-layer address (if any) does not change..  See Section 3.2
         for further details.

Or maybe:
      o  WPD-10: CE Routers MUST by default use a WAN-side IAID
         value that is stable between CE Router
         restarts, DHCPv6 client restarts, or interface state changes
         (e.g., Transient PPP interfaces), as long as the underlying
         link-layer address (if any) does not change..  See Section 3.2
         for further details.

?

> It would be

Is it? There doesn't seem to be such provision in RFC8415. And RFC7844 
is really an opt-in...

> used on, since the CE router will often be on both ends of different

You mean like the "WAN-side" text above?

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 25 Feb 2021 21:09:47 +0000

As DHCPv6 uses the DUID and IA Type (this is fixed based on what client wants - such as IA_PD) and IA_ID, a device should keep these consistent (across reboots, ...).

If the DUID changes, then there's no reason that the IA_ID cannot change (it's a different client).

If the DUID doesn't change, you MUST keep the IA_ID for a particular interface constant (I'm not sure I would tie this to the interface's link-layer address, but I guess you could).

If a device changes the IA_ID (without changing the DUID), the problem is that the DHCPv6 server will think this is a "different" request than the earlier IA_ID and assign new prefixes or addresses (and no communication about previously used ones). 

If the DUID changes, it is a different client anyway - so then the IA_ID can be a new value.

- Bernie

-----Original Message-----
From: Fernando Gont <[email-masked]> 
Sent: Thursday, February 25, 2021 3:28 PM
To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Owen DeLong <[email-masked]>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)

Hello, Ben,

> The text in Section 3.2 goes into a bit more detail to clarify that 
> this is basically a pre-existing requirement from RFC 8415, but the 
> short text here is easy to misread as imposing a requirement to use a 
> stable persistent identifier, which would have lousy privacy 
> properties.  RFC
> 8415 does acknowledge this issue to some extent, but the most 
> applicable text about it seems to be in Section 4.5 of RFC 7844, that 
> clarifies that the IAID needs to be consistent for the association *as 
> long as the link-layer address remains constant*, which is a very 
> natural scope and consistent with best practices for simultaneously 
> changing identifiers at different layers when needed for privacy improvement.

You're right that if the CE Router changes its link-layer address, it's probably because it's trying to its identity, and hence the IAID should also change.

(FWIW, to a large extent we phrased the text as is because I know of no CE Router that randomizes it's link-layer address, so in practice it would result in the same thing). Not surprisingly, I'm keen to improve the specification of this numeric id ;-), so how about:

Or maybe:

?

> changes.)", though I was hoping to have something shorter.

Is it? There doesn't seem to be such provision in RFC8415. And RFC7844 is really an opt-in...

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 18:57:47 -0300

> If the DUID doesn't change, you MUST keep the IA_ID for a particular interface constant (I'm not sure I would tie this to the interface's link-layer address, but I guess you could).

My take is that this is a bit of a stretch in RFC7844.

> If the DUID changes, it is a different client anyway - so then the IA_ID can be a new value.

Thinking back about this: maybe it would be simpler to state something 
along the lines of:

       o  WPD-10: CE Routers MUST by default use a WAN-side IAID
          value that is stable between CE Router restarts, DHCPv6
          client restarts, or interface state changes (e.g., Transient
          PPP interfaces) unless the CE Router implements [RFC7844]. See
          Section 3.2 for further details.

?

Thanks!

Regards,

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 25 Feb 2021 22:08:29 +0000

I’m somewhat fine with your text.

The “unless the CE Router implements [RFC7844].” seems like something one could drive a truck through? What part(s) of [RFC7844] are you talking about (perhaps the text in section 4.5 and referencing it might be best here). Perhaps, “unless the CE Router implements the IAID techniques discussed in Section 4.5 of [RFC7844].” (or something like that).

  *   Bernie

From: Fernando Gont <[email-masked]>
Date: Thursday, February 25, 2021 at 4:59 PM
To: Bernie Volz (volz) <[email-masked]>, Benjamin Kaduk <[email-masked]>, The IESG <[email-masked]>
Cc: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, Owen DeLong <[email-masked]>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-v6ops-cpe-slaac-renum-07: (with COMMENT)

?

Thanks!

Regards,

---

From: Fernando Gont <[email-masked]>
Date: Thu, 25 Feb 2021 19:21:43 -0300

On 25/2/21 19:08, Bernie Volz (volz) wrote:
> The “unless the CE Router implements [RFC7844].” seems like something 
> one could drive a truck through? What part(s) of [RFC7844] are you 
> talking about (perhaps the text in section 4.5 and referencing it might 
> be best here). Perhaps, “unless the CE Router implements the IAID 
> techniques discussed in Section 4.5 of [RFC7844].” (or something like that).

Based on a quick read of RFC7844, it seems it implies:
* MAC randomization
* DUID based on the MAC adresses (hence changing)
* Changing IAID in response to MAC address changes.

So it seems that when a new mac address is randomized, all three values 
change....

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 25 Feb 2021 18:20:27 -0800

>          link-layer address (if any) does not change..  See Section 3.2

The thread has continued and I think has gotten into enough details that I
don't know much about that my insight will not be very valuable.  About the
only contribution I might make is that a construction of the form "MUST by
default behave such that [list of things] or behave according to RFC 7844"
might be a little easier to read, since it's a choice rather than a primary
behavior and exception.

> Is it? There doesn't seem to be such provision in RFC8415. And RFC7844 

My mistake; I think that was sloppy writing from me here and I meant to
say something like "still permitted to change".

> You mean like the "WAN-side" text above?

Exactly!

Thanks,

Ben

---

From: Fernando Gont <[email-masked]>
Date: Fri, 26 Feb 2021 04:07:56 -0300

Hello, Ben,

>> On 23/2/21 19:13, Benjamin Kaduk via Datatracker wrote:
[...]
> might be a little easier to read, since it's a choice rather than a primary

Fair enough.

I'd suggest something like:

      o  WPD-10: CE Routers MUST by default use a WAN-side IAID
         value that is stable between CE Router
         restarts, DHCPv6 client restarts, or interface state changes
         (e.g., Transient PPP interfaces), or behave according to
         [RFC7844].  See Section 3.2 for further details.

My only concern here is that, in a way, this reads a bit like "pick any 
of these two behaviors", whereas what we want is something more along 
the lines of "it MUST do this, unless you implement the anonymity 
profiles. (i.e., if you pick the RFC7844, it should be because you do 
mean the CE Router to implement the anonymity profiles).

So an alternative could be:

      o  WPD-10: CE Routers MUST by default use a WAN-side IAID
         value that is stable between CE Router
         restarts, DHCPv6 client restarts, or interface state changes
         (e.g., Transient PPP interfaces), unless the CE Router
         employs [RFC7844] for the WAN-side.  See Section 3.2 for
         further details.

(might spell out the title of RFC7844, too....)

Thoughts? Suggestions?

Thanks!

Regards,

---

From: Benjamin Kaduk <[email-masked]>
Date: Sat, 27 Feb 2021 11:16:08 -0800

> (might spell out the title of RFC7844, too....)

Those both look good to me, so I expect you'll go with your preference (the
latter).

Thanks,

Ben