Subject: [Int-area] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt

From: Tom Herbert <[email-masked]>
Date: Mon, 19 Feb 2018 11:15:46 -0800

Hello,

This draft discusses issue of privacy in IPv6 network prefix
assignment. Specifically the privacy problems of an assigned network
prefix becoming a persistent identifier for devices (e.g. /64
assignment to devices in mobile networks).  The use of
identifier/locator split is suggested as a solution.

Thanks,
Tom

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Feb 19, 2018 at 11:06 AM
Subject: New Version Notification for
draft-herbert-ipv6-prefix-address-privacy-00.txt
To: Tom Herbert <[email-masked]>

A new version of I-D, draft-herbert-ipv6-prefix-address-privacy-00.txt
has been successfully submitted by Tom Herbert and posted to the
IETF repository.

Name:           draft-herbert-ipv6-prefix-address-privacy
Revision:       00
Title:          Privacy in IPv6 Network Prefix Assignment
Document date:  2018-02-20
Group:          Individual Submission
Pages:          17
URL:
https://www.ietf.org/internet-drafts/draft-herbert-ipv6-prefix-address-privacy-00.txt
Status:
https://datatracker.ietf.org/doc/draft-herbert-ipv6-prefix-address-privacy/
Htmlized:
https://tools.ietf.org/html/draft-herbert-ipv6-prefix-address-privacy-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-herbert-ipv6-prefix-address-privacy-00

Abstract:
   This document discusses privacy concerns around network prefix
   assignment in IPv6. It evaluates the privacy threat, proposes a set
   of ideal criteria for strong privacy, and suggests solutions to
   achieve a high degree of privacy in addressing.

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: Jon Crowcroft <[email-masked]>
Date: Tue, 20 Feb 2018 08:06:32 +0000

people may already have read this (and its a while back) but interesting to
see the limited but non zero use of privacy v6 addr
https://www.akamai.com/uk/en/multimedia/documents/technical-publication/temporal-and-spatial-classification-of-active-ipv6-addresses-technical-publication.pdf

On Mon, Feb 19, 2018 at 7:15 PM, Tom Herbert <[email-masked]> wrote:

> _______________________________________________
> 5gangip mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/5gangip
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 20 Feb 2018 22:32:24 -0800

Jon,

Thanks for the reference. I think that both spatial and temporal
characteristics should be part of strong privacy addresses. Will update the
draft to mention those.

One thing that I'm not sure how to quantify yet is the effects of using
addresses for narrow purposes like a single flow. For instance, if a packet
is seen with some address that might not be useful as a target of attack by
trying to connect to the address. No application would be listening on such
addresses (although this does make ICMP interesting, like whether there
should be a response to echo request).

Tom

On Feb 20, 2018 2:06 AM, "Jon Crowcroft" <[email-masked]> wrote:

people may already have read this (and its a while back) but interesting to
see the limited but non zero use of privacy v6 addr
https://www.akamai.com/uk/en/multimedia/documents/technical-publication/
temporal-and-spatial-classification-of-active-ipv6-addresses-technical-
publication.pdf

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 21 Feb 2018 22:08:36 +0900

> identifier/locator split is suggested as a solution.

The draft should state that like any IP address assignment scheme, the
addresses used by the host are visible to the network operator and anyone
with access to the network operator logs or power to compel the network
operator. Thus, randomizing IP addresses does not protect against
large-scale surveillance, it can only protect against tracking by third
parties.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Feb 2018 15:55:32 +0100 (CET)

On Mon, 19 Feb 2018, Tom Herbert wrote:

> This draft discusses issue of privacy in IPv6 network prefix assignment. 
> Specifically the privacy problems of an assigned network prefix becoming 
> a persistent identifier for devices (e.g. /64 assignment to devices in 
> mobile networks).  The use of identifier/locator split is suggested as a 
> solution.

Current state of available address for a PDN is /64. In most 
implementations I am aware of, if the PDN is brought down, and then up 
again, a new /64 will be used. The host can therefore control this part of 
"privacy", cycle PDN when it feels it's appropriate to get new address 
space to avoid tracking. I am supportive of this approach and any spatial 
overlap of multiple PDNs/address space approach, so that connections can 
be moved over to use the new address, gracefully.

