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

[Ballot comment]

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.

[Ballot discuss]
I am taking the somewhat curious route of raising a DISCUSS on a document that I am shepherding.  I will return to a Yes when these issues are resolved.  Thomas Narten raised a good point that this document does not mention the work published in RFCs 4436 and 6059 (from the concluded DNA WG).  Two of the points he raised are worth addressing in this document prior to publication.

1. [Resolved] - Storing addresses is going to raise privacy issues.

2. DNA provides some ability to manage the Network_ID component of the cryptographic hash.  For wired networks, that may be quite useful as long as the Network_ID can be stored securely.

[Ballot comment]
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.

[Ballot discuss]

(0) Just modifying my disucss to discuss a part of Brian's discuss:-)
I'm sure we'll sort it out easily enough though. I very much do
not think that it'd be a good plan to store every address that
has been generated using this algorithm. That would be making a
privacy-enhancing feature damage privacy. See [1] for an example.

  [1] http://www.theguardian.com/technology/2011/apr/20/iphone-tracking-prompts-privacy-fears

(1) Section 5: Why mention only MD5 and SHA1? Why not
HMAC-SHA256? As-is, implementers are likely to get this
wrong in various ways, e.g. allowing MD5 collisions to
be generated on purpose with different inputs perhaps
as a way to assign blame to an innocent victim.  If
HMAC-MD5 or better (*) HMAC-SHA256 were recommended
instead, it is far more likley that implementers will
do the right thing and it seems just as easy to do
today's right thing as what's mentioned here.

  (*) Even though HMAC-MD5 is still ok, its better
  (for audit reasons) if we reduce the number of
  copies of MD5 runtime code on systems and do not
  introduce new instances of that code.

(2) Why might a sys admin want to display the
secret key? If there's a reason shouldn't you say
so that coders don't do the wrong thing? The
concern is that once established, this key might
be re-used for other purposes and display might
then become an interesting attack vector.

[Ballot comment]
- Probably not worth investigating, but I'd wonder if a
bad-actor with the 64 bit prefix to play about with
could force an IID on a node that used plain MD5 with a
guessable or known secret_key. I don't think that's
doable today but its yet another reason to avoid very
outdated hash functions like md5. This is a non-issue
if discuss#1 is resolved by ditching MD5.

[Ballot discuss]
I am taking the somewhat curious route of raising a DISCUSS on a document that I am shepherding.  I will return to a Yes when these issues are resolved.  Thomas Narten raised a good point that this document does not mention the work published in RFCs 4436 and 6059 (from the concluded DNA WG).  Two of the points he raised are worth addressing in this document prior to publication.

1. If you have stable storage (and many devices do), it makes sense to just cache the addresses instead of
regenerating them. DNA does this. Seems like that option should be allowed. (the current document suggests saving the number of DAD iterations in stable storage... why do that if you can just save the address itself?)

2. DNA also has recommendations for detecting when you (re)connect to a network you visited before. That is pretty much the same thing this spec needs to do in order to generate the same addresses when connecting to a previously visited network (i.e., the Network_ID paramater). For the wired case (i.e, no SSID), DNA suggests using the linklayer/linklocal address pair of routers to identify a link. This document might suggest doing the same thing.

[Ballot comment]
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.

[Ballot discuss]
I'd like to hear mostly from the shepherd, who didn't actually answer the second part of the first question on the shepherd writeup: "Why is this the proper type of RFC?"

This looks to me like an algorithm to generate stable, private, and mostly unique addresses. It looks like it does not affect interoperability at all if people choose a different method. It looks to me like you could have accomplished the same task in a number of different ways. This just seems like a nice method to use if someone wanted to use it. So it's not clear to me why this isn't just an Informational document explaining a nice way to generate stable, private, mostly unique addresses without lots of MUSTs and SHOULDs that are not really interoperability requirements.

[Ballot discuss]


(1) Section 5: Why mention only MD5 and SHA1? Why not
HMAC-SHA256? As-is, implementers are likely to get this
wrong in various ways, e.g. allowing MD5 collisions to
be generated on purpose with different inputs perhaps
as a way to assign blame to an innocent victim.  If
HMAC-MD5 or better (*) HMAC-SHA256 were recommended
instead, it is far more likley that implementers will
do the right thing and it seems just as easy to do
today's right thing as what's mentioned here.

  (*) Even though HMAC-MD5 is still ok, its better
  (for audit reasons) if we reduce the number of
  copies of MD5 runtime code on systems and do not
  introduce new instances of that code.

