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:19 UTC

Return-Path: <crowcroft@gmail.com>
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 84028130E68; Tue, 3 Jul 2018 08:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.4
X-Spam-Level:
X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 7JZUDAxuIXlC; Tue, 3 Jul 2018 08:19:37 -0700 (PDT)
Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::231]) (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 334D1130DCC; Tue, 3 Jul 2018 08:19:37 -0700 (PDT)
Received: by mail-wr0-x231.google.com with SMTP id t6-v6so2381301wrn.7; Tue, 03 Jul 2018 08:19:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=43g7kDFsMCls9rBLZ5vqTlZWAQfaXqhDUHs83lCoHTU=; b=b6yB/Gc20FlKVGgFvIOEGVMyQL30ik+3NI5nOERZ2FK9R5oKEU4j55HrZqemsbfUVf 9QJzTcrkrT9z5b/gS1/CnSqPQpBDT2I+VqNRR7mCNYDpjwdqJ08ujx9JZa7KTCRM5uFo 1Rb7Qvd4hhJ8m+6HC3eBgVZj+QKaU5ZAujQLpeNGGiRHIOdVJIERvT09BThmzEZdrkEO KEMBp/LWF7/rO7xGl5iCrAO0CmKmwMg+AO2QkjSiCQmFsNACgKe9JehZDAqkor19Y3jZ ebv468RbUIwBQqmIib4U4QTihK7oLI3BUUlO/B/ovd9ClP7WkDeXgPlT4f0ysE+5zHGz dmog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=43g7kDFsMCls9rBLZ5vqTlZWAQfaXqhDUHs83lCoHTU=; b=CagzZ1WAvqZVQL2MWwx6ue5wXB409GNT6CWrCctRSrXDurgCzXHk4PXkHws6rh0CJz Tr2ICDDY/U/7Qv8A98JLGDjl67UhdQq4lduCf2armeQMQrpuI+RwSkVBx4vO07VUkhm/ Omo8wRfr+HtQRHhjcHsTSZh0mY23IOgeYd5DPfaEIvWpBYeFRUv7/6Uk6eQTDf6NZMVN I45l0LPn2507fKHbjcqYxx2qS8fai6PNEyCTL38O0Qbg58piRlJe9HLxEWLIItcb1rFH /111jnngexX36Dx4qucgHcNkQd3tCuiFRRlEA7bYeqaCRF57ZtOE5i+1Bv1sYsJ0wUNE EsUw==
X-Gm-Message-State: APt69E29lC36m2Z8HPkOxZPXb4JoJt5+Lwy5s2VTIvYSWWAX/QIzdQGo prNI3ZE1TQsJNOdkvLGWk2UmtVrCYXD9Hu9HMqE=
X-Google-Smtp-Source: AAOMgpeML0MCiWZTQBxK7Zq4zLqD+z2ev2eWXZxxow7Pb63TICRyKZPjBP60XRB7IPY3Yjeb31Ky1oIyIlkyInAI+4o=
X-Received: by 2002:adf:e590:: with SMTP id l16-v6mr21609173wrm.190.1530631175595; Tue, 03 Jul 2018 08:19:35 -0700 (PDT)
MIME-Version: 1.0
Sender: crowcroft@gmail.com
Received: by 2002:a1c:ef11:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:19:34 -0700 (PDT)
In-Reply-To: <CAPDqMepRAro+xHbniXFarZ20Ac8PYJGTKBj6619NUsXVgPvhTg@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>
From: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
Date: Tue, 3 Jul 2018 17:19:34 +0200
X-Google-Sender-Auth: GB7Gi7DJj-LXKQShAp918tp7b_s
Message-ID: <CAEeTejL-1ZfQerWYOaVXN0M=TB-mSHGTY6YVd91e3SwVbiogCA@mail.gmail.com>
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>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/lisp/9OzUSal20cJWvHtCXoGw-fBbHuI>
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:19:40 -0000

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 <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