Subject: default-iids: Clarifying the use of stable addresses

From: Fernando Gont <[email-masked]>
Date: Fri, 20 May 2016 12:46:01 -0400

Folks,

In the hopes of making this document more clear regarding whether this
document is requiring the use of stable addresses, how about adding the
following text:

"SLAAC has traditionally resulted in stable addresses, since the IID
 has been generated by embedding a stable layer-2 numeric identifier
 (e.g., a MAC address). [RFC4941] implies, throughout the
 specification, that temporary addresses are generated and employed
 along with temporary addresses.

 We note that depending on the specific device type and/or operating
 environment, a host may or may not want to configure and/or use a
 stable address, but may e.g., exclusively use temporary addresses.

 This document does not require that stable addresses be actively
 employed or even generated, but simply provides a recommendation
 regarding how stable addresses should be generated when a node decides
 to do so.

 Similarly, this document is orthogonal to other privacy improvements
 such as MAC address randomization. This document aims to mitigate known
 security and privacy implications of stable IPv6 addresses in a
 hardware/protocol-independent manner, without any assumptions on the
 security/privacy properties of the underlying layers.
"

If you have suggestions for improvement, please do let me know, and send
proposed tweaks.

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

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Fri, 20 May 2016 23:10:15 +0000

> -----Original Message-----
> From: ipv6 [mailto:[email-masked]] On Behalf Of Fernando Gont
 
>  security/privacy properties of the underlying layers.

Fernando, it seems to me that the I-D as written, on this particular subject, is already abundantly clear. And it seems to me that your additional text would sound more like a lobbying effort to keep people from using stable addresses. Why the extra pitch? The whole point of this document is to provide guidance when people do want to use stable addresses. Presumably, they already know whatever security implications, and have other security implications that outweigh those of the more general public Internet client-server model.

The messages in this I-D are already clear. Normally, security in client-server interactions is improved when the clients have unpredictable and unstable addresses. However this I-D explains that when stable addresses are required, it's a bad idea to embed MAC addresses or any other stable address that belongs to a different layer, in the IPv6 address. Furthermore, when stable addresses are used, multiple stable addresses are used by an individual host, different IIDs should be used with each prefix.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 May 2016 10:47:16 +0900

On Sat, May 21, 2016 at 8:10 AM, Manfredi, Albert E <
[email-masked]> wrote:

> The messages in this I-D are already clear.

I disagree that they were already clear, and I think that something like
Fernando's text will help a lot to clarify them.

I will note, though, that this draft does the following:

   1. Deletes the text in RFC 2464 and other documents that defines how the
   IID is constructed, and replaces it with a pointer to this draft
   2. Makes it very clear that an implementation that does not choose to
   use a stable IID does not need to follow this draft

The combination of #1 and #2 means that an implementation that does not
choose to use a stable IID can legitimately form whatever IID it so chooses.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sat, 21 May 2016 02:15:25 +0000

From: Lorenzo Colitti [mailto:[email-masked]] 

> 1. Deletes the text in RFC 2464 and other documents that defines how the IID is constructed, and replaces it with a pointer to this draft

Yes, clearly does that, specifically for addresses that must be stable.

> 2. Makes it very clear that an implementation that does not choose to use a stable IID does not need to follow this draft

Non-stable addresses are very clearly out of scope of this draft, agreed. Want addresses that change frequently? Look elsewhere.

> The combination of #1 and #2 means that an implementation that does not choose to use a stable IID can legitimately form whatever IID it so chooses.

Well, again, that's out of scope. This draft should not be used for guidance concerning non-stable addresses, so why is this continuing to be such a bone of contention? It seems like all the additional text being proposed has to do with things that don’t relate to this draft at all. Then, don't use this draft!

For example, the whole thread about whether or not it is appropriate to use rapidly changing MAC addresses as IID, for non-stable IPv6 addresses, is a topic for some other draft, IMO. Not this one. Those considerations do not need to find their way in this draft at all.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 21 May 2016 12:23:13 +0900

On Sat, May 21, 2016 at 11:15 AM, Manfredi, Albert E <
[email-masked]> wrote:

