Re: [lisp] [5gangip] Fwd: New Version Notification for draft-nordmark-id-loc-privacy-00.txt

Tom Herbert <tom@quantonium.net> Tue, 03 July 2018 15:34 UTC

Return-Path: <tom@quantonium.net>
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 C1C26130EA5 for <lisp@ietfa.amsl.com>; Tue, 3 Jul 2018 08:34:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=quantonium-net.20150623.gappssmtp.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 HA8lA9g4R3Yd for <lisp@ietfa.amsl.com>; Tue, 3 Jul 2018 08:33:58 -0700 (PDT)
Received: from mail-wr0-x22a.google.com (mail-wr0-x22a.google.com [IPv6:2a00:1450:400c:c0c::22a]) (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 81147130E09 for <lisp@ietf.org>; Tue, 3 Jul 2018 08:33:58 -0700 (PDT)
Received: by mail-wr0-x22a.google.com with SMTP id u7-v6so2412351wrn.12 for <lisp@ietf.org>; Tue, 03 Jul 2018 08:33:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xeMgB5yMuPi1Cjv1lu5FgXYHouIpe+QoOwAhrLzTXXM=; b=WFS8IwWbf3Rno8hGvaD7OiZoer8dsGeI7HCWhCDAKLZsel0kpZM3+Q8w+Mstf3TL1O EhO92gJ6iaKHqNHMqTYCkTtVhz9PQG0jriVefuIS3AiU4j6mxXH5uie5ckaKb07n9nBN DATEO6SDWHKFs/rtkbRNhQFhjPAso6rTMZE6yt0sz/hqkL95r9JHADhk/tDTNqUM7JIz h2P6btbgB/zUv9VDUfQQsysfbVUXWhIWjMMQMNaiEZ7Iw1ax8jQcO1SIhv0VbNPhUomr RCxr4pLaXfmZXpACDwx2GHX9ig3mCW+lLVnIXk0Dw9pL8lu6NjWE/Ise1lacA9AErb+x ON4w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xeMgB5yMuPi1Cjv1lu5FgXYHouIpe+QoOwAhrLzTXXM=; b=a8leWO1cpBHZbc+Lgk4VlJzltbfK+Jrrwv0QX1ZxXpvTW3fnzSQGdUq6ZLMshj/WJD dYv5Yc4rXA53vr8aNQ9USBumaGGbVEz12BQw97po/nmD/d+XeY5KwsesPBeNTNK6b2A7 WpDANqdtxEh1rvnOCjjVOrJn7HEJfQJGV/II3zcG3UQGK3REbtvQiJj8OywE9DiT/wbb iDch4Fwj3fOBgJY8tOuA9TqGwqgfXtQih0NPew/srrXFHJuU8qCv1W7Qs4tNYcVywDvi umfnhXGe1FJ519tI8aHuKghcbWPMf+jM7KfUwJN2vIRknKddNn7gB89ePpU+OR7SJ9Xv aFmg==
X-Gm-Message-State: APt69E33HzMxc2WK/CeBxATtGSl6ka8q7tsKLhSdsmbWxsnheWqSFWQe A10mr5v01YdnLseqVunKwS5JqgfkSBhufxggdL/kYQ==
X-Google-Smtp-Source: AAOMgpe6WgxRN8O9Jk9HFVTjCff6Q0t+gkXwgJ+PdIfxmQbpdwqVVxi2OhpEtVergdjPpGMPDnnhPEF9/gZCbAXQpIU=
X-Received: by 2002:adf:a056:: with SMTP id l22-v6mr2123756wrl.153.1530632036864; Tue, 03 Jul 2018 08:33:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:adf:fa86:0:0:0:0:0 with HTTP; Tue, 3 Jul 2018 08:33:56 -0700 (PDT)
In-Reply-To: <CAEeTejL-1ZfQerWYOaVXN0M=TB-mSHGTY6YVd91e3SwVbiogCA@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>
From: Tom Herbert <tom@quantonium.net>
Date: Tue, 3 Jul 2018 08:33:56 -0700
Message-ID: <CAPDqMeoEDbM0FbOHAmWCNU8zmsRvk7cxYCv39OLSrXytdb-BfA@mail.gmail.com>
To: Jon Crowcroft <jon.crowcroft@cl.cam.ac.uk>
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/TfTze_kU6OYHkUflsYV6GmTTT5k>
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:34:03 -0000

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