Subject: "Recommendation on Temporary IPv6 Interface Identifiers" (revised I-D) (Fwd: New Version Notification for draft-gont-6man-non-stable-iids-01.txt)

From: Fernando Gont <[email-masked]>
Date: Wed, 15 Mar 2017 11:57:24 -0300

Folks,

We have posted a rev of our I-D "Recommendation on Temporary IPv6
Interface Identifiers".

It's available here:
<https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-01.txt>

You're feedback is welcome.

Thanks!

Best regards,
Fernando

-------- Forwarded Message --------
Subject: New Version Notification for draft-gont-6man-non-stable-iids-01.txt
Date: Mon, 13 Mar 2017 11:22:58 -0700
From: [email-masked]
To: Fernando Gont <[email-masked]>, Madeleine Garcia Corbo
<[email-masked]>, Christian Huitema <[email-masked]>,
Madelen Corbo <[email-masked]>, Guillermo Gont
<[email-masked]>

A new version of I-D, draft-gont-6man-non-stable-iids-01.txt
has been successfully submitted by Fernando Gont and posted to the
IETF repository.

Name:		draft-gont-6man-non-stable-iids
Revision:	01
Title:		Recommendation on Temporary IPv6 Interface Identifiers
Document date:	2017-03-13
Group:		Individual Submission
Pages:		13
URL:
https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-01.txt
Status:
https://datatracker.ietf.org/doc/draft-gont-6man-non-stable-iids/
Htmlized:
https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-01
Diff:
https://www.ietf.org/rfcdiff?url2=draft-gont-6man-non-stable-iids-01

Abstract:
   This document clarifies the stability requirements for IPv6
   addresses, and provides recommendations regarding the generation of
   Temporary addresses.  Finally, it formally updates RFC4941 such that
   nodes are allowed to configure only temporary addresses.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Mark Smith <[email-masked]>
Date: Thu, 16 Mar 2017 07:19:49 +1100

Hi,

Firstly, I really like this draft.

Suggestions/comments:

o  3.3.  Requirements for Temporary IPv6 Addresses

" Temporary addresses MUST have a limited lifetime, which should be
       different for different addresses."

For clarity, I'd suggest adding:

"This includes when a node has different addresses from within the same prefix."

just to be very clear that there is a requirement of individual
addresses, and that it doesn't change if they happen to be from within
the same prefix. (I assume this is the case?)

"  4.  The resulting interface identifiers MUST NOT embed layer-2
       identifiers (e.g.  MAC addresses)."

perhaps add,

"to prevent correlation between IPv6 IIDs and MAC addresses, when an
outside entity has been able to record both."

"This is
   in contrast with e.g. stable addresses [RFC7217], that do not have
   have a limited lifetime."

I think this is technically not true, the standard IPv6 preferred and
valid lifetimes could cause a stable address to expire, so in those
terms stable addresses, as do all IPv6 addresses, have a "lifetime"
which may be limited (static addresses could be considered an
exception, however it is only convention that when they're configured
they have a infinite preferred and valid lifetime.)

Perhaps this would be more accurate:

"This is in contrast with e.g. stable addresses [RFC7217], who's
values do not change in response to a privacy event or the expiration
of a timer, such as the address's preferred or valid lifetime."

"Having a variable maximum lifetime prevents
   an observer from synchronizing with the temporary address
   regeneration; that is, from being able to expect when address will be
   regenerated, and thus infer that one newly observed addresses is the
   result of regenerating a previously observed one."

