Subject: Stephen Farrell's Discuss on draft-ietf-6man-default-iids-16: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 13 Dec 2016 05:53:58 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-6man-default-iids-16: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6man-default-iids/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Before I ballot yes on this there is one aspect I'd like
to briefly discuss...

Is this clear enough that it is not replacing temporary
addresses, and in saying when one ought use those vs. when
one ought use 7217? I'm not sure TBH, but, for me, this
text reads a bit too much as "use 7217 and not temporary
addresses" except for in the place where it says "For
example, this document does not change any existing
recommendations concerning the use of temporary addresses
as specified in [RFC4941],..." So my discuss point is: does
this document need more clarity as to when to use 7217 and
when to use 4941? I suspect it probably does need a more
clear statement about that, if we think we can reach
consensus on what that ought say;-)

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 3: is it correct to say "In particular, this
document RECOMMENDS that nodes do not generate stable
IIDs..." or do you really mean that nodes SHOULD NOT emit
packets with <those> in source addresses? IOW, do you mean
that nodes SHOULD NOT respond to packets addressed to
addresses using stable IIDs? I'm not clear from the text,
but am fine with either though I guess that could cause a
problem somewhere maybe.

---

From: "Alissa Cooper (alcoop)" <[email-masked]>
Date: Tue, 13 Dec 2016 15:47:52 +0000

Hi Stephen,

> On Dec 13, 2016, at 8:53 AM, Stephen Farrell <[email-masked]> wrote:
> 

The WG discussed this question at great length and the resulting language is the product of that discussion. In particular, we are careful to always use the qualifier “stable” when referring to the type of address for which the default recommendation is changing (like, in every paragraph of Section 1 and Section 3). I don’t know how to make this any clearer than it is in the last paragraph of Section 1, so please suggest text if you have something in mind.

I think if you consider the address scanning attack discussed in RFC 7721, the fact that the addresses are generated is what facilitates the attack. I’m not sure why we would say it’s ok to generate an address as long as you never use it, which is why the recommendation is against generating IIDs.

Thanks,
Alissa

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 14 Dec 2016 08:13:02 +1300

On 14/12/2016 04:47, Alissa Cooper (alcoop) wrote:
> The WG discussed this question at great length and the resulting language is the product of that discussion. 

+1. I think the current wording really does represent the balanced view of the WG.
There are many enterprise and campus networks that assume and rely on stable addresses
for desktop devices and this document aims to improve matters by getting rid of
MAC address visibility in that case. Whether a network adopts a stable address
policy is a quite separate operational question.

   Brian

> In particular, we are careful to always use the qualifier “stable” when referring to the type of address for which the default
recommendation is changing (like, in every paragraph of Section 1 and Section 3). I don’t know how to make this any clearer than
it is in the last paragraph of Section 1, so please suggest text if you have something in mind.
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 13 Dec 2016 22:14:02 +0000

Hiya,

> policy is a quite separate operational question.

Yeah, I was thinking about it in the meantime and can't come
up with something. I'll clear the discuss and make this some
kind of comment that folks can mull over or not as seems best
to them.

Cheers,
S.

---

From: Tim Chown <[email-masked]>
Date: Wed, 14 Dec 2016 11:28:44 +0000

On 13 Dec 2016, at 19:13, Brian E Carpenter <[email-masked]<mailto:[email-masked]>> wrote:

On Dec 13, 2016, at 8:53 AM, Stephen Farrell <[email-masked]<mailto:[email-masked]>> wrote:

Agreed.

The document says "this document does not change any existing recommendations concerning the use of temporary addresses as specified in [RFC4941<https://tools.ietf.org/html/rfc4941>], nor do the recommendations apply to cases where SLAAC is employed to generate non-stable IPv6 addresses”, which seems fine to me.

Related though, I’ve seen a few people referring to RFC 7217 addresses as “privacy addresses”. I think that’s wrong, because

a) the privacy addresses in RFC 4941 were designed both to change the IID randomly on attachment to a different network link *and* periodically when remaining on the same network (typically every 24 hours), which means RFC 4941 gives you privacy by location when moving between locations *and* over time when the device is static. e.g., a desktop;

b) the intent of RFC 4941 was to use privacy addresses to initiate new outbound connections, so you could not be correlated by third parties observing your fixed IID wherever you were. You would still also have a stable SLAAC or DHCP address that could be used to reach the device, were it running some service, e.g. a web cam.

So, RFC 7217 addresses the mobility privacy concern to some extent, but not the temporal privacy concern for non-mobile devices. It doesn’t fully address the mobility case because you will always have the same IID and address when you’re on the same prefix, e.g., your office, or your home. Hence for user privacy you’d want RFC 4941 temporary addresses as well.  Network admins having to deal with all those addresses may think differently.

It seems Mac OS Sierra use both RFC 7217 stable addresses, and RFC 4941 privacy addresses:

en4: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
options=10b<RXCSUM,TXCSUM,VLAN_HWTAGGING,AV>
ether 38:c9:86:2e:a4:ac
inet6 fe80::c73:4908:5069:e794%en4 prefixlen 64 secured scopeid 0xc
inet6 2001:630:50:d019:2b:d751:be42:8bcd prefixlen 64 autoconf secured
inet6 2001:630:50:d019:180d:746f:b6b6:835f prefixlen 64 autoconf temporary
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (1000baseT <full-duplex,flow-control>)
status: active

