Subject: OPS-DIR review of draft-6man-stable-privacy-addresses-16

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jan 2014 01:05:28 +0000

Hi,

First, I would note that I have already contributed comments/text to this draft, as acknowledged by Fernando.  It’s been a few versions since I last read it.

The goal of the draft has considerable merit, and I believe the document is worthy of publication, subject to comments belwo being considered.

I would classify the document as ‘Ready with issues’.

Issues:

1. In the discussion in section 5 on the algorithm, it may be desirable to suggest that implementations allow a choice of IID generation based on ‘classic’ SLAAC with EUI-64 or via this new proposed method, with a default of the new method.

2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some time ago, and in rare cases) seen Linux installations where network interface names can ‘swap’, thus changing the address in use on the interface under the proposed algorithm, whereas with existing EUI64 SLAAC the IIDs would remain the same even if the interface name for a physical interface changed. This is probably rather more likely if replacing a network card on motherboard with on-board NIC(s).  Perhaps Fernando can comment on whether this is a realistic concern with modern OSes.

3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a different F(), given that’s not specified.  With EUI-64, a dual-boot host would likely have the same address under either OS (well, not Windows any more…).  This may be worth making explicit.

4. The draft talks (in one place in Section 3) about stable privacy addresses being allocated by DHCPv6; some further discussion of how this might be achieved may be useful given the secret key is presumed to be generated on and reside on the host, not the DHCPv6 server.  Or would this be described in a separate future draft?  This may be a case where the administrator being able to display or change the secret key needs to be more than a MAY as currently satted in the text.

5. Design goal 1 might add “and same interface” for scenarios where a host has two interfaces in the same subnet (with the same prefix).  This scenario is one that may cause ‘interesting’ effects with addresses if interface names swap and no Network_ID is used.

6. I’d suggest not mentioning MD5.

Nits:

1. Some references are included multiple times, e.g. [RFC4941], rather than only at the first instance.

2. Design goal 2, perhaps say “must” rather than “do”?

3. In section 4 the author states the goal of stable IIDs within a given subnet. It may be better to say for a given prefix, given a renumbering process will change the prefix and with it the IID, though by loose language you might refer to it as the same subnet.

In response to recent discussion on 6man, I don’t believe it’s practical or desirable for a node to store addresses related to locations (networks) visited.  I agree with the author that the static address per network should be generated statelessly.

Tim

---

From: Hannes Frederic Sowa <[email-masked]>
Date: Thu, 23 Jan 2014 02:15:12 +0100

Hi!

