beware of sidechannel attacks - eg. a sequence of efficient routes can determine a sequence of locations just from latency/rtt estimation (observe outbound data and likely return path ack packets) - you want privacy, you're gonna pay
On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert <[email protected]> wrote: > On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft > <[email protected]> wrote: >> what we need is compact onion routing - maybe we could call it garlic >> routing. >> >> in all seriousness, if people are worried about privacy with regards >> network operators, or state actors co-ercing network operators, at >> this level, that is what you want. otherwise forget about efficient >> mobile routing - the fact is that the signature of the set of >> locations you visit is enough to re-identify a node pretty quickly - >> its been done (see wetherall's work on this a few years back on simply >> looking at sequences of wifi AP associations, without bothing with end >> system mac addr, to uniquely matc individual (indeed, find their home) >> - you have to get the threat model appropriately...and proportioately > > Jon, > > The threat is not limited to coming from network operators, it is > basically from the whole Internet. IP addresses must be sent as clear > text, and when they encode personally identifiable information then > that can be used by third parties to compromise privacy. In mobile > addresses, the threat is both comprising identity and location of the > user. Identity can be compromised when the same address (or device > specific prefix in case of RFC4941 addresses) is reused for different > flows, location is compromised when an address encodes a locator that > can be used to determine specific location. There are publicized > examples of third parties using IP addresses to expose identity and > location (e.g. > https://theintercept.com/2018/03/26/facebook-data-ice-immigration/). > > In order to provide privacy in addressing, IP addresses need to be > purged of PII. This likely entails minimizing aggregation and a high > frequency of address change in a host. On the surface, this does seem > to be in conflict with "efficient mobile routing" as you mentioned, > however I don't believe that efficient routing is an acceptable trade > off for not providing adequate privacy to users. Alternatives that > achieve both goals should be investigated. > draft-herbert-ipv6-prefix-address-privacy-00 suggests "hidden > aggregation" as one possibility. > > Tom > >> >> On Mon, Jul 2, 2018 at 11:42 PM, Erik Nordmark <[email protected]> wrote: >>> >>> This is a rough draft, but hopefully it can stimulate more discussion around >>> privacy considerations. >>> >>> -------- Forwarded Message -------- >>> Subject: New Version Notification for draft-nordmark-id-loc-privacy-00.txt >>> Date: Mon, 02 Jul 2018 15:34:11 -0700 >>> From: [email protected] >>> To: Erik Nordmark <[email protected]> >>> >>> >>> A new version of I-D, draft-nordmark-id-loc-privacy-00.txt >>> has been successfully submitted by Erik Nordmark and posted to the >>> IETF repository. >>> >>> Name: draft-nordmark-id-loc-privacy >>> Revision: 00 >>> Title: Privacy issues in ID/locator separation systems >>> Document date: 2018-07-02 >>> Group: Individual Submission >>> Pages: 6 >>> URL: >>> https://www.ietf.org/internet-drafts/draft-nordmark-id-loc-privacy-00.txt >>> Status: https://datatracker.ietf.org/doc/draft-nordmark-id-loc-privacy/ >>> Htmlized: https://tools.ietf.org/html/draft-nordmark-id-loc-privacy-00 >>> Htmlized: >>> https://datatracker.ietf.org/doc/html/draft-nordmark-id-loc-privacy >>> >>> >>> Abstract: >>> There exists several protocols and proposals for identifier/locator >>> split which have some form of control plane by which participating >>> nodes can use to share their current id to locator information with >>> their peers. This document explores some of the privacy >>> considerations for such a system. >>> >>> >>> >>> >>> 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 >>> >>> _______________________________________________ >>> 5gangip mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/5gangip >> >> _______________________________________________ >> 5gangip mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/5gangip > > _______________________________________________ > 5gangip mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/5gangip _______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
