A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)
draft-ietf-6man-stable-privacy-addresses-17

Note: This ballot was opened for revision 16 and is now closed.

( Richard Barnes ) Yes

Brian Haberman (was Discuss, Yes) Yes

( Ted Lemon ) Yes

Jari Arkko No Objection

( Stewart Bryant ) No Objection

Comment (2014-01-21 for -16)
As Adrian says, this does not look like it impacts the routing systems so based on a quick skim, no objection.

I am, however, left pondering as to whether a simple call to the system RNG wouldn't work well enough most of the time.

( Gonzalo Camarillo ) No Objection

Benoit Claise No Objection

Comment (2014-01-23 for -16)
Please Tim's OPS DIR review (currently under discussion)

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.

Spencer Dawkins No Objection

Comment (2014-01-23 for -16)
This is a very well-written and clear document. Thank you for that.

( Adrian Farrel ) No Objection

Comment (2014-01-20 for -16)
Based on a quick skim of this document and the judgement that it has
no direct impact on the routing infrastructure, I am balloting No
Objection.

Stephen Farrell (was Discuss) No Objection

Comment (2014-01-28)
Thanks for those changes.

One new comment. It'd be better to reference HMAC-SHA1 and
HMAC-SHA256 as the examples and not SHA1 and SHA256.
There are relevant security differences between those, 
depending on how you provide and process the inputs to F().
(I've not tried to figure out if ther're significant here, but the
HMAC flavours are just better and if you did use them then
I'd not even need to think about it:-)

If you're not happy to do that then rather than say that SHA1
or SHA256 can be used "for" F(), it'd be better to say that F() 
can be "baeed upon" SHA1, as that'd encompass HMAC-SHA1
or HMAC-SHA256.

Joel Jaeggli No Objection

Barry Leiba No Objection

Martin Stiemerling No Objection

Comment (2014-01-20 for -16)
Section 2., paragraph 4:

>    Note that the result of F() in the algorithm above is no more secure
>    than the secret key.  If an attacker is aware of the PRF that is
>    being used by the victim (which we should expect), and the attacker
>    can obtain enough material (i.e. addresses configured by the victim),
>    the attacker may simply search the entire secret-key space to find
>    matches.  To protect against this, the secret key should be of a
>    reasonable length.  Key lengths of at least 128 bits should be
>    adequate.  The secret key is initialized at system installation time
>    to a pseudo-random number, thus allowing this mechanism to be enabled
>    /used automatically, without user intervention.

  Isn't there a requirement (MUST) or at least a recommendation (RECOMMENDED) to say something about the minimum length of the secret key? Just to let implementers know from what length on the secret is 'safe' as input?

( Pete Resnick ) (was Discuss) Abstain

Comment (2014-01-22 for -16)
This is an algorithm to generate stable, private, and mostly unique addresses. It does not affect interoperability at all if people choose a different method. Anyone can accomplish the same task in a number of different ways. This is just a nice method to use if someone wanted to use it. This should just be an Informational document explaining a nice way to generate stable, private, mostly unique addresses without all of the MUSTs and SHOULDs, which are not interoperability requirements in the first place. Standardizing this is silly in the extreme.