Subject: IPv6 Privacy Considerations

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 09:21:03 -0400

Many people are concerned about privacy on the Internet.
Indeed, there was specific strong external pressure on the 
IETF -- 15 years ago -- to create the IPv6 Privacy Extensions 
(originally published as RFC-3041).  This all was LONG BEFORE
the widely broadcast allegations from last year.

The use of "static" DHCP in many residential broadband deployments
means that a given household will have the same IPv4 address,
provided via DHCP, for months or years at a time.  These are
known to be used for tracking users both by commercial firms
seeking profit (despite the loss of user privacy) and are
alleged to be used by multiple governments on multiple continents.
Some nations, often those without strong traditions of Freedom 
of Speech, reportedly are very aggressive about monitoring
which users post which comments so they can arrest dissidents.
At least one nation is believed to place its Internet users
behind a national firewall, in part to facilitate such tracking.

DHCP necessarily facilities user tracking; many DHCP deployments
keep logs of when particular IP addresses were OFFERed or RENEWed
and which user had a given IP address at a given time.  So it is
no surprise that many perceive DHCP as a mechanism to remove or 
reduce user privacy.

Those IPv6 Privacy Extensions are very important to many people.
For them to be effective, IIDs need certain properties.  These
IID properties include:

1) Sufficiently large to have a tiny chance of collisions from
   locally-generated IIDs on a particular IPv6 link/subnet.
2) Sufficiently large to have enough entropy and unpredictability
   so that it is impractical to track users through the IPv6 IID
   or through the IPv6 address.

There are some specific environments (e.g. businesses/workplaces) 
where all of the computing and networking infrastructure are owned 
and operated by a single entity and where different ("workplace") 
terms of use apply than on the general Internet.  In those
environments, DHCP can be a useful tool for reducing operational
costs and there also is a diminished expectation of privacy on the
part of users (e.g. since they aren't paying for the Internet service,
for the local infrastructure, or for the desktop computer). 
As best I can tell, when DHCPv6 is used in such environments,
it often is used to cause the device to use its internal hardware
Link/MAC-layer address to form the IID.  This makes inventory and
accounting easier.  Many IPv6 hosts now do support DHCPv6.

Reports indicate that such organisations generally are able to
receive a sufficient supply of IPv6 addresses to use global-scope
addressing.  However, the existence of ULAs means that if using
global-scope addresses is undesirable (e.g., for security reasons)
or there is some local difficulty in obtaining enough global-scope
addresses, it is still practical to retain a 64-bit IID.  

Separately, some folks less familiar with IPv4 think that having
only 64-bits of routing goop means that 2^^64 is the number of
end systems.  Of course, folks here will recall that this really
means that 2^^64 is the number of *subnets* available, with each
subnet being able to support an extremely large number of nodes.

The IETF and particularly the IPv6 Working Group need to keep these 
privacy concerns in mind and avoid creating a situation
where changes to the IPv6 specifications have the result that ISPs
(in practice) require end users to use DHCP for their residential 
connections because SLAAC ceases to be a practical deployment option.

Yours,

Ran Atkinson

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Thu, 13 Mar 2014 14:34:58 +0100

> connections because SLAAC ceases to be a practical deployment option.

I agree.

However, having not kept up with ipng/ipv6/6man or whatever it's called these days I'm not sure what made you send this message, or the previous one. I.e., what are the problematic drafts?

But isn't any effort to break existing stateless autoconfig completely futile anyway? IPv6 has been around (in some form) for nearly two decades, with hundreds of millions of implementations out in the field. Writing a specification that assumes that all current systems are going to be upgraded is a complete waste of time.

(Then again, the whole ip6.int / ip6.arpa thing was a huge waste of time, too, but we did it anyway.)

Even changes that are supposed to be backward compatible have proven incredibly hard to deploy, see for instance ECN.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 13 Mar 2014 13:49:26 +0000

> The IETF and particularly the IPv6 Working Group need to keep these privacy
> concerns in mind and avoid creating a situation where changes to the IPv6
> specifications have the result that ISPs (in practice) require end users to use
> DHCP for their residential connections because SLAAC ceases to be a practical
> deployment option.