> 2. In the algorithm section, there is a comment that interface names MUST remain the same across boots or down/up events for the stable privacy address to remain stable. I have (admittedly some tim…

It is mostly solved. Currently earily user space reconfigures the names
of the network interface cards based on mac addresses. This also means
we cannot generate those addresses while kernel boot-up but must wait
until those renames have occured.

For the linux implementation we are currently more and more considering a pure
userspace implementation as we have problems with dad counter persistence and
possible address generation algorithm configurations.

> 3. I assume the IID may/will vary for a different OS run on the same host, e.g. where the host is dual-boot, or where a new OS installed (or the same OS re-installed). A different OS may well use a…

Problem here is the sharing of the secret. Well, a different OS must read the
other OSes filesystem to get the secret needed for address generation.

Maybe we could install those secrets into some uEFI store but I am not an
expert on this.

> 6. I’d suggest not mentioning MD5.

Ack.

Thanks,

  Hannes

---

From: Fernando Gont <[email-masked]>
Date: Thu, 23 Jan 2014 04:37:12 -0300

Hi, Tim,

Thanks so much for your feedback! Please find my comments in-line...

On 01/22/2014 10:05 PM, Tim Chown wrote:
> Issues:
> 
> 1. In the discussion in section 5 on the algorithm, it may be
> desirable to suggest that implementations allow a choice of IID
> generation based on ‘classic’ SLAAC with EUI-64 or via this new
> proposed method, with a default of the new method.

This point is actually addressed by the draft-ietf version for
deprecate-eui64 (which will not deprecate eui64, but will specify the
default).

i.e., this document just focuses on how you implement stable-privacy.
The draft-ietf version of deprecate-eui64
(draft-ietf-6man-ipv6-defult-iids) seems like the place to specify that
of having a knob to configure which method to use...

> 2. In the algorithm section, there is a comment that interface names
> MUST remain the same across boots or down/up events for the stable
> privacy address to remain stable. 

Strictly speaking, it says that Net_Iface MUST be constant. Then
Appendix A discusses possible sources for NetIface...

> I have (admittedly some time ago,
> and in rare cases) seen Linux installations where network interface
> names can ‘swap’, thus changing the address in use on the interface
> under the proposed algorithm, whereas with existing EUI64 SLAAC the
> IIDs would remain the same even if the interface name for a physical
> interface changed. This is probably rather more likely if replacing a
> network card on motherboard with on-board NIC(s).  Perhaps Fernando
> can comment on whether this is a realistic concern with modern OSes.

I think I was told that this has been fixed in Linux . That said, we
don't require any specific source for NetIface. For instance, you can
even use the link-layer address (please see Section A.3), such that you
get the same stability properties as EUI64 SLAAC.

The rationale for not requiring any specific source is that an
implementer know better which source is more stable/convenient. Some
source might be stable in one OS, but not in others. And viceversa.

> 3. I assume the IID may/will vary for a different OS run on the same
> host, e.g. where the host is dual-boot, or where a new OS installed
> (or the same OS re-installed). A different OS may well use a
> different F(), given that’s not specified.  With EUI-64, a dual-boot
> host would likely have the same address under either OS (well, not
> Windows any more…).  This may be worth making explicit.

This could be a pro or con, one might say.

I guess we could add something along the lines of:

"Since different implementation are likely to use different values for
secret_key, and may also employ different PRNGs for F() and different
surces for NetIface, we note that an a host that is dual-boot or that is
reinstalled may result in different IPv6 addresses for each OS and/or
installation."?

> 4. The draft talks (in one place in Section 3) about stable privacy
> addresses being allocated by DHCPv6; some further discussion of how
> this might be achieved may be useful given the secret key is presumed
> to be generated on and reside on the host, not the DHCPv6 server.  Or
> would this be described in a separate future draft? 

Yes, a future draft -- e.g. where the algorithm is computed by the
DHCPv6 server.

> 5. Design goal 1 might add “and same interface” for scenarios where a
> host has two interfaces in the same subnet (with the same prefix).
> This scenario is one that may cause ‘interesting’ effects with
> addresses if interface names swap and no Network_ID is used.

Will do. (the seconds sentence already notes this).

> 6. I’d suggest not mentioning MD5.

Yep. Will do.

> rather than only at the first instance.

I will check this -- it could be that I'm referring to different terms
of the same specs.... or just me being plain redundant. :-(

> 2. Design goal 2, perhaps say “must” rather than “do”?

Yep. Will do.

> 3. In section 4 the author states the goal of stable IIDs within a
> given subnet. It may be better to say for a given prefix, given a
> renumbering process will change the prefix and with it the IID,
> though by loose language you might refer to it as the same subnet.

Will do.

> In response to recent discussion on 6man, I don’t believe it’s
> practical or desirable for a node to store addresses related to
> locations (networks) visited.  I agree with the author that the
> static address per network should be generated statelessly.

Great. :-)

Thanks so much!

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

---

From: Tim Chown <[email-masked]>
Date: Fri, 24 Jan 2014 17:13:28 +0000

Hi,

> of having a knob to configure which method to use...

I think Brian has cleared this point up (issue to be described in a separate text).

> source might be stable in one OS, but not in others. And viceversa.

It does seem that each of those sources listed in the Appendix may not be constant. That may of course depend on hardware as well as OS.

I guess there can be no 100% guarantee for all platforms, so the document should note that, and the implications.  For example, the last para in Section 1 could instead say:

"This document specifies a method to generate Interface Identifiers that, subject to a constant/stable interface identifier being available, are stable/constant for each network interface within each prefix", or something like that.

It should be noted that if no such table identifier is available, a stable IID per prefix can't be guaranteed (unless stable storage for visited prefixes is used, which has significant privacy concerns as discussed earlier this week...)

> reinstalled may result in different IPv6 addresses for each OS and/or

That could work.  Or you could maybe have a section or subsection that documents cases where a stable IID can't be guaranteed.  The case above is one, and dual-boot or a reinstalled OS is another?  Are there other cases?

> Yes, a future draft -- e.g. where the algorithm is computed by the

So one thing to consider here is that unless the 'secret_key' is shared/copied between the host and the DHCPv6 server, a subnet which changes to/from DHCPv6 to/from RAs for address configuration will see the IID change.  Maybe this is a third case of the above...

>> static address per network should be generated statelessly.

Overall the document is in very good shape. Well done!

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jan 2014 10:23:50 -0300

Hi, Tim,

Thanks so much for your response! -- Please find mine in-line...

>> Appendix A discusses possible sources for NetIface...
[....]
> It does seem that each of those sources listed in the Appendix may not
> be constant. That may of course depend on hardware as well as OS.

At the very least, I'd expect the MAC address to be constant.

> I guess there can be no 100% guarantee for all platforms, so the
> document should note that, and the implications.  For example, the last
> para in Section 1 could instead say:
> 
> "This document specifies a method to generate Interface
> Identifiers that, subject to a constant/stable interface identifier
> being available, are stable/constant for each network interface within
> each prefix", or something like that.

I have no issues with adding this. Although I wonder if it really
represents reality. In most systems, you can apply ACLs based on the
interface name/index... so the lack of constant IDs for the interfaces
you mean that you couldn't really apply such ACLs.

If you still think that the aforementioned paragraph would help, I'd
probably add it as:

"This document specifies a method to generate Interface
 Identifiers that, subject to a stable interface identifier being
 available (see Appendix A), are stable for each network interface
 within each prefix"

(I've just added a reference to Appendix A, and removed the term
"constant", based on the discussions we have had for the
ipv6-addressing-privacy I-D).

> That could work.  Or you could maybe have a section or subsection that
> documents cases where a stable IID can't be guaranteed.  The case above
> is one, and dual-boot or a reinstalled OS is another?  Are there other
> cases?

Rather than enumerating the cases, I'd probably add a "disclaimer" in
the Intro. How about this improved version of the text:

 "Since different implementation are likely to use different values for
  the secret_key parameter, and may also employ different PRNGs for
  F(), and different sources for the Net_Iface parameter, the
  addresses generated by this scheme should not expected to be constant
  across different operating system installations. For example, a host
  that is dual-boot or that is reinstalled may result in different IPv6
  addresses for each OS and/or installation."

> So one thing to consider here is that unless the 'secret_key' is
> shared/copied between the host and the DHCPv6 server, a subnet which
> changes to/from DHCPv6 to/from RAs for address configuration will see
> the IID change.  Maybe this is a third case of the above...

I kind of think of DHCPv6 as a different world and "out of scope". But
please let me know if you think otherwise...

Thanks!

Cheers,

---

From: Tim Chown <[email-masked]>
Date: Mon, 27 Jan 2014 17:11:04 +0000

Hi,

> At the very least, I'd expect the MAC address to be constant.

Yes, as much as it would be for classic EUI64 SLAAC.  

> ipv6-addressing-privacy I-D).