I consider anything that gives the host less than /64 worth of addresses a 
regression from current situation. We can always discuss if /80 is enough 
etc, but anyhow, it's a regression that should be presented front and 
center by any proposed change to current state of affairs.

I have now read section 6 twice, and I still have no idea how many usable 
addresses the host has available to itself according to 
draft-herbert-ipv6-prefix-address-privacy-00.

Can you please enlighten me?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Feb 2018 00:03:30 +0900

On Wed, Feb 21, 2018 at 11:55 PM, Mikael Abrahamsson <[email-masked]>
wrote:
>> Specifically the privacy problems of an assigned network prefix becoming a
>> persistent identifier for devices (e.g. /64 assignment to devices in mobile
>> networks).  The use of identifier/locator split is suggested as a solution.
>>
>
> overlap of multiple PDNs/address space approach, so that connections can be
> moved over to use the new address, gracefully.
>

+1

> center by any proposed change to current state of affairs.

+1

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Feb 2018 07:23:52 -0800

> large-scale surveillance, it can only protect against tracking by third

Lorenzo,

AFAICT, the legal requirements for providers to store and provide logs
varies by jurisdication. The EU seems to be pretty far along in
specifying this. In 2016 an EU court ruled that IP addresses are
personally identifiable information (PII) when combined with other
information that can reveal identity. A network provider in it's
normal operations will know the identity of nodes to which it assign
addresses and so must safeguard the information since it is PII.
Providers are required to log addressing mappings (like NAT mappings)
and must release individual records per legal request. However, I
don't think under these rules providers are compelled to blindly
provide all logs to authorities for the purposes of data mining (if
someone else knows otherwise please interject here).

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Feb 2018 00:28:13 +0900

... while in certain other countries, pervasive monitoring was, er...
pervasive.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Feb 2018 16:30:56 +0100 (CET)

> someone else knows otherwise please interject here).

I think you can safely assume that there are juristictions in the world 
where the authorities have real-time and historical full access to 
anything the operator has logged.

However, there is no technical solution to this human problem, so I don't 
see it as anything we can solve.

Apart from that, it seems to me that you're both saying the same thing.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Feb 2018 07:47:32 -0800

On Wed, Feb 21, 2018 at 6:55 AM, Mikael Abrahamsson <[email-masked]> wrote:
> Current state of available address for a PDN is /64. In most implementations
> I am aware of, if the PDN is brought down, and then up again, a new /64 will
> be used. The host can therefore control this part of "privacy", cycle PDN
> when it feels it's appropriate to get new address space to avoid tracking. I
> am supportive of this approach and any spatial overlap of multiple
> PDNs/address space approach, so that connections can be moved over to use
> the new address, gracefully.
>
> etc, but anyhow, it's a regression that should be presented front and center
> by any proposed change to current state of affairs.
>
Mikael,

As mentioned in section 6, addresses contain no hierachy beyond the
provider prefix so the space over which addresses are assign can be
flat large space (/32, /48, etc). The goal is that from any outside
observer all addresses seem to be randomly chosen from the space with
no means to create correlations.

Host are assigned addresses from the space. The goal is that all
addresses appear to be randomly assigned in that space. Conceptually,
a host could request assignment for inidivual millions or billions of
addresses, but that won't scale. The alternative suggested is to
assign addresses in blocks using hidden aggregation as described in
section 6.2.2.2. Blocks would contain multiple addresses (could be
thousands, millions, etc.).

Tom

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 21 Feb 2018 17:03:34 +0100 (CET)

On Wed, 21 Feb 2018, Tom Herbert wrote:

> addresses appear to be randomly assigned in that space. Conceptually, a 
> host could request assignment for inidivual millions or billions of 
> addresses, but that won't scale. The alternative suggested is to assign 
> addresses in blocks using hidden aggregation as described in section 
> 6.2.2.2. Blocks would contain multiple addresses (could be thousands, 
> millions, etc.).

This means the host still needs to cycle these blocks over time to 
maintain privacy. Does the scaling still support a host having hundreds of 
these blocks at any given time?

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Feb 2018 17:51:57 -0800