Every residential deployment I'm aware either uses DHCPv6 IA_PD to supply the prefix, or 6rd (where the prefix is based on the IPv4 address, which can be static or dynamic, from DHCPv4 or IPCP).
Thanks to strong IETF pressure to keep these DHCPv6 prefixes as static as possible, it appears that most wireline providers do intend to move to a model of static IPv6 prefixes.
When the IPv4 address or IPv6 prefix (to the residence) changes frequently, the only way to get a consistent IP address to residence mapping was to ask the ISP to maintain that mapping and provide it frequently. In this coming environment that will no longer be necessary. Figure the mapping out once and you never have to go back to the ISP again.

Change the last 64 bits all you want -- the best you can do is force "them" to guess which device it was or which person (it wasn't me! -- it was my spouse/child/parent/silbling/etc.). That's a fairly thin layer of privacy.

Not that I'm opposed to suggestions to randomize those 64 bits. I just think that if privacy is really the goal, then doing this on a static prefix shared by a small number of people is rather futile.
Barbara

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 10:22:06 -0400

On 13  Mar 2014, at 09:49 , STARK, BARBARA H wrote:
> Every residential deployment I'm aware either uses DHCPv6 IA_PD
> to supply the prefix, or 6rd (where the prefix is based on the IPv4 address,
> which can be static or dynamic, from DHCPv4 or IPCP).

I'm aware of at least some residential Ipv6 deployments in some 
countries that use SLAAC rather than DHCPv6. 

Similarly, at least some "wireless hotspot" deployments today
use SLAAC and put all users from that one hotspot (e.g. coffee shop)
on the same IPv6 routing prefix.  Using SLAAC and an unpredictable
IPv6 IID on such links can help with privacy.

> Thanks to strong IETF pressure to keep these DHCPv6 prefixes as static
> as possible, it appears that most wireline providers do intend to move
> to a model of static IPv6 prefixes.

Which IETF RFCs are you thinking of that apply "strong IETF pressure" 
for ISPs to have very static IPv6 prefix allocations ?

Did those RFCs at least document the privacy tradeoffs ?

> When the IPv4 address or IPv6 prefix (to the residence) changes frequently,
> the only way to get a consistent IP address to residence mapping was
> to ask the ISP to maintain that mapping and provide it frequently.

I'm having trouble parsing that sentence, but it seems to be agreeing 
that DHCP logs are used today to track users (i.e. the privacy issue
is real).

> In this coming environment that will no longer be necessary.
> Figure the mapping out once and you never have to go back to the ISP again.

This seems undesirable from a user privacy perspective.

Thanks for the detailed view from your world. :-)

Yours,

Ran Atkinson

---

From: [email-masked]
Date: Thu, 13 Mar 2014 15:45:55 +0100 (CET)

> IPv6 IID on such links can help with privacy.

If DHCPv4 is acceptable, I would expect DHCPv6 IA_NA, or DHCPv6 IA_PD
(with a suitable non identifiable user part) to be equally acceptable.
Am I wrong here?

> for ISPs to have very static IPv6 prefix allocations ?

We see strong *user* pressure to keep addresses handed out with DHCP
to be as static as possible (for instance so that users can run servers
on their DHCP addresses).

> that DHCP logs are used today to track users (i.e. the privacy issue

In some places we have *legal requirements* to be able to track address
to customer mapping this way. Note that customer is not necessarily the
same as user (e.g. a customer could represent a household).

Steinar Haug, AS 2116

---

From: RJ Atkinson <[email-masked]>
Date: Thu, 13 Mar 2014 11:11:33 -0400

> (with a suitable non identifiable user part) to be equally acceptable.

I suspect that the answer depends very much on the user
and on their surrounding environment.  

Some users are not very concerned about privacy, or possibly
don't fully understand the privacy issues.  Other users are 
very concerned about privacy.  

Separately, with IPv4 there is no analogue to SLAAC, so one
ends up with DHCPv4 simply because no other/better alternative
exists.

I doubt very much that any answer on privacy would be
universally applicable.

> on their DHCP addresses).