So I think the thing here is that the IID can't be guaranteed to be stable per prefix, because there are factors that may cause it to change.  The only way to be sure it's stable per prefix is to store the IID used per prefix, or to find some stateless generation method for which there can be no change. Storing the per-prefix IIDs essentially puts a permanent list of all addresses the device has ever used into persistent storage on the device.

>  addresses for each OS and/or installation."

Well, I'm not making this as a blocking comment, I'm just suggesting that a (sub)section that itemises the reasons that the "stable" address per prefix may not be stable would be a useful thing to have in the table of contents.  

There may be some use cases where an administrator assumes the IID is stable per prefix, when it may not be.  Someone that doesn't know how the IID generation function works, but just sees the "Configure stable privacy address" option in a menu, might not realise that the IID can change under some circumstances. Again, I'm happy to go with your final call on this, but just raising it to be sure you've thought about it.

> please let me know if you think otherwise...

The title of the document is clearly stating this is a SLAAC method, so there's no need to discuss DHCPv6. But I would say that some networks will run SLAAC, and some DHCPv6, and that choice might change over time, so there is an issue as to whether the secret_key is held only on the host, only on the DHCPv6 server, or if there's some method to share them.

Another thing to consider operationally is the scope of where the stable privacy address is used. If you really wanted to guarantee a stable privacy address per subnet within a single enterprise, and you had administrative/policy control of the hosts, you might want to have a configuration knob to turn on storage of per-prefix IIDs for prefixes belonging to that site. Similarly some administrators might turn off IPv6 Privacy Addresses where they have managed devices within an enterprise to ensure their devices use stable IPv6 source addresses. I guess this type of consideration is probably best aimed at your other usage draft though...

Tim

---

From: Christian Huitema <[email-masked]>
Date: Mon, 27 Jan 2014 17:49:06 +0000

> So I think the thing here is that the IID can't be guaranteed to be stable per prefix, because there are factors that may cause it to change.  The only way to be sure it's stable per prefix is to s…

In fact, the draft already has some text about remembering DAD collisions:

                                                   In order to mitigate this potential problem,
   nodes MAY record the DAD_Counter value employed for a specific
   {Prefix, Net_Iface, Network_ID} tuple in non-volatile memory, such
   that the same DAD_Counter value is employed when configuring an
   address for the same Prefix and subnet at any other point in time.

This can be a baby step towards "a permanent list of all addresses the device has ever used..." But then, we have to wonder whether we really need to guarantee that the address will remain constant for all locations that the device visits. In practice, it feels like the "stable address" property is mostly needed in the "home base" of the device, for example the corporate network if the device is registered in one. On the other hand, I don't think many will object if their device gets a different address each time they visit the same airport bar...