> Well, again, that's out of scope. This draft should not be used for
> guidance concerning non-stable addresses, so why is this continuing to be
> such a bone of contention? It seems like all the additional text being
> proposed has to do with things that don’t relate to this draft at all.
> Then, don't use this draft!
>

All I'm saying is that if we publish this draft, then the formation of IPv6
IIDs on many link layers, including ethernet and wifi, becomes completely
unspecified, and implementations (well - implementations that don't want to
use stable IIDs) can do whatever they want with no recommendations or
guidance from the IETF.

---

From: Mark Smith <[email-masked]>
Date: Sat, 21 May 2016 13:29:12 +1000

On 21 May 2016 at 11:47, Lorenzo Colitti <[email-masked]> wrote:
> On Sat, May 21, 2016 at 8:10 AM, Manfredi, Albert E
> <[email-masked]> wrote:
>>
> Deletes the text in RFC 2464 and other documents that defines how the IID is
> constructed, and replaces it with a pointer to this draft
> Makes it very clear that an implementation that does not choose to use a
> stable IID does not need to follow this draft
>

Which I think is consistent with

"Significance of IPv6 Interface Identifiers"
https://tools.ietf.org/html/rfc7136

(without looking this draft being discussed because I'm about to go
out the door, it might be worth referencing that RFC if it usefully
supports some of the clarifications made).

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 May 2016 17:41:14 +1200

> supports some of the clarifications made).

So, reviewing the thread, I think we've been barking up the
wrong tree to some extent (hence the new subject header above).

RFC4941 aims to be compatible with SLAAC but it includes this
near the beginning of the protocol description:

'  2.  Create additional addresses based on a random interface
       identifier...'

In other words it's *explicit* that there is always an existing
address, which I think we agree is actually completely unnecessary
for client computers. (It's also at variance with some of the wording
in RFC4862, which frequently refers to IIDs as 'unique' per interface,
which can't be right, otherwise RFC4941 simply wouldn't work.)

So, I think some RFC needs to state that it is legitimate to have a host
with only RFC4941 global addresses.

Apart from that I'm quite happy with Lorenzo's comment above. Once
the IID bits have no semantics, anything goes.

Regards
   Brian

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 21 May 2016 12:09:01 +0200

Le 20/05/2016 à 18:46, Fernando Gont a écrit :
> Folks,
>
> In the hopes of making this document more clear regarding whether
> this document is requiring the use of stable addresses, how about
> adding the following text:
>
> (e.g., a MAC address)

Add [RFC2464] as a reference; dont allude to SLAAC, because:

> [RFC4941] implies, throughout the specification, that temporary
> addresses are generated and employed along with temporary addresses.

RFC4941 has a problem in that it treats the privacy problem of SLAAC 
only by looking at the IID.  But SLAAC is made of two parts: IID and 
prefix.  RFC4941 does not treat of the prefix randomization.

As such it is wrongly titled "Privacy Extensions of SLAAC" - it is 
"Privacy extensions in the IID" actually.

(RFC4191 has more problems, but we can discuss separately).

> stable address, but may e.g., exclusively use temporary addresses.

I agree.  They are called "client-only" devices.

> regarding how stable addresses should be generated when a node
> decides to do so.
>
> such as MAC address randomization.

I dont understand - an IID based on a random 48bit 'MAC' address has the 
same effect as randomizing an IID.  This is not orthogonal.

> This document aims to mitigate
> known security and privacy implications of stable IPv6 addresses in
> a hardware/protocol-independent manner, without any assumptions on
> the security/privacy properties of the underlying layers. "

I agree, but  we still dont have a problem description of what to 
mitigate - a risk analysis.

Alex

>
> If you have suggestions for improvement, please do let me know, and
> send proposed tweaks.
>
> Thanks,
>

---

From: Alexandre Petrescu <[email-masked]>
Date: Sat, 21 May 2016 12:12:12 +0200

> supports some of the clarifications made).

I agree with this point.  It is good to refer to that RFC about 
significance of IID...

Alex

