Subject: draft-ietf-6man-rfc4941bis: in favor of SHOULD do random IIDs that change on (re)attachment

From: Dave Plonka <[email-masked]>
Date: Mon, 25 Mar 2019 09:59:17 +0100

Hi folks,

Regarding Fernando's questions for feedback on:

(a) whether 4941bis should suggest (just) temporary random IIDs, that
are relatively short-lived, e.g., 1 day, that change on network
(re)attachment
or:
(b) both that method and alternatives (e.g., RFC7217), that might use
the same IID on reattachment

I would like to share one privacy-benefitting capability that leverages (a):

With typical short-lived, pseudorandom IIDs, we have a method to
estimate the number of simultaneously interfaces (roughly host
equivalents) having currently assigned temporary privacy addresses at
points in time.  This count is a lower-bound, limited by the point of
observation, i.e., whether or not those addresses are involved in
traffic that passes that point, e.g., a gateway or border router, or a
service, such as a web server.

Being able to count IPv6 interfaces/hosts by leveraging the
pseudorandom IID as a short-lived universally unique ID (in its
network prefix) allows us, then, to aggregate those hosts together
into covering prefixes that we can guarantee (based on empirical
measurement) the number of host interfaces that are present in an
anonymity set, for instance a traffic measurement associated with a
set of anonymous users' hosts.

The method is described here:
   "kIP: a Measured Approach to IPv6 Address Anonymization"
   short paper: https://arxiv.org/pdf/1707.03900.pdf

and was presented in MAPRG here:
   video: https://www.youtube.com/watch?v=qYtaKuzXaiM#t=59m55s
   slides: https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf

and recently at the CARIS2 workshop here:
   "Measured Approaches to IPv6 Address Anonymization and Identity Association"
   2-page extended abstract:
http://pages.cs.wisc.edu/~plonka/caris2/caris2-ipv6anon-draft.pdf

For this reason, I am personally in favor of 4941bis encouraging the
existing temporary privacy address mechanism, i.e., alternative (a).
It has useful properites that can help, for example, in complying with
GDPR while still reporting useful analytics (in aggregate, about an
anonymity set of IPv6 activity) and also in communicating about
traffic activities involving anonymous aggregates, i.e., without
reporting individual IP addresses but still knowing the size of the
anonymity that a give covering prefix/CIDR represents at a point in
time.

Dave

-- 
[email-masked]  http://www.cs.wisc.edu/~plonka/

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 12:04:32 +0100

Hello, Dave,

> the same IID on reattachment

Not sure I follow. I don't think there are any differences regarding the
properties of the addresses resulting from these two algorithms. You can
employ any of these algorithms and make them generate addresses upon the
same or different circumstances.

Thanks!

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

---

From: Dave Plonka <[email-masked]>
Date: Mon, 25 Mar 2019 12:15:29 +0100

HI Fernando - yes, I imagine it can't be followed from just what I've
said here. It is described in detail in the preso and short paper
links provided.

The counting technique (which can be used to guarantee a minimum
number of addresses in an anonymity set for privacy) relies on the
inference that a temporary privacy address is still bound to an
interface between observations of traffic from it.

If a privacy addressing mechanism intentionally reuses an IID that it
used previously (but not continually) on a given network, it breaks
the validity of this assumption (that the address must still be
assigned continually to an interface between two observations of its
use), and therefore causes an obstacle to counting the number of
simultaenous privacy addresses in use at a time, making it hard, or
even impossible, to guarantee the size of a resulting anonymity set
(of IPv6 hosts/interfaces using privacy addresses).

This is a distinct advantage to changing the privacy addresses' IIDs
on attach/reattach to a network.

Dave

--

---

From: Dave Plonka <[email-masked]>
Date: Mon, 25 Mar 2019 12:19:43 +0100

Tim Chown made the point quite well in this follow-on discussion here:

    https://www.youtube.com/watch?v=qYtaKuzXaiM#t=1h18m20s

--

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 13:17:43 +0100

> said here. It is described in detail in the preso and short paper

I will watch the videos/presos.

But anyway, my point is that both algorithms can be employed to generate
addresses that change as much as needed.

It's just that the ala-RFC7217 can be more easily tied to some events
such as a change of a MAC address.

Both algorithms are expected to / can be used to comply with the
requirements in
https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-02#section-5

The aforementioned requirements are meant to e.g. trigger when, at
least, you generate a new address. If there's any information leakage,
it's because there's a missing requirement in that set, or because the
algorithm is not complying with the requirements.

As noted above, the ala RFC7217 algorithm just makes it explicit some
changes -- e.g., by including the MAC address as a parameter of the hash
function, it's guaranteed that a change in the MAC address will lead to
a change in the temporary address. But of course you could achieve the
same with the simple randomization approach if yuo make sure you call
the PRNG again to generate a new temporary address upon generation of a
new randomized mac address.

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

---

From: Fernando Gont <[email-masked]>
Date: Mon, 25 Mar 2019 13:18:59 +0100

