Subject: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07

From: DY Kim <[email-masked]>
Date: Sun, 6 Aug 2017 16:44:41 +0900

Hi authors,

I had some questions on Sec. Security Considerations of the document. It is said:

	The mechanics of IPv6 privacy extensions RFC4941 is
   	compatible with assignment of an Unique IPv6 Prefix per Host.

In the case of unique prefixes per host, the privacy of interest is in regard to the host prefix, not the IID. Privacy of a host would be compromised by use of its prefix, not of its IID anymore. That is, the privacy extension mechanisms proposed in rfc4291 or elsewhere in similar ways would become pointless for host prefixes.

How would you access this situation?

An alternative might be you apply a privacy extension mechanism to the host prefixes. However, the pool of the available prefixes would significantly be reduced from 2**64 for IID down to:

	o 2**16 if the controlled domain is a usual /48 site
	o 2**32, e.g., if the domain is a /32 network somewhere upstream in an ISP

Aren’t these numbers too small compared with 2**64 in order to benefit from any such privacy mechanisms?

---
DY

---

From: "Brzozowski, John" <[email-masked]>
Date: Mon, 7 Aug 2017 12:02:45 +0000

The approach documented in the draft complies and is compatible with current implementations and specifications as it pertains to privacy addressing.  If an operator of such a deployment also wishes to alter or randomize how prefixes (upper 64 bits) are provisioned and transmitted nothing changes, our ability to support privacy addressing is unchanged.

John
+1-484-962-0060

-----Original Message-----
From: DY Kim <[email-masked]>
Date: Sunday, August 6, 2017 at 03:44
To: John Brzozowski <[email-masked]>, Gunter Van de Velde <[email-masked]>
Cc: v6ops <[email-masked]>
Subject: privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07

    Hi authors,

    

    

    ---
    DY

---

From: DY Kim <[email-masked]>
Date: Mon, 7 Aug 2017 21:38:42 +0900

So, you mean randomizing, e.g., IID in the case (wherein each host has a unique /64 prefix) still helps privacy of the host?

Well,…

As soon as I figure out that the site is implementing Unique IPv6 Prefix per Host (there could be many rather easy way to figure that out, I’d presume), I would rather chase the /64 prefixes rather than the whole /128 addresses, in order to chase a specific host and so compromise its privacy.

---
DY

> On 7 Aug 2017, at 21:02, Brzozowski, John <[email-masked]> wrote:
> 
> our ability to support privacy addressing is unchanged.

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Aug 2017 15:13:05 +0200

I see the need of this document more for servers or devices that may have multiple VMs than “individual” PCs where privacy is an issue. It may happen, of course, but even if you have a /64 in a single laptop, the privacy issues are actually “lower” than if you have a single /128 address.

I think many sites will have a mix of “regular” SLAAC/DHCPv6 usage with one address per host, and one /64 per host, so not sure how you will be able to identify that. How you know if several /128 from the same /64 are in the same host running many VMs or they are actually different hosts?

Regards,
Jordi

-----Mensaje original-----
De: v6ops <[email-masked]> en nombre de DY Kim <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 7 de agosto de 2017, 14:39
Para: "Brzozowski, John" <[email-masked]>
CC: v6ops list <[email-masked]>, "[email-masked]" <[email-masked]>
Asunto: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07

    Well,…

    ---
    DY

    

    > our ability to support privacy addressing is unchanged.
    
    _______________________________________________
    v6ops mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/v6ops

**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: David Lamparter <[email-masked]>
Date: Mon, 7 Aug 2017 15:51:58 +0200

On Mon, Aug 07, 2017 at 09:38:42PM +0900, DY Kim wrote:
> So, you mean randomizing, e.g., IID in the case (wherein each host has
> a unique /64 prefix) still helps privacy of the host?
> 
> Well,…
> 
> As soon as I figure out that the site is implementing Unique IPv6
> Prefix per Host (there could be many rather easy way to figure that
> out, I’d presume), I would rather chase the /64 prefixes rather than
> the whole /128 addresses, in order to chase a specific host and so
> compromise its privacy.

I had a hacked-up implementation of this draft where the router actually
implements a lifetime for the entire /64 assigned to the host.  After a
configurable amount of time, it would advertise a different /64 to the
client (while keeping the old one around for some period of overlap,
with valid-lft but not preferred-lft.)

This has the downside of the router "controlling" client privacy, but
then again if you're the router you can always leak client's L2
addresses.  It also has the upside of the router "forcing" client
privacy even on clients that don't care for privacy addrs ;)