>
>
> Regards,
> Mark.
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Mark Smith <[email-masked]>
Date: Sun, 22 May 2016 09:58:21 +1000

>> adding the following text:

<snip>

> RFC4941 has a problem in that it treats the privacy problem of SLAAC only by
> looking at the IID.  But SLAAC is made of two parts: IID and prefix.
> RFC4941 does not treat of the prefix randomization.
>
> As such it is wrongly titled "Privacy Extensions of SLAAC" - it is "Privacy
> extensions in the IID" actually.
>

I see your point, however that RFC is describing how privacy
extensions work with the SLAAC address configuration method, where as
a title of "Privacy extensions in the IID" would imply that it is not
address configuration method specific (in other words, would equally
apply to using DHCPv6 for address configuration.)

> I agree.  They are called "client-only" devices.

Actually, I wouldn't be so specific about their role.

For example, a file transfer between two smartphones would mean one of
them, for the purpose of the application, is acting as a server
(sender) while the other, for the purpose of the application, is
acting as a client (receiver). For the duration of the transfer, both
application server and client could be using temporary addresses, with
the application client discovering the application server's temporary
address via an application layer referral or announcement mechanism.

The temporary addresses only need to persist for as long as the file
transfer is taking place. RFC4941's default preferred lifetime of 1
day, and a valid lifetime of 1 week for temporary addresses is likely
to be long enough for most if not all of these types of applications
on personal devices like smartphones, tablets and PCs.

The roles of 'client' and 'server' don't exist at the IPv6 (and IPv4)
layer - devices at that layer are just packet senders or receivers -
or peers of each other. (I read [1] a while back, and it described
DECnet as the "first networking product to provide general-purpose,
peer-to-peer communications". The other popular layer 3 protocols
since have all been peer-to-peer.)

The roles of 'client' or 'server' are application layer concepts. It
is only IPv4 NAT that has created the requirement to consider devices
at the network layer to be 'clients' or 'servers'. As we don't need to
do NAT in IPv6, we don't need to both classify and constrain ourselves
to thinking of devices as exclusively being only one of either a
'client' or a 'server'.

[1] - "Overview of Digital's Open Networking" -
http://www.hpl.hp.com/hpjournal/dtj/vol5num1/vol5num1art1.txt

> same effect as randomizing an IID.  This is not orthogonal.

It's orthogonal because this group isn't trying to solve privacy
issues at both layer 3 and layer 2 at the same time. Tthey're separate
problems, because they occur at separate layers. The privacy and
functional issues at the different layers may be different - assuming
they aren't may result in a lack of privacy at one or both of the
layers because the proper problem analysis won't have been done.

> I agree, but  we still dont have a problem description of what to mitigate -
> a risk analysis.
>
> Alex
>
>>

Regards,
Mark.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 22 May 2016 19:31:23 +0000

-----Original Message-----
From: ipv6 [mailto:[email-masked]] On Behalf Of Mark Smith

> The roles of 'client' or 'server' are application layer concepts.
> It is only IPv4 NAT that has created the requirement to consider
> devices at the network layer to be 'clients' or 'servers'. As we
> don't need to do NAT in IPv6, we don't need to both classify and
> constrain ourselves to thinking of devices as exclusively being
> only one of either a 'client' or a 'server'.

Except that NAT also exists with IPv6, and that stable addresses are nice to have for IPv6 servers anyway, even without using NAT. And for other types of networks than the public Internet. E.g., some networks are peer-peer nets, sans DNS. They also want stable addresses.

Bert

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 15:39:07 -0400

