Re: [lisp] [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: lisp@ietfa.amsl.com
Delivered-To: lisp@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/lisp/NNvC_p7B4kjAe39Z8vvIqWjc3G4>
Subject: Re: [lisp] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt
X-BeenThere: lisp@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: List for the discussion of the Locator/ID Separation Protocol <lisp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lisp>, <mailto:lisp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lisp/>
List-Post: <mailto:lisp@ietf.org>
List-Help: <mailto:lisp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lisp>, <mailto:lisp-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
>