agree...of course... just we need to start adding security +cost+ considerations... to drafts > On Tue, Jul 3, 2018 at 8:19 AM, Jon Crowcroft > <jon.crowcr...@cl.cam.ac.uk> wrote: > > 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 > > > > Yep, we also know there is a lot of effort being done to extract > information from cipher text like apply machine learning to the data. > As compute and data acquisition techniques advance, attacks on the > Internet only get more sophisticated. Work will always be needed to > mitigate new attacks and that will have cost. It's a never ending > problem, but it's worth it to continually try to solve IMHO. > > Tom > > > > On Tue, Jul 3, 2018 at 5:14 PM, Tom Herbert <t...@quantonium.net> wrote: > >> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft > >> <jon.crowcr...@cl.cam.ac.uk> 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 <nordm...@acm.org> > 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: internet-dra...@ietf.org > >>>> To: Erik Nordmark <nordm...@sonic.net> > >>>> > >>>> > >>>> 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 > >>>> 5gan...@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/5gangip > >>> > >>> _______________________________________________ > >>> 5gangip mailing list > >>> 5gan...@ietf.org > >>> https://www.ietf.org/mailman/listinfo/5gangip > >> > >> _______________________________________________ > >> 5gangip mailing list > >> 5gan...@ietf.org > >> https://www.ietf.org/mailman/listinfo/5gangip >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