This draft seems to be going a bit further in this direction (in a
good way) than RFC4941 does (based on my brief reading of "3.5.
Regeneration of Randomized Interface Identifiers") RFC4941 seems to
have either host or interface universal values
(TEMP_PREFERRED_LIFETIME: 1day, TEMP_VALID_LIFETIME:1 week) for the
maximum lifetimes of temporary addresses. It looks to be focusing on
avoiding synchronised address changes across clients rather than
across addresses within a client.

"That is, a host that de-
   attaches from a network and subsequently re-attaches to a (possibly
   different) network should regenerate all of its temporary addresses."

RFC4941 only very briefly deals with this scenario. I agree with doing
it, however I think there is a risk of a DoS on the link or similar if
an interface starts failing, and disconnects/re-connects rapidly. I
think there should be some prevention against this e.g., multiple
disconnects/connects within 3 seconds indicates the interface is
failing and regeneration of temporary addresses should not take place
if this occurs.

"Besides, a node that generates an IPv6 address by embedding
   a link-layer address in the IPv6 address will, when configuring
   addresses for different prefixes, result in the same IID being used
   for such prefixes, thus allowing the corresponding traffic to be
   correlated."

An example of significance might be correlation between internal ULA
address traffic and external GUA address traffic if the IIDs are
shared and the foreign entity has managed to capture both. ULA would
tend to have greater privacy expectations or semantics because they're
not global addresses and not intended to be exposed to global parties.

"The resulting Interface Identifier SHOULD be compared against the
       reserved IPv6 Interface Identifiers [RFC5453] [IANA-RESERVED-IID]
       and against those Interface Identifiers already employed in an
       address of the same network interface and the same network
       prefix."

Also against addresses on different network interfaces attached to the
same network. Perhaps this IID comparison should really be taking
place across all addresses from within and across prefixes independent
of interfaces?  Actually, I think that is really saying that there is
no IID duplication across any of the addresses used by the host.

 "The algorithm in [RFC7217] can be augmented for the generation of
   temporary addresses.  The benefit of this would be that a node could
   employ a single algorithm for generating stable and temporary
   addresses, by employing appropriate parameters.

   Nodes would employ the following algorithm for generating the
   temporary IID:"

A brief mention of what is changed verses RFC7217 before presenting
the algorithm would be useful. It seems MAC_Address and Time are the
differences?

Regarding using the MAC_Address,

"Employing the MAC address in this expression (in replacement of the
Net_Iface parameter of the expression in RFC7217) means that the
re-generation of a randomized MAC address will result in a different
temporary address."

it isn't clear to me whether randomised MAC addresses is a requirement
or a recommendation when using this algorithm. With it replacing
Net_Iface, it seems to be leaning towards a requirement.

nits:

-  " a
   node may want to use only Temporary address (e.g., a temporary
   address)."

This text seemed a little confusing because it seemed the temporary
address text was being repeated. I realised that the capital T
"Temporary" was a special word, perhaps the parenthesis text is
unnecessary here. e.g.

" a node may want to use only Temporary address ."

- In the terminology section, it might be worth quoting a few of the
repeatedly used terms from RFC7721 for the convenience of the reader.
"Temporary address" would be an example.

- Should "stable address" be capitalised throughout as it too is a
term defined in RFC7721?

- With both "Temporary address" and "temporary address" terms both
being used, it seems like there is some sort of difference between
what these terms mean. It's not really obvious to me what that
difference is. It would seem to me that "Temporary address" (and
"Stable address") should always be being used, as their definitions in
RFC7721 would seem to apply universally.

- "3.3. Requirements for Temporary IPv6 Addresses

   The requirements for temporary IPv6 addresses are as follows:"

-"t","+"T"

"The requirements for Temporary IPv6 addresses are as follows:"

Regards,
Mark.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 16 Mar 2017 13:35:40 -0300

Hi, Mark,

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

Thanks!

> the same prefix. (I assume this is the case?)

Will do. Actually, this scenario is probably the most important one,...
so it's better be crystal clear.

> outside entity has been able to record both."

Yes, there's also the fact that:

1) We cannot be assured that the randomization of the underlying MAC
address is good enough
2) if the IIDs are 64-bit long, and the mac addresses are 48-bit long,
you still need to randomize those remaining 16 bits... so there's no
point in setting pieces of the IID differently
3) Another way to think about this is "compartmentalization": if you
embed an ID from a layer below 8when you don't need to), if you screw up
with how you generate it, the problem is exacerbated.
4) etc.

I'm not sure whether to delve into all these details here, or just
simply provide references to the reader, as we're currently doing. That
is, the reuse of identifiers is well-covered in e.g.  	
draft-gont-predictable-numeric-ids-00... and if we start to elaborate
the reasons, the discussion will be incomplete or we will end up
embedding such I-D into this one...

Thoughts?

> of a timer, such as the address's preferred or valid lifetime."