This is not explicitly suggested by the draft, it just seemed the
obvious approach to me.  You need to somehow track and expire client
prefixes anyway.

Cheers,

-David

P.S.: I'm currently hacking on FRR's RA codebase anyway, I may or may
not find time to resurrect the old hack, so there may or may not be an
additional implementation.  No promises ;)

---

From: Simon Hobson <[email-masked]>
Date: Mon, 7 Aug 2017 15:39:24 +0100

> privacy even on clients that don't care for privacy addrs ;)

But, doesn't this then preclude the client keeping any persistent connections open ? I'd be "very annoyed" if (for example) I found all my SSH terminal sessions suddenly closed due to having an address change forced on my machine.

---

From: David Lamparter <[email-masked]>
Date: Mon, 7 Aug 2017 17:03:36 +0200

On Mon, Aug 07, 2017 at 03:39:24PM +0100, Simon Hobson wrote:
> But, doesn't this then preclude the client keeping any persistent
> connections open ? I'd be "very annoyed" if (for example) I found all
> my SSH terminal sessions suddenly closed due to having an address
> change forced on my machine.

Yes it does.  It's really only appropriate for use cases where you have
some reasonable value that you can set a client prefix's valid-lft to,
e.g. 24h for setups where clients go away overnight.  Coincidentally,
the hack also expired a client's prefix if the client's linklocal
address was unreachable for more than a configurable (lower) time, so
that it wouldn't reassign the same prefix if the client comes back.

All of this is really from the viewpoint of public / venue / ephemeral
networks.

-David

---

From: DY Kim <[email-masked]>
Date: Tue, 8 Aug 2017 00:43:59 +0900

inline..

---
DY

> On 7 Aug 2017, at 22:13, JORDI PALET MARTINEZ <[email-masked]> wrote:
> 
> I think many sites will have a mix of “regular” SLAAC/DHCPv6 usage with one address per host, and one /64 per host,

Can there be a mix? Really? Does the doc imply or explicitly state a mixed mode?

> so not sure how you will be able to identify that. How you know if several /128 from the same /64 are in the same host running many VMs or they are actually different hosts?

I’d (hack and) open my connection for a /64 prefix and absorb any addresses under that prefix. I’d watch there are only single or only very few addresses for that prefix. It/they may change over time, perhaps, due to regular IID randomization, but still I could figure, with high success chance, that the site should be implementing this doc’s scheme. If the site should be a ‘regular’ site, there could be a bunch of addresses under the prefix, each further being randomized regularly, producing a big bunch of addresses.

Or some other hacking techniques… there should be lots of smart hackers...

---

From: DY Kim <[email-masked]>
Date: Tue, 8 Aug 2017 00:50:06 +0900

That’s possible. But, assuming you’re on a ‘normal’ site of /48 prefix, your freedom of obfuscation for the /64 prefixes is 2^16 which may not be big enough for the purpose.

On the other hand, what I’d be more concerned would be the usefulness of the IID randomization. I’m afraid it loses its usefulness for protection of the host privacy...

---
DY

> On 7 Aug 2017, at 22:51, David Lamparter <[email-masked]> wrote:
> 
> After a
> client

---

From: DY Kim <[email-masked]>
Date: Tue, 8 Aug 2017 00:51:22 +0900

+1

---
DY

> On 7 Aug 2017, at 23:39, Simon Hobson <[email-masked]> wrote:
>

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 07 Aug 2017 18:09:20 +0200

Just in case what I said was misunderstood … I’m not saying using the “same” /64 for the mixed mode. For example, you have a /48 and use one /56 out of it for a datacenter with servers that use one /64 each one (as they have many VMs each host).

In my opinion, privacy is a matter of “persons”, not machines (so if the unique-ipv6-prefix-per-host is used for servers, devices, etc., no people “browsing” there is not a privacy issue). Privacy is broken today not just because detecting addresses, but many other “signals”, “footprints” and “hints” that apps, browsers, etc., see for example https://panopticlick.eff.org/

Regards,
Jordi

-----Mensaje original-----
De: DY Kim <[email-masked]>
Responder a: <[email-masked]>
Fecha: lunes, 7 de agosto de 2017, 17:44
Para: <[email-masked]>
CC: v6ops list <[email-masked]>
Asunto: Re: [v6ops] privacy: draft-ietf-v6ops-unique-ipv6-prefix-per-host-07

    inline..
    
    ---
    DY