On Wed, Feb 21, 2018 at 8:03 AM, Mikael Abrahamsson <[email-masked]> wrote:
>> Host are assigned addresses from the space. The goal is that all addresses
>> appear to be randomly assigned in that space. Conceptually, a host could
>> request assignment for inidivual millions or billions of addresses, but that
>> won't scale. The alternative suggested is to assign addresses in blocks
>> using hidden aggregation as described in section 6.2.2.2. Blocks would
>> contain multiple addresses (could be thousands, millions, etc.).
>
>
> This means the host still needs to cycle these blocks over time to maintain
> privacy. Does the scaling still support a host having hundreds of these
> blocks at any given time?
>

Mikael,

Yes, blocks are a finite resource and so would have to have TTL and be
reclaimed. Also, if keys are involved in address creation they would
need expected management and key rotation. Address space should be big
enough to make long TTLs.

The hidden aggregation method is intended to make scaling possible.
Each assigned block results in on entry in mapping system so total
amount of state is num_hosts*num_blocks per host. e.g. in a network of
10M nodes with 100 blocks per host that's 1B entries in the mapping
system-- should be able to scale that. If block size is 2^16 then if
every address is in the mapping system it's 6.5e11-- harder to scale.
Aggregation is needed keep network state reasonable for scaling, but
aggregation that is visible to the outside world exposes information
about network internals of network and potentially PII as discussed in
the draft.

Tom

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 22 Feb 2018 12:38:15 +0900

On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert <[email-masked]> wrote:

> system-- should be able to scale that.

I have a fundamental problem with the assertion "should be able to scale to
1B mapping entries" given that a) current routing hardware capabilities are
three orders of magnitude away from that, and b) anyone on the Internet can
mount a state exhaustion attack on the mapping system simply by originating
a packet to any IPv6 address in the domain.

Personally I don't think this work should progress until we have line of
sight to a system that can actually do that.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 21 Feb 2018 20:12:48 -0800

> a packet to any IPv6 address in the domain.
The complete mapping system is not required to be stored in a single
device it is sharded. So if a single device hold 10M entries, then 100
devices are required with some multiplier needed for redundancy and
load. The numbers are not out of line with numbers of routers that are
deployed in large provider networks today. However, scaling into the
future especially with vast numbers of IoT devices, like the 1T
devices projection, will require more work (but even without this work
on scaling is still needed).

> sight to a system that can actually do that.

I would think that a major part of the work is to implement a mapping
system and identifier/locator protocol and to demonstate the scaling
properties. This is work currently in progress.

Tom

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Feb 2018 20:12:57 -0800

The Internet works today with billions of nodes connected. Why is that? Because not all of them are in single routing hardware. I realize aggregation allows for billions of individual addresses, but let’s compare this to DNS where an entry equals an individual address.

Maybe “mapping entries globally” does not equal “mapping entries in a given table”.

Dino

> On Feb 21, 2018, at 7:38 PM, Lorenzo Colitti <[email-masked]> wrote:
> 
> I have a fundamental problem with the assertion "should be able to scale to 1B mapping entries" given that a) current routing hardware capabilities are three orders of magnitude away from that, and b) anyone on the Internet can mount a state exhaustion attack on the mapping system simply by originating a packet to any IPv6 address in the domain.
> 
> Personally I don't think this work should progress until we have line of sight to a system that can actually do that.

---

From: AshwoodsmithPeter <[email-masked]>
Date: Thu, 22 Feb 2018 15:10:18 +0000

Edge devices only store FIB/Mapping entries of things they are talking to, that’s a very tiny fraction of the 1B entries..

Peter

From: 5gangip [mailto:[email-masked]] On Behalf Of Lorenzo Colitti
Sent: Wednesday, February 21, 2018 10:38 PM
To: Tom Herbert <[email-masked]>
Cc: [email-masked]; [email-masked]; 5GANGIP <[email-masked]>; Mikael Abrahamsson <[email-masked]>
Subject: Re: [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt

On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Tom Herbert <[email-masked]>
Date: Thu, 22 Feb 2018 11:53:13 -0800

On Feb 21, 2018 10:38 PM, "Lorenzo Colitti" <[email-masked]> wrote:

Lorenzo,

The intent of this draft is to articulate a problem that may be worth
working on. It's not to specify the solution, although I think it makes
sense to at least suggest some possible paths for a solution to establish
that the problem is solvable. Also, there is not necessarily just one
possible solution. The draft mentions possibly of hybrid assignment of
addresses for different privacy requirements, and how NAT is an existing
technique that  can provide strong privacy in addressing (I hope there is a
better solution that does not rely on NAT).

Tom