Re: [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt
Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk> Tue, 03 July 2018 15:36 UTC
Return-Path: <Jon.Crowcroft@cl.cam.ac.uk>
X-Original-To: 5gangip@ietfa.amsl.com
Delivered-To: 5gangip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B710130EBB; Tue, 3 Jul 2018 08:36:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZCYrHGkhZrH; Tue, 3 Jul 2018 08:36:48 -0700 (PDT)
Received: from mta2.cl.cam.ac.uk (mta2.cl.cam.ac.uk [IPv6:2001:630:212:200::25:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93358130F67; Tue, 3 Jul 2018 08:36:48 -0700 (PDT)
Received: from ely.cl.cam.ac.uk ([2001:630:212:238:230:48ff:fefe:c314]) by mta2.cl.cam.ac.uk with esmtp (Exim 4.86_2) (envelope-from <Jon.Crowcroft@cl.cam.ac.uk>) id 1faNME-0002QN-Lg; Tue, 03 Jul 2018 16:36:46 +0100
From: Jon Crowcroft <Jon.Crowcroft@cl.cam.ac.uk>
To: Tom Herbert <tom@quantonium.net>
cc: Erik Nordmark <nordmark@acm.org>, ila@ietf.org, "lisp@ietf.org list" <lisp@ietf.org>, dmm <dmm@ietf.org>, 5GANGIP <5gangip@ietf.org>
In-reply-to: <CAPDqMeoEDbM0FbOHAmWCNU8zmsRvk7cxYCv39OLSrXytdb-BfA@mail.gmail.com>
References: <153057085187.16368.17027473724315322445.idtracker@ietfa.amsl.com> <3c9865b6-5819-ab4c-7d0d-87d36949591a@acm.org> <CAEeTejLoOU2aXhD+SxsHuJ2Xr14aCH0wzj6_PBcQXLxRYQfmzQ@mail.gmail.com> <CAPDqMepRAro+xHbniXFarZ20Ac8PYJGTKBj6619NUsXVgPvhTg@mail.gmail.com> <CAEeTejL-1ZfQerWYOaVXN0M=TB-mSHGTY6YVd91e3SwVbiogCA@mail.gmail.com> <CAPDqMeoEDbM0FbOHAmWCNU8zmsRvk7cxYCv39OLSrXytdb-BfA@mail.gmail.com>
Comments: In-reply-to Tom Herbert <tom@quantonium.net> message dated "Tue, 03 Jul 2018 08:33:56 -0700."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20756.1530632206.1@ely.cl.cam.ac.uk>
Date: Tue, 03 Jul 2018 16:36:46 +0100
Message-Id: <E1faNME-0002QN-Lg@mta2.cl.cam.ac.uk>
Archived-At: <https://mailarchive.ietf.org/arch/msg/5gangip/U_AfSyYnEuS7-M7P9KskgpIjGqQ>
Subject: Re: [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt
X-BeenThere: 5gangip@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of implications of the upcoming 5th Generation \(fixed and\) Mobile communication systems on IP protocols." <5gangip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/5gangip>, <mailto:5gangip-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/5gangip/>
List-Post: <mailto:5gangip@ietf.org>
List-Help: <mailto:5gangip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/5gangip>, <mailto:5gangip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jul 2018 15:36:55 -0000
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.crowcroft@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 <tom@quantonium.net> wrote: > >> On Mon, Jul 2, 2018 at 10:01 PM, Jon Crowcroft > >> <jon.crowcroft@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 <nordmark@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-drafts@ietf.org > >>>> To: Erik Nordmark <nordmark@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 > >>>> 5gangip@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/5gangip > >>> > >>> _______________________________________________ > >>> 5gangip mailing list > >>> 5gangip@ietf.org > >>> https://www.ietf.org/mailman/listinfo/5gangip > >> > >> _______________________________________________ > >> 5gangip mailing list > >> 5gangip@ietf.org > >> https://www.ietf.org/mailman/listinfo/5gangip >
- [5gangip] Fwd: New Version Notification for draft… Erik Nordmark
- Re: [5gangip] Fwd: New Version Notification for d… Jon Crowcroft
- Re: [5gangip] Fwd: New Version Notification for d… Jon Crowcroft
- Re: [5gangip] Fwd: New Version Notification for d… Tom Herbert
- Re: [5gangip] Fwd: New Version Notification for d… Jon Crowcroft
- Re: [5gangip] [DMM] Fwd: New Version Notification… Behcet Sarikaya
- Re: [5gangip] Fwd: New Version Notification for d… Tom Herbert
- Re: [5gangip] Fwd: New Version Notification for d… Behcet Sarikaya
- Re: [5gangip] Fwd: New Version Notification for d… Dirk.von-Hugo