>     https://www.youtube.com/watch?v=qYtaKuzXaiM#t=1h18m20s

Please elaborate, so that others that may not go through the videos can
weigh in.

Thanks,

---

From: Tom Herbert <[email-masked]>
Date: Mon, 25 Mar 2019 15:26:24 +0100

> set of anonymous users' hosts.

Dave,

How is this affected if we start assigning end hosts multiple address (tens
of them to million of them and beyond)?

>    slides:
> https://www.ietf.org/proceedings/99/slides/slides-99-maprg-kip-a-measured-approach-to-ipv6-address-anonymization-03.pdf
>

That's a lot of information to parse. Is there an I-D describing this?

Tom

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

---

From: Ole Troan <[email-masked]>
Date: Mon, 25 Mar 2019 15:32:45 +0100

> On 25 Mar 2019, at 15:26, Tom Herbert <[email-masked]> wrote:
> 
> 
> How is this affected if we start assigning end hosts multiple address (tens of them to million of them and beyond)?

If you did, any sensible router implementation would consider it an attack on the ND cache. Which they probably would anyway for superfluous use of addresses on a link. TCAM entries is a relatively scarce resource. 

Ole

---

From: Dave Plonka <[email-masked]>
Date: Tue, 26 Mar 2019 10:55:19 +0100

Hi Tom,

Responses in-line, below:

> How is this affected if we start assigning end hosts multiple address (tens of them to million of them and beyond)?

Good question.

The technique is first based on counting simultaneously assigned IPv6
addresses that are at least occasionally used (as src/dst for
traffic), so it would count these additional addresses if they are
visible, e.g., in traffic or flow export, at the observation point.

Given that the IPv6 IID is an interface identifier by definition, I
believe this is consistent with saying that the method counts
simultaneously configured IPv6 interfaces based on these interface
identifiers.

If a host uses a pool of temporary privacy addresses simultaneously,
it will increase the number of active IIDs/interfaces counted beyond
the number of hosts, giving more opportunities to discover that a host
has an interface(s) with address(es) configured.

The kIP anonymization mechanism takes this into account, so it doesn't
dramatically overcount users or subscribers, by using those IIDs as an
merely an indication of when the host interfaces' Identity Association
(IA, or *covering prefix*) is assigned, and distills it down to just
that. So, if we believe that the IA, e.g., from an ISP to a
subscriber, is a /64, then we would count it as one subscriber. Of
course, in DHCPv6 we know that the IA can vary, and real-world
accounts show it is typically /64 but up to /56, e.g., in commercial
ISPs in the U.S.

(There is separate work about how to reverse-engineer a
user's/subscriber's Identity Association, e.g., by path divergence in
active traceroute-like measurements. See, for instance, Section 6
SUBNET DISCOVERY here "In the IP of the Beholder: Strategies for
Active IPv6 Topology Discovery":
https://arxiv.org/pdf/1805.11308.pdf)

The counting technique is valuable, I think, in and of itself, to
measure address utilization and estimate populations in networks or
prefixes.
(Something we can't do in IPv4 because of NAT.)

However, it is also powerful as the basis for an anonymity mechanism
when the counts are used to make aggregates because anonymization by
aggregation is only valuable if you can make some guarantees, or at
least have some confidence, about the number of members of the
resulting anonymity set amongst which one can not distinguish when
reporting some feature or characteristic that would otherwise cause
privacy concerns.

> That's a lot of information to parse. Is there an I-D describing this?
<snip>

Not yet, but I now have funding/support to develop it, so plan to
write an I-D on the kIP counting an anonymization mechanism (with just
the pertinent parts to implementation), probably targeted for as a
MAPRG draft.

It is really quite a short paper and presentation here though, for the
time being (wouldn't it take 20 mins to read a draft?):
https://arxiv.org/pdf/1707.03900.pdf
https://www.youtube.com/watch?v=qYtaKuzXaiM#t=59m55s

I believe these are important complements because they show the
results/effects of the counting, which would not be in the I-D
specifying the method's implementation.

Does that make sense?

Thanks,
Dave

--

---

From: Dave Plonka <[email-masked]>
Date: Tue, 26 Mar 2019 11:01:35 +0100

Hi Fernando,

> https://tools.ietf.org/html/draft-gont-6man-non-stable-iids-02#section-5

OK, thanks for the clarification.

> new randomized mac address.

Agreed. My goal was just to make clear that there are some advantages in
privacy by anonymization in aggregate if we encourage a change in address
on attachment/reattachment at a lower level.

I think this is non-obvious, so want to let the community know that when we
 produce anonymity sets by aggregation of IPv6 addresses to covering prefix,
where most are temporary privacy addresses, the counting is important so
that we can make some assurances about the resulting size of the anonymity
set.

Does that make sense?

Thanks,
Dave

--

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Mar 2019 13:48:13 +0100

Dave,

> on attachment/reattachment at a lower level.

I think that's irrespective of the attachment/reattachment, but rather
has to use with the frequency at which temporary addresses are generated.

Thanks,