-- Christian Huitema

---

From: Tim Chown <[email-masked]>
Date: Mon, 27 Jan 2014 19:09:31 +0000

Hi,

> This can be a baby step towards "a permanent list of all addresses the device has ever used..." But then, we have to wonder whether we really need to guarantee that the address will remain constant…

I agree with the likely use case. I suggested something to consider along those lines for Fernando’s related draft.

Tim

---

From: Fernando Gont <[email-masked]>
Date: Mon, 27 Jan 2014 19:04:17 -0300

Hi, Tim,

On 01/27/2014 02:11 PM, Tim Chown wrote:
[....]
>> 
>> "This document specifies a method to generate Interface Identifiers
>> that, subject to a stable interface identifier being available (see
>> Appendix A), are stable for each network interface within each
>> prefix"
>> 
> So I think the thing here is that the IID can't be guaranteed to be
> stable per prefix, because there are factors that may cause it to
> change. The only way to be sure it's stable per prefix is to store
> the IID used per prefix, or to find some stateless generation method
> for which there can be no change. Storing the per-prefix IIDs
> essentially puts a permanent list of all addresses the device has
> ever used into persistent storage on the device.

Well, strictly speaking, you can never guarantee an IID to be stable:
since you're required to do DAD, even with the traditional SLAAC you
might find a collision. Even if you record the addresses, the same applies.

My take is that, one way or another, you can always find some
stable-enough Net_Iface parameters that leads to a pragmatically stable IID.

>> Rather than enumerating the cases, I'd probably add a "disclaimer"
>> in the Intro. How about this improved version of the text:
>> 
>> "Since different implementation are likely to use different values
>> for the secret_key parameter, and may also employ different PRNGs
>> for F(), and different sources for the Net_Iface parameter, the 
>> addresses generated by this scheme should not expected to be
>> constant across different operating system installations. For
>> example, a host that is dual-boot or that is reinstalled may result
>> in different IPv6 addresses for each OS and/or installation."
> 
> Well, I'm not making this as a blocking comment, I'm just suggesting
> that a (sub)section that itemises the reasons that the "stable"
> address per prefix may not be stable would be a useful thing to have
> in the table of contents.

My take is that such section is doomed to have an errata. :-) Thus why I
suggest a clarification of "don't expect the IID to remain constant
across OS installations... even if re-installation of the same OS).
Having some sort of stable Net_iface is a requirement for this spec. It
doesn't matter which one you choose... as long as it is stable.

>>>>> 4. The draft talks (in one place in Section 3) about stable
>>>>> privacy addresses being allocated by DHCPv6; some further
>>>>> discussion of how this might be achieved may be useful given
>>>>> the secret key is presumed to be generated on and reside on
>>>>> the host, not the DHCPv6 server.  Or would this be described
>>>>> in a separate future draft?
>>>> 
>>>> Yes, a future draft -- e.g. where the algorithm is computed by
>>>> the DHCPv6 server.
>>> 
>>> shared/copied between the host and the DHCPv6 server, a subnet
>>> which changes to/from DHCPv6 to/from RAs for address
>>> configuration will see the IID change.  Maybe this is a third
>>> case of the above...
>> 
>> I kind of think of DHCPv6 as a different world and "out of scope".
>> But please let me know if you think otherwise...
> 
> The title of the document is clearly stating this is a SLAAC method,
> so there's no need to discuss DHCPv6. But I would say that some
> networks will run SLAAC, and some DHCPv6, and that choice might
> change over time, so there is an issue as to whether the secret_key
> is held only on the host, only on the DHCPv6 server, or if there's
> some method to share them.

So far, there's nothing like that. And while this document mentions
DHCPv6, the idea is "this might be ported to DHCPv6 in some future
document".

> Another thing to consider operationally is the scope of where the
> stable privacy address is used. If you really wanted to guarantee a
> stable privacy address per subnet within a single enterprise, and you
> had administrative/policy control of the hosts, you might want to
> have a configuration knob to turn on storage of per-prefix IIDs for
> prefixes belonging to that site. Similarly some administrators might
> turn off IPv6 Privacy Addresses where they have managed devices
> within an enterprise to ensure their devices use stable IPv6 source
> addresses. I guess this type of consideration is probably best aimed
> at your other usage draft though...

Agreed. FWIW, I should say that previous attempts to do that for SLAAC
have failed (e.g.
<http://tools.ietf.org/id/draft-gont-6man-managing-slaac-policy-00.txt>).

Thanks!

Best regards,