Useful operational data.  Thanks.

I also know of users who prefer to have dynamic address assignments, 
and then use Secure Dynamic DNS Update (or similar methods) 
to update their server A/AAAA records.

> In some places we have *legal requirements* to be able to track
> address to customer mapping this way. Note that customer is not
> necessarily the same as user (e.g. a customer could represent
> a household).
 
Thanks for the confirmation that DHCP is being used at present 
to track "customers".  This probably would be worth adding as 
explanatory text in a privacy document someplace, if it isn't 
already well documented.

Yours,

Ran

---

From: Philip Homburg <[email-masked]>
Date: Thu, 13 Mar 2014 15:46:42 +0100

>IPv6 IID on such links can help with privacy.

Just about every IPv6 subnet on ethernet or wifi that I have seen uses
SLAAC for address configuration. By embedding the MAC address in the generated
IPv6 address, any device that moves across networks can be tracked easily.

So privacy extensions solve a problem where IPv6 would be worse than
IPv4 in this respect.

---

From: Peter Dordal <[email-masked]>
Date: Thu, 13 Mar 2014 13:21:26 -0500

On 03/13/2014 08:49 AM, STARK, BARBARA
H wrote:

Too true.

And the situation becomes even worse if web browsing is involved.

Nonetheless, I think it is very important to preserve end-user
"privacy" options for the

low-order 64 bits (that is, SLAAC). The situation with the
high-order bits can potentially

change; perhaps a privacy market will develop there. But if changing
the low-order bits

becomes impossible, there are few alternatives.

(Also, I would not discount the utility of multi-host
spouse/child/etc confusion in improving

privacy from non-governmental watchers.)

Peter Dordal

Loyola Univ Chicago CS Dept

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2014 15:32:10 +0100

In your previous mail you wrote:

>  Change the last 64 bits all you want -- the best you can do is force "them" 
>  to guess which device it was or which person (it wasn't me! -- it was my spo
>  use/child/parent/silbling/etc.). That's a fairly thin layer of privacy.
>  
>  Not that I'm opposed to suggestions to randomize those 64 bits. I just think
>   that if privacy is really the goal, then doing this on a static prefix shar
>  ed by a small number of people is rather futile.

=> this is not new. In fact when the RFC 3041 was published I had a
concern I can summarize as "RFC 3041 was a bad response to a bad
"about privacy" argument". I even wrote an I-D titled
"RFC 3041 Considered Harmful" which was BTW integrated into RFC 4941,
i.e., the current version of privacy extensions for SAAC.
 I am afraid most of the IPv6 privacy discussion is not really
technical so there is nearly nothing we can (or should?) do at
the IETF...

Regards

[email-masked]

PS: I have 3 ISPs, one is Free with 6rd and a fixed IPv4 address
(so IPv6 64 bit prefix), a second is for servers with IPv4/IPv6
(fix address and prefix too). The last one is IPv4 only with a
changing address and I use it only as a backup...

---

From: Francis Dupont <[email-masked]>
Date: Fri, 14 Mar 2014 15:53:44 +0100

>  very concerned about privacy.  

=> you have a trade-off between privacy and to be able to run
a server so IMHO there is a place for both. BTW this doesn't
mean the ISP has to choose for me...

>  I doubt very much that any answer on privacy would be

=> an unique answer no but there are places (vs. US) where privacy
has a strong legal meaning, for instance in Europe. So I am
afraid this discussion won't be closed soon even there is nothing
we could do on the technical / IETF side.

>  Useful operational data.  Thanks.

=> my primary DNS server uses a 6rd fixed IPv6 address for instance
(and not an IPv4 one because it is behind a NAT :-).

>  to update their server A/AAAA records.

=> painful, not very reliable, etc. IMHO it is far better to get
a static address (and it is a critical point when I choose an ISP).
Note I know how to do (and it was a good exercise for students 10
years ago for the AAAA part).

>  explanatory text in a privacy document someplace, if it isn't 