I believe Windows does the same.

Tim

  Brian

Thanks,
Alissa

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

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

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Dec 2016 18:03:29 -0300

Hi, Stephen,

Thanks for your feedback! Comments in-line...

On 12/13/2016 12:47 PM, Alissa Cooper (alcoop) wrote:
[....]
>> 
>> Is this clear enough that it is not replacing temporary addresses,
>> and in saying when one ought use those vs. when one ought use 7217?
>> I'm not sure TBH, but, for me, this text reads a bit too much as
>> "use 7217 and not temporary addresses" except for in the place
>> where it says "For example, this document does not change any
>> existing recommendations concerning the use of temporary addresses 
>> as specified in [RFC4941],..." So my discuss point is: does this
>> document need more clarity as to when to use 7217 and when to use
>> 4941? I suspect it probably does need a more clear statement about
>> that, if we think we can reach consensus on what that ought say;-)
> 
> The WG discussed this question at great length and the resulting
> language is the product of that discussion. In particular, we are
> careful to always use the qualifier “stable” when referring to the
> type of address for which the default recommendation is changing
> (like, in every paragraph of Section 1 and Section 3). I don’t know
> how to make this any clearer than it is in the last paragraph of
> Section 1, so please suggest text if you have something in mind.

+1 to everything Alissa said.

In addition:

1) For scanning attacks, it's the attacker that "uses" the addresss

2) For active host-tracking (you know the IID, and you know the possible
prefixes of networks where a node might be... and then you combine
prefixes and IID and continuusly poll each resulting address, to track
the node) it's the attacker that "uses" the address.

3) Then there could potentially be protocols that leak addresses (e.g.
"publish or transfer the list of all configured addresses), and in such
a case, even if you (or even the attacker) do not actively use the
address, the information leakage is still there.

Thanks!

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Fernando Gont <[email-masked]>
Date: Wed, 14 Dec 2016 18:27:46 -0300

Hi, Tim,

On 12/14/2016 08:28 AM, Tim Chown wrote:
>> On 13 Dec 2016, at 19:13, Brian E Carpenter
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>>> On Dec 13, 2016, at 8:53 AM, Stephen Farrell
>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
[....]
>>> language is the product of that discussion.
>>
> The document says "this document does not change any existing
> recommendations concerning the use of temporary addresses as specified
> in [RFC4941 <https://tools.ietf.org/html/rfc4941>], nor do the
> recommendations apply to cases where SLAAC is employed to generate
> non-stable IPv6 addresses”, which seems fine to me.
> 
> Related though, I’ve seen a few people referring to RFC 7217 addresses
> as “privacy addresses”. I think that’s wrong, because
> 
> a) the privacy addresses in RFC 4941 were designed both to change the
> IID randomly on attachment to a different network link *and*
> periodically when remaining on the same network (typically every 24
> hours), which means RFC 4941 gives you privacy by location when moving
> between locations *and* over time when the device is static. e.g., a
> desktop;

This is a side comment, but the benefits in such case are debatable.
Changing the IID within the same network over time may not buy you much
since, e.g.:

1) traffic patterns may leak your identity anyway, and... it's not clear
to what extent changing every 24hs vs not changing is worth the
operational expense. (OTOH, change it as you move buys you something...
although in this case, it's a design goal of RFC7217).

2) If there are not many hosts in the same subnet, changing the IID over
time within the same network will not conceal your identity a lot.

> So, RFC 7217 addresses the mobility privacy concern to some extent, but
> not the temporal privacy concern for non-mobile devices. It doesn’t
> fully address the mobility case because you will always have the same
> IID and address when you’re on the same prefix, e.g., your office, or
> your home. Hence for user privacy you’d want RFC 4941 temporary
> addresses as well.  Network admins having to deal with all those
> addresses may think differently.

I see RFC7217 and RFC4941 as tools. Depending on the scenarios, and how
you use these addresses, you may get the best tradeoff by using only ne
of them, or some combination of them. please see e.g.,
draft-gont-6man-address-usage-recommendations

> I believe Windows does the same.

FWIW, Fedora, Raspbian, and ArchLinux (to name a few), ship with RFC7217
on by default. IIRC, they don't enable RFC4941 by default.

Thanks!

Best regards,

---

From: Tim Chown <[email-masked]>
Date: Thu, 15 Dec 2016 09:22:47 +0000

Hi,

> On 14 Dec 2016, at 21:27, Fernando Gont <[email-masked]> wrote:
> 
> Hi, Tim,
> 

Right, but I think the privacy argument is that it all helps.  

And that from the user’s perspective extra privacy outweighs operational expense (but I’d argue that you need to monitor and manage IPv6 with different considerations to IPv4 anyway…).

Privacy in the context of a prefix-per-host maybe needs some thought, if you want a similar model there as currently applies to /128s. Currently draft-ietf-v6ops-unique-ipv6-prefix-per-host-01 has no security considerations text.

