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

[Tim Chown <[e-mail]>]

Hi,

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

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

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

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

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

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

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

> 
>> 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.
> 
> 
> 
> 
>> Nits:
>> 
>> 1. Some references are included multiple times, e.g. [RFC4941],
>> 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!

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

Tim

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