You're right. The current text is not really accurate. We'll certainly
add something along these lines (what you've suggested)...

> across addresses within a client.

We're certainly going further than RFC4941: that's intentional. The goal
of this requirement is to avoid the regeneration of a temporary address
to become obvious to an observer -- because if it is obvious, there's no
point in regenerating the temporary addresses.

> RFC4941 only very briefly deals with this scenario. 

IIRC, research had found that RFC4941 implementations were failing in
this area.

> I agree with doing

I agree with you. There should certainly be some sort of limit. The
specific value (e.g., multiple disconnects in X time) is less
important... but the document should probably at least mention this and
suggest some limit here.

> not global addresses and not intended to be exposed to global parties.

This is certainly worth incorporating. Thanks!

> no IID duplication across any of the addresses used by the host.

Agreed. We'll clarify this.

> the algorithm would be useful. It seems MAC_Address and Time are the

Yes. Essentially "Time" is what makes the resulting address change over
time. For Temp address, the secret_key *could* be randomized e.g. upon
system bootstrap.

> Net_Iface, it seems to be leaning towards a requirement.

Your question/concern is certainly valid.

Rationale: In RFC7217, you want a Net_Iface that is as stable as
possible (and the MAC address might not be the best choice in such
case). For temporary addresses, as long as Net_Iface uniquely identifies
an interface, it's okay. You could certainly use anything (e.g., still
use the interface name or interface index) for the generation of
temporary addresses. However, if you use the MAC address, one property
comes for free: if you happen to implement mac address randomization,
you can be assured that whenever you regenerate an IPv6 address (after
the mac address has been regenerated), the ipv6 address is going to change.

FWIW, so far the I-D does not say much regarding whether you should do
mac address randomization or not...

> " a node may want to use only Temporary address ."

Oops, this is an editorial error. The original text (previous rev of the
I-D) was:

   While the use of stable addresses (only) or mixed stable and
   temporary addresses can be desirable in a number of scenarios, there
   are other scenarios in which, for security and privacy reasons, a
   node may want to use only non-stable address (e.g., a temporary
   address).

But when we changed the use of "non-stable" to "temporary", the
parenthesis remained. We'll fix this. Thanks!

> "Temporary address" would be an example.

Agreed. We'll copy&paste, and provide a reference to the RFC7721.

> RFC7721 would seem to apply universally.

The I-D currently has inconsistent use of Capitalization for these
terms, I guess the "Capitalized" version is useful to indicate that
we're employing the term defined in RFC7721, rather than simply
referring to a property of the address? Thoughts?

> "The requirements for Temporary IPv6 addresses are as follows:"

Will do.

Thanks so much!

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

---

From: Christian Huitema <[email-masked]>
Date: Thu, 16 Mar 2017 17:51:09 -0700

>> Firstly, I really like this draft.
Thanks for the feedback, Mark. As Fernando wrote, we are more than
willing to improve the document. The general motivation here is that RFC
4941 was written 10 years ago, and we have learned a thing or two since
that. In fact, while the current draft is written as an update to RFC
4941, we are wondering whether it would not be simpler to just evolve
the draft into something like 4941bis.

Among the dated parts of 4941, the first one is indeed the timing issues
that you commented on. 4941 specified a simple periodic assignment. As
we explain in the draft, we get better privacy characteristics if the
temporary address generation is linked to "privacy events" such as a
connection to a new network, a change in a MAC Address, or even a user
request to "erase the web history". Keeping the same IID through such
event enables "before and after" correlation, and that's not exactly
good for privacy.

Then, there is the cross-prefix correlation issue. In section 3.3.,
Generating Temporary Addresses, RFC 4941 specifies that "New temporary
addresses MUST be created by appending the interface's current
randomized interface identifier to the prefix that was received." That
means that if different prefixes are configured, the temporary addresses
for all these prefixes will use the same IID. Again, that is not the
best way to protect privacy. Besides, 4941 requires running DAD on each
temporary address, so there is little reason to mandate a single
temporary IID per interface.

The algorithm specifies the use of MD5, which is now a bit unfortunate.
Using MD5 to generate random numbers in the specified way probably does
not pose any serious security issue, but there is a global push to just
get rid of MD5 everywhere. And in fact, there is no good reason to
specify any particular hash function -- at least, no interoperability
issue. SHA256, SHA512 or SHA3 would work just fine. There are probably a
couple more details like that.

-- Christian Huitema

---

From: Mark Smith <[email-masked]>
Date: Mon, 27 Mar 2017 06:52:07 +1100

Hi Fernando,

Sorry not to get back to you sooner.

Comments below, <snipping> bits I can't add to.

> Thanks so much for your feedback! Please find my comments in-line...
<snip>
> embedding such I-D into this one...

I don't think it is worth dealing with the details here either. Just a
simple "do this because of this broad/fundamental reason" should be
enough.

<snip>

> We're certainly going further than RFC4941: that's intentional.

OK. My interpretation was that the only change being made to RFC4941
was to drop the statement or a requirement that temporary addresses
were companions to stable addresses, rather than going further than
that.

> The goal

Yes, I would see that as one of the further updates to RFC4941.

<snip>
<snip>
<snip>
> mac address randomization or not...

I think for the purposes of the algorithm, it would be good to state
whether randomised MACs are desirable or don't really matter.

<snip>

Regards,
Mark.