Agreed.

Thanks,

Tim

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 17 Dec 2016 11:49:29 -0800

On Thursday, December 15, 2016 1:23 AM, Tim Chown wrote:

>> ...

Of course, there are other identity cues besides IP addresses. HTTP cookies, for example. Hosts that want privacy need to manage for that across multiple layers. But if we assume that kind of host management for privacy, then changing addresses does help.

> Right, but I think the privacy argument is that it all helps.  

It does. There are two issues, hide the identity from local hosts, and hide the identity from remote hosts. It is true that just changing the IID does little to hide the identity from local hosts. To achieve that, the host would need to disconnect, change its MAC address, host name, and DHCP ID, and reconnect. With RFC7217, that may mean changing the local secret that goes in the IID computation formula. Even so, the host would have to be careful with all timing correlation, not to mention all kinds of metadata hiding in various places. 

But changing the IID removes the ability for remote hosts to use the IPv6 address as an identity cue. And that's definitely a good idea.

>> draft-gont-6man-address-usage-recommendations

The current proposal is designed so that a given host will always use the same IID on a given network. This is certainly a nice property for some network managers, but it is just one of the possible tradeoffs between manageability and privacy. There are other tradeoffs. For example, a privacy oriented extreme would be, changing the IID each time a machine wakes up. An in between would be, change every so many days. Once the current draft is published, maybe we need to work on another RFC explaining how to manage addresses for privacy.

-- Christian Huitema

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Dec 2016 03:19:19 -0300

Hi, Christian,

On 12/17/2016 04:49 PM, Christian Huitema wrote:
>>> ... This is a side comment, but the benefits in such case are
>>> debatable. Changing the IID within the same network over time may
>>> not buy you much since, e.g.:
>>> 
>>> 1) traffic patterns may leak your identity anyway, and... it's
>>> not clear to what extent changing every 24hs vs not changing is
>>> worth the operational expense. (OTOH, change it as you move buys
>>> you something... although in this case, it's a design goal of
>>> RFC7217).
> 
> Of course, there are other identity cues besides IP addresses. 

Not just that. The question is whether changing an address, say, every
24hs makes much of a difference wrt not changing it at all, in practical
cases.

e.g., on one extreme you'd use a new address for each new communication
instance, with clear benefits. On the other, you could have stable IIDs.
And in between there are tradeoffs.

>>> 2) If there are not many hosts in the same subnet, changing the
>>> IID over time within the same network will not conceal your
>>> identity a lot.
>> 
> It does. There are two issues, hide the identity from local hosts,
> and hide the identity from remote hosts. It is true that just
> changing the IID does little to hide the identity from local hosts.

I was referring about hiding the identity from remote hosts. Let's
assume an extreme scenario in which you have only one host in a prefix.
Changing the address will not be of any help. If you have only a few of
them, it's not much of a difference (particularly if the frequency of
change is fixed, as opposed to randomized).

> To achieve that, the host would need to disconnect, change its MAC
> address, host name, and DHCP ID, and reconnect. With RFC7217, that
> may mean changing the local secret that goes in the IID computation
> formula.

I guess in this case you could use the MAC address as the Net_Iface
parameter.

> Even so, the host would have to be careful with all timing
> correlation, not to mention all kinds of metadata hiding in various
> places.

Agreed.

>>> I see RFC7217 and RFC4941 as tools. Depending on the scenarios,
>>> and how you use these addresses, you may get the best tradeoff by
>>> using only ne of them, or some combination of them. please see
>>> e.g., draft-gont-6man-address-usage-recommendations
>> 
>> Agreed.
> 
> The current proposal is designed so that a given host will always use
> the same IID on a given network. This is certainly a nice property
> for some network managers, but it is just one of the possible
> tradeoffs between manageability and privacy. There are other
> tradeoffs. For example, a privacy oriented extreme would be, changing
> the IID each time a machine wakes up. An in between would be, change
> every so many days. Once the current draft is published, maybe we
> need to work on another RFC explaining how to manage addresses for
> privacy.

There are multiple aspects associated with addresses. It's not just what
types of addresses you configure, but also how you use them. For
example, currently, a node that employs temporary addresses will
typically accept incoming connections on such addresses (that were only
meant to be employed for outgoing connections). This has implications on
both privacy and security.

We started some work on the topic:
  * draft-gont-6man-address-usage-recommendations
  * draft-gont-6man-non-stable-iids

Please feel fee to send comments or join and contribute with edits.

Thanks!

Best regards,
Fernando

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 20 Dec 2016 23:01:59 +0900

> change is fixed, as opposed to randomized).

Only if other people know that a) there is only one host in the prefix and
b) the prefix never changes.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 20 Dec 2016 15:21:58 -0300

On 12/20/2016 11:01 AM, Lorenzo Colitti wrote:
> On Tue, Dec 20, 2016 at 3:19 PM, Fernando Gont <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Only if other people know that a) there is only one host in the prefix
> and b) the prefix never changes.

Agreed for "a)". For "b)", if the prefix changes RFC7217 will take care
of changing the IID (no need to change it yourself).

Thanks,