On 05/20/2016 11:23 PM, Lorenzo Colitti wrote:
> On Sat, May 21, 2016 at 11:15 AM, Manfredi, Albert E
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
>     guidance concerning non-stable addresses, so why is this continuing
>     to be such a bone of contention? It seems like all the additional
>     text being proposed has to do with things that don’t relate to this
>     draft at all. Then, don't use this draft!
> 
> 
> All I'm saying is that if we publish this draft, then the formation of
> IPv6 IIDs on many link layers, including ethernet and wifi, becomes
> completely unspecified, and implementations (well - implementations that
> don't want to use stable IIDs) can do whatever they want with no
> recommendations or guidance from the IETF.

Huh?

Right now you have specs for stable adresses and RFC4941. This I-D
simply improves how you generate stable addresses. WHerever you'd embed
a link-layer id, you use RFC7217. That's it.

Where's the lack of guidance??

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Sun, 22 May 2016 15:48:27 -0400

> the IID bits have no semantics, anything goes.

Exactly. So this is not the document to blame for "requiring" stable
addresses. If anything, such requirement comes from elsewhere (e.g.
RFC4941), and *that* "elsewhere" is the document to complain about and
to update.

Thanks,

---

From: Mark Smith <[email-masked]>
Date: Mon, 23 May 2016 08:21:46 +1000

On 23 May 2016 5:31 AM, "Manfredi, Albert E" <[email-masked]>
wrote:
> Except that NAT also exists with IPv6,

So it is experimental.

The terms ''client' and 'server' don't exist in RFC2460 nor RFC791, so
there are no such roles in these protocols. Hosts are only packet senders
or receivers to or from their network layer peers.

I'm not arguing against stable addresses. I see use cases relevant to me
for temporary only (my smart phone), temporary + stable (my tower PC at
home that I use as both a client and a server for different apps) and
stable only (routers that I need to login to to administer and whose
interface addresses are used by hosts and other routers).

I think the mistake Lorenzo might be making is confusing stable with
permanent and unchangeable "to the end of time".

RFC7217 addresses are not permanent. An operator can cause one to change at
any time, by reinitialising the algorithm with a different secret key or
other parameters that will cause the IID to change. A fresh OS install will
cause new ones to be generated. The computer itself will be replaced at
some point, and that should cause new RFC7217s to be generated.

A virtual machine will be able to persist in operation much longer than
hardware, however at some point its operating system and software is likely
to become obsolete and replaced. If that possible time span is too long,  a
policy of generating new addresses every 5 years could be put in place.

MAC addresses are permanent, as they're burnt into the card. Yet how many
permanent MAC addresses from the NICs in the 2000s, 1990s or earlier would
be in use today? Permanence in computing isn't very permanent.

I think very few RFC7217 addresses will exist for any longer than 10 years.
The few that do can be easily changed if necessary, for the use cases where
stable addresses are necessary or desirable.

Regards,
Mark.

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 May 2016 08:08:36 +0900

> Where's the lack of guidance??

Here's the lack of guidance. Take Ethernet. After this document is
published, all the text in RFC 2464 is replaced by this text:

   The Interface Identifier [AARCH] for an Ethernet interface MUST be
   generated as specified in [RFCXXXX].

RFCXXXX says that it applies only if an implementation wants to create a
stable address, and that that is OPTIONAL.

If an implementation does not want to create a stable address, there is no
guidance as to what it should do. I assume that means it can do whatever it
wants.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Sun, 22 May 2016 23:31:10 +0000

> RFCXXXX says that it applies only if an implementation wants to create a stable
> address, and that that is OPTIONAL.

It's only "optional" in the sense that RFC 2460-bis might say it's optional. Stable addresses are mandatory in some networks, with some security protocols, in some networks functions, and so on. So I'm not sold on this "optional," except in the sense that a general IPv6 Standard might say.

> guidance as to what it should do. I assume that means it can do whatever it wants.

But that guidance should not be in this draft anyway, so it's not necessarily correct to say that they can do whatever they want. They can do whatever the guidance for non-stable addresses is, in other RFCs. This draft does not need to care.

Bert

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 23 May 2016 10:09:55 +0900

On Mon, May 23, 2016 at 8:31 AM, Manfredi, Albert E <
[email-masked]> wrote:

> But that guidance should not be in this draft anyway, so it's not
> necessarily correct to say that they can do whatever they want. They can do
> whatever the guidance for non-stable addresses is, in other RFCs. This
> draft does not need to care.
>

If we all understand that this draft is removing all existing guidance, and
we have WG consensus to do so, that's fine.

Personally I think we can't just leave this up to host implementations. If
some ill-considered implementation decides that its IID generation
algorithm is "pick a random IID between :: and ::ff", it would satisfy this
draft, but I think we need to be able to say that that implementation is
broken.

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 07:58:09 -0400

On 05/22/2016 07:08 PM, Lorenzo Colitti wrote:
> On Mon, May 23, 2016 at 4:39 AM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> If an implementation does not want to create a stable address, there is
> no guidance as to what it should do. I assume that means it can do
> whatever it wants.

That is not because of this document, but because of the additional step
you want this document to make.

Right now this document just improves stable addresses. And such
addresses are required to be there because of RFC2464 and RFC4941.

If you want to remove such requirement (which is *not* introduced by our
document), you'll obviously have to provide advice on what to do if you
don't want stable addresses (temp-addr only?).

That's why I stressed that the inclusing of your text "...OPTIONAL" is
an additional step, and not what this document is meant to do.

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 May 2016 00:25:49 +0900

> you want this document to make.

If you're saying that this is "because of the additional step I want this
document to make", then you must be saying that the document as it is now
says that implementations SHOULD create stable addresses all the time.
Which was one of my points all along.

Not sure how that fits with your continued previous assertions that "this
document only affects implementations that want to create stable
addresses", but... good to see that you, as one of the authors, agrees with
me on what the document currently says about this.

Now that we agree on what the document says about this, let me repeat my
concern: it is not acceptable, in 2016, to say that implementations SHOULD
create stable addresses all the time.

Cheers,
Lorenzo

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:41:09 -0400

On 05/23/2016 11:25 AM, Lorenzo Colitti wrote:
> On Mon, May 23, 2016 at 8:58 PM, Fernando Gont <[email-masked]
> If you're saying that this is "because of the additional step I want
> this document to make", then you must be saying that the document as it
> is now says that implementations SHOULD create stable addresses all the
> time. Which was one of my points all along.

This document doesn't say anything in that respect. Whatever was the
requirement, is not changed. If there's any requirement for stable
addresses, that's *inherited* from the existing specs. (Please see the
other document I just posted, which might help).