=> ISPs must keep "connection data" for many monthes everywhere in
Europe. But they are personal data too so ISPs must protect them
against unlawful accesses, declare security issues, etc.
So if the situation is simple from a technical point of view
(DHCP leases are logged) it is complex on the legal side.
Now what you want to put in the "IETF" text?

Thanks

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Mar 2014 03:32:25 +1100

If one is really worried ISP's could give out both stable and
unstable prefixes.  We just need a way to identify which is which.

If you are running servers you put them on the stable prefixes.
You assign temporary addresses out of the unstable prefixes.

IA_NA, IA_PD and SLAAC all need to be supported.

As for dynamic updates, they do work provided there is a service
which continues to attempt to do the update when the name servers
for the zones are unreachable.

It also requires dynamic DNS providers to support UPDATE + TSIG
and/or SIG(0) for all their customers.  SIG(0) is better from a
compromised server perspective as the provider is just storing a
public key usually in the zone being updated.

Registrars also need to support UPDATE + TSIG and/or SIG(0) to
update glue records for those that want to host their own zones.
draft-andrews-dnsop-update-parent-zones-04 provides a outline of
how to do this.  This works for any parent zone not just RRR managed
zones.

It is possible to make slave name servers use the source address
of NOTIFY + TSIG and/or SIG(0) messages to determine where to
transfer the zone content from.  This is just a exercise in coding
as all the protocol elements already exist to do this.  Normally
you would store the KEY record in the zone at the apex if you were
doing SIG(0).

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 14 Mar 2014 10:09:31 -0700

> IA_NA, IA_PD and SLAAC all need to be supported.
Mark,

I don't know how important it is to solve this, but *if* we want to 
solve it we might have a way do to it using existing protocol mechanism 
(the lifetimes) in DHCP and in SLAAC.

For example, if a host doing SLAAC receives two prefixes (with A=1) in 
RAs: one having a lifetime of 30 days and one having a lifetime of 1 day 
(or 1 hour), then the host implementation of temporary address can pick 
those from the short lifetime prefix, while picking the stable-privacy 
address from the long-lived prefix. No on the wire change needed.

Likewise, a DHCP server in a home gateway might receive two (or more) 
prefixes from the ISP using IA_PD, with very different lifetimes. When 
such a DHCP servers handles a IA_NA it could pick from the long-lived 
prefix(es), while IA_TA is picked from the short-lived prefix(es).

But the first question is whether we want to work on this problem area.

    Erik

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 14 Mar 2014 17:51:41 -0700 (PDT)

----- Original Message -----
> From: RJ Atkinson <[email-masked]>
> To: [email-masked]
> Cc: 
> Sent: Friday, 14 March 2014 1:22 AM
> Subject: Re: IPv6 Privacy Considerations
> 
> 

I'm not quite sure if Barbara was referring to just prefix delegation via DHCPv6 or both PD and direct CPE assignment.

The Internode production deployment of IPv6 here in .au (with around 16K subscribers now), used SLAAC for CPE address assignment and DHCPv6 PD for prefix delegation. The advantage of using SLAAC for CPE address assignment is that SLAAC is/was more widely supported than DHCPv6, and also you can plug a host directly into the service to simplify troubleshooting, or just to facilitate customers who don't want or need a CPE just to attach their single host.

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

---

From: Mark Andrews <[email-masked]>
Date: Sat, 15 Mar 2014 13:37:36 +1100

> (the lifetimes) in DHCP and in SLAAC.

It needs to be explicit.  As for the importance this may be forced
on us.

Personally I've used the same prefix at home for 10 years and it
doesn't bother me.  The IPv4 address I have is dynamic but only
changes when my ISP needs to split nodes.  I'm not particularly
worried as there are lots of ways to track a machine.  But for those
that are worried it would be nice to have this sort of functionality.

---

From: Hesham Soliman <[email-masked]>
Date: Sun, 16 Mar 2014 22:57:31 +1100

>technical so there is nearly nothing we can (or should?) do at

=> FWIW +1. Especially if you consider how mobile networks are allocating
IPv6 addresses, i.e. /64 per device.
Makes the IID irrelevant. And these are the majority of devices on the
Internet. 

Hesham