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

[Tim Chown <[e-mail]>]

Hi,

On 27 Jan 2014, at 13:23, Fernando Gont <[e-mail]> wrote:

> Hi, Tim,
> 
> Thanks so much for your response! -- Please find mine in-line...
> 
> On 01/24/2014 02:13 PM, Tim Chown wrote:
>>>> 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...
> [....]
>> 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.

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

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

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.

>>>> 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."?
>> 
>> 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."

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.

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

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

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