This document does not say anything regarding whether you should create
stable addresses or not. It says that if you do, you should employ, by
default, RFC7112.

Right now, all nodes configure stable addresses. If our document gets
published, all nodes still configure stable addresses -- *no changes
here*! (modulo that the stable addresses will now be based on RFC7217).

If you want to (optionally) get rid of stable addresses, that's
orthogonal with default-iids. I personally symphatize with the idea. I
just think that this is not what default-iids is about. But since I
symphatize with the idea, I've saved you time and posted this:
<https://www.ietf.org/internet-drafts/draft-gont-6man-non-stable-iids-00.txt>

Thanks,

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 May 2016 00:48:24 +0900

> other document I just posted, which might help).

Yes, the document does not say anything about this. But the fact remains:
if the document is published as is, then that is what the IETF standards
will say: SHOULD create stable addresses.

Like I said, I think this is not something this WG can credibly do in 2016.
A major overhaul of all the IPv6-over-foo specs, as proposed in this
document, *must* have a much higher bar for privacy than "a little bit
better than 1996".

---

From: Fernando Gont <[email-masked]>
Date: Mon, 23 May 2016 11:56:56 -0400

On 05/23/2016 11:48 AM, Lorenzo Colitti wrote:
> On Tue, May 24, 2016 at 12:41 AM, Fernando Gont <[email-masked]
> Yes, the document does not say anything about this. But the fact
> remains: if the document is published as is, then that is what the IETF
> standards will say: SHOULD create stable addresses.

Exactly. The other document we posted changes that fact.

And changing that fact is orthogonal.

> Like I said, I think this is not something this WG can credibly do in
> 2016. A major overhaul of all the IPv6-over-foo specs, as proposed in
> this document, *must* have a much higher bar for privacy than "a little
> bit better than 1996".

They are separate issues. default-iids is "iff you do stable addresses,
do this". The other document we posted is more of "should we do stable
addresses?".

There are scenarios where stable addresses (only, or +temp addresses)
are desirable. So improving them is valuable.

Obviously, it's also valuable to allow for temp addr only. But divide
and conquer.