(2) Why might a sys admin want to display the
secret key? If there's a reason shouldn't you say
so that coders don't do the wrong thing? The
concern is that once established, this key might
be re-used for other purposes and display might
then become an interesting attack vector.

[Ballot comment]

- Probably not worth investigating, but I'd wonder if a
bad-actor with the 64 bit prefix to play about with
could force an IID on a node that used plain MD5 with a
guessable or known secret_key. I don't think that's
doable today but its yet another reason to avoid very
outdated hash functions like md5. This is a non-issue
if discuss#1 is resolved by ditching MD5.

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-stable-privacy-addresses-16, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions. IANA requests that the IANA Considerations section of the document remain in place upon publication.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'A Method for Generating Semantically Opaque Interface Identifiers with
  IPv6 Stateless Address Autoconfiguration (SLAAC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-12-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a method for generating IPv6 Interface
  Identifiers to be used with IPv6 Stateless Address Autoconfiguration
  (SLAAC), such that addresses configured using this method are stable
  within each subnet, but the Interface Identifier changes when hosts
  move from one network to another.  This method is meant to be an
  alternative to generating Interface Identifiers based on hardware
  addresses (e.g., IEEE LAN MAC addresses), such that the benefits of
  stable addresses can be achieved without sacrificing the privacy of
  users.  The method specified in this document applies to all prefixes
  a host may be employing, including link-local, global, and unique-
  local addresses.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have completed my AD evaluation for
draft-ietf-6man-stable-privacy-addresses and only have a few
comments/questions that I would like to get some feedback on...

1. It would be useful to include an *informative* reference or two for
candidate PRFs.

2. Given the opaque bits discussion in section 5, I think it would be
good to include a reference to the 6man-ug draft to provide the
justification.

3. Section 6 discusses the benefits of using the DAD_Counter in the PRF
call, but I think the draft should also mention the downsides to not
maintaining that variable in non-volatile memory over reboots.
Specifically, the scenario where a node used IDGEN_RETRIES attempts on
the previous boot to get a valid address and during the current boot
will fail if it needs IDGEN_RETRIES+1 tries and DAD_Counter info is not
stored.

4. I am agnostic on this one, but want some feedback.  Should the
reference to the address-generation-privacy draft be normative given
that it contains the necessary background info supporting this approach?


Once we agree on these points, we can move the draft along in the
publication process.

Regards,
Brian

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-6man-stable-privacy-addresses-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (A method for Generating Stable Privacy-Enhanced Addresses with IPv6 Stateless Address Autoconfiguration (SLAAC)) to Proposed Standard


The IESG has received a request from the IPv6 Maintenance WG (6man) to
consider the following document:
- 'A method for Generating Stable Privacy-Enhanced Addresses with IPv6
  Stateless Address Autoconfiguration (SLAAC)'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-04-26. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  This document specifies a method for generating IPv6 Interface
  Identifiers to be used with IPv6 Stateless Address Autoconfiguration
  (SLAAC), such that addresses configured using this method are stable
  within each subnet, but the Interface Identifier changes when hosts
  move from one network to another.  The aforementioned method is meant
  to be an alternative to generating Interface Identifiers based on
  IEEE identifiers, such that the benefits of stable addresses can be
  achieved without sacrificing the privacy of users.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-6man-stable-privacy-addresses/ballot/


No IPR declarations have been submitted directly on this I-D.

All,
    I have performed by AD review of draft-ietf-6man-stable-privacy-addresses.  For the most part, this is a well-written document.  I only have a few comments that should be resolved prior to moving this to IETF Last Call...

1. Section 1 : I understand that the fourth paragraph is indented since it is quoting from another document.  I do not see why the fifth paragraph is indented.  The same confusion exists for the second paragraph of Section 3.

2. Section 3 :

* The PRF is fed several variables in order to generate a random number.  I appreciate that the issues with different identifiers being generated for the same prefix due to varying values of DAD_Counter are discussed (Section 4).  What is missing is discussion of when the Interface_Index value changes.  On many systems, the value returned via the socket APIs is based on the ifIndex value assigned to the interface.  There are a variety of situations where the ifIndex can change within a system and these should be mentioned.  This can impact design goal #2.

* What are the assumptions on this algorithm with respect to multi-homed devices that could have different network interfaces available to attach to the same network?  For example, if I have a quad-port network card, I could attach to a network via eth0 and get an identifier for prefix X. The next time I attach to that network, I use eth2 and I will not get the same identifier even though I still get a PIO containing prefix X. This issue directly contradicts design goal #1.

3. I think it would be good to explicitly state that this IID generation mechanism is incrementally deployable since there are no interoperability issues with IID generation.

Regards,
Brian