Re: [Pidloc] PIdLoc Webex

Tom Herbert <tom@quantonium.net> Mon, 10 December 2018 15:39 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: pidloc@ietfa.amsl.com
Delivered-To: pidloc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F09E3130F2D for <pidloc@ietfa.amsl.com>; Mon, 10 Dec 2018 07:39:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.358
X-Spam-Level:
X-Spam-Status: No, score=-3.358 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham 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 1U3GfGVbDvV4 for <pidloc@ietfa.amsl.com>; Mon, 10 Dec 2018 07:39:40 -0800 (PST)
Received: from mail-it1-x129.google.com (mail-it1-x129.google.com [IPv6:2607:f8b0:4864:20::129]) (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 D79CE130F1F for <pidloc@ietf.org>; Mon, 10 Dec 2018 07:39:39 -0800 (PST)
Received: by mail-it1-x129.google.com with SMTP id c9so18805738itj.1 for <pidloc@ietf.org>; Mon, 10 Dec 2018 07:39:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=K7Ror57FUbfFFXQRR6+XoskidTTfFT4UM90XYA8IkMg=; b=T9Snd7gEuxJonDMoOCzePSuxIfnBCAMbtLwie7UHVplSnYwfn+/WlszAY49sQpJzxx OSPFkijJfIbi8CEQA13vt339wqtlHwMYOxOjAIEQckYr8NsevvN552nvLD9r/0utzzbt Kf3BCTwlKqfHT9jamm/yw6pKZjvVnszrXWne7cZrcIcjcgAf85/nv6UF5Kebudjs8NJX /3GRWTXmf6bFqFbt8Q5aF5uENnZ2AqQ7hvx0bLTNfw7e3AvOyrtKUmWe/BhfvYZo12s/ cAbe/MyJNu5qTjdHCm8fyy38K9m50dFN0ayxJf4lBehSqPz2TeWnY2rHRedqKk38ABre Ff4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=K7Ror57FUbfFFXQRR6+XoskidTTfFT4UM90XYA8IkMg=; b=iUPxKxOgDfoFU11+qhqTinvQhVCQxaytDoFBbNxNt5th9jD78SUTJ49ikYfAeC12Al mVpxExAlnWRia/m6y5kAZLWJaF+gIREVnuK1mWzWP7a6xsjtaNB/Ah4b5p+XlXZ80e6Y pmVFybQ24bzPFcMCAOq9jw+1kQfePCPZp8G7XV1XwGHG1gmyoumPkWBE7j8JKK5nfLg+ yw3mxLNF++O9AlgBpcgCo/3+gtgI4z3/Rw40HebrnBYFU19J/N2ZL3AfJZpQYlpM2DWY hCl0G2y0dEwssRIYd2BwcKAUwH5RYiCrDTAPHZssEQ7PxgJ9msD4jgWbj1KLM3scLaRe gECg==
X-Gm-Message-State: AA+aEWbHpDG676hkvbGnEOFVha0LGpKwsclIi6BNBlHWDyrJQ7YPm7IM 2T1NwhD92eVT0csOoHTPTDjeGxTPr8jCtCBnLPASqw==
X-Google-Smtp-Source: AFSGD/XLOuhVSGOzoG6ASsA/TWoJZz8lQ+Z40XxMTjTu03Hv2Nay2HPmbTJY2J4BVMRgxtbx7E87Zd06yNgth7TJcHs=
X-Received: by 2002:a24:b64a:: with SMTP id d10mr11523866itj.149.1544456378590; Mon, 10 Dec 2018 07:39:38 -0800 (PST)
MIME-Version: 1.0
References: <FRAPR01MB0801A22EEC0D55414EFFEC2ED1D00@FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE> <FRAPR01MB0801CDFD28647B7A02D700D2D1D00@FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE> <FRAPR01MB0801A452C8111F16940D4D65D1D10@FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE> <FRAPR01MB080121A9C90A6F78BBD7E4B7D1AF0@FRAPR01MB0801.DEUPRD01.PROD.OUTLOOK.DE> <95C0EB99-9A1F-4650-B764-2CC923B879A2@gmail.com> <CAPDqMeoUPaCiAF_7FeiBko0g=ofH6UcCtMAFn+1yLrPWJQfGWw@mail.gmail.com> <12D7EB58-278A-4ED4-83CE-B72F9206F054@gmail.com> <CAPDqMeqBL2O-g3-u5y2OZvsLJFG-qe_a3dc5qXSR8GaMAFsKXg@mail.gmail.com> <5CDE5968-FF04-4F8D-96F6-5CE51445B3CC@gmail.com> <CAPDqMeoRBD0qFFgnwpZghaNz7aHJA_mXfc16ainwjDhXQMQ+ew@mail.gmail.com> <3BB55FFA-D711-43AB-A788-AD7AA300D7DF@gmail.com> <CAPDqMermOi_avv24f9=mawUJ3HAvLjqv3CbhziOL5pWCLbtDdA@mail.gmail.com> <E3A4FF53-AA56-404A-9E3B-FD88E84674C5@gmail.com> <CAPDqMepM0PmuHgXxqGP41kBCRXHfO7iDD_QkvzMiFPD9wyEHLQ@mail.gmail.com> <9A5612A3-0C9A-4A43-84F3-C5CEC3FF0CCA@gmail.com> <CAPDqMepPQ_0NAK7ip6vX7x-Ge9k3DWEViNg=37WQPDS5eTvFCg@mail.gmail.com> <490EDBBB-CD3D-4552-BE93-38651B913D13@gmail.com>
In-Reply-To: <490EDBBB-CD3D-4552-BE93-38651B913D13@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Mon, 10 Dec 2018 07:39:26 -0800
Message-ID: <CAPDqMeoFWssJKUj4grDLfeo7Hbdi+sMWxiWoytP_ZxBXsLf4ew@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Dirk.von-Hugo@telekom.de, RJ Atkinson <rja.lists@gmail.com>, Saleem Bhatti <saleem@st-andrews.ac.uk>, Shunsuke Homma <homma.shunsuke@lab.ntt.co.jp>, Behcet Sarikaya <sarikaya@ieee.org>, Luigi Iannone <ggx@gigix.net>, erik@zededa.com, pidloc@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/GKawA8EsjZ9OGzKdZB3QRYWLSI8>
Subject: Re: [Pidloc] PIdLoc Webex
X-BeenThere: pidloc@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <pidloc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pidloc>, <mailto:pidloc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pidloc/>
List-Post: <mailto:pidloc@ietf.org>
List-Help: <mailto:pidloc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pidloc>, <mailto:pidloc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Dec 2018 15:39:42 -0000

On Fri, Dec 7, 2018 at 11:46 AM Dino Farinacci <farinacci@gmail.com> wrote:
>
> Sorry, looking at the entire network, and how it works, scales, and what the cost of privacy is critical to evaluate. Just looking at it from the app end-systesm isn't looking at the details to *really* make the entire system work.
>
Dino,

There's already very large systems that *really* work. Both mobile
providers and cloud providers have been using identifier/locator
protocols and mapping systems for a long time. It is obvious that
access to the control plane needs to be tightly secured and providers
do that. If, for instance, someone were able to snoop call messages in
3GPP then all privacy and security break down (there's little choice
but to entrust providers with protecting privacy). A material problem
in these systems that isn't solved by a secure control plane is that
PII can deducible from IP addresses assigned by such systems that are
exposed to the outside world. IMO, this is a specific and current
problem and is worth discussion on this list.

Tom

> Dino
>
> > On Dec 7, 2018, at 11:31 AM, Tom Herbert <tom@quantonium.net> wrote:
> >
> > On Fri, Dec 7, 2018 at 11:08 AM Dino Farinacci <farinacci@gmail.com> wrote:
> >>
> >>> Yes, the network should assign ephemeral addresses. Scaling this so
> >>> that hosts can use a different address per connection is the problem
> >>> that ensues.
> >>
> >> For the outer (or only header), you cannot get assigned ephemeral addresses. They need to be provider-assigned addresses so routing deeper in the network can aggregate such addresses into coarser prefixes.
> >>
> >> And note ISPs want to use uRPF so another reason for provider-assigned addresses. The best way to solve the *entire* problem is to tunnel with encryption from a point inside the ISP. Then the outer addresses are coarsified and the inner addresses are obfuscated.
> >>
> >> You could solve some of the problem with ILA but you need to keep translating the packet as it goes to the destination. And that will be hard to debug since it breaks traceroute.
> >>
> >
> > You are convoluting the behavior of internal network operations with
> > the externally visible behavior. Think of it this way, we have end
> > hosts and we have Internet servers. The desired property wrt privacy
> > is that any host can use an untrackable source address per connection
> > to talk to any Internet servers. Servers on the Internet should not be
> > able to draw any correlation between any two flows, nor should they be
> > able to deduce geographic location with any accuracy. End hosts and
> > server only see these assigned addresses. They don't know about
> > mapping systems, underlays, encapsulation, or what the addresses mean
> > other. All they know is that the addresses than they identify a
> > communicating node and are routable in IP packets over the Internet to
> > some service provider. It is up to the network provider to support
> > this using mechanisms that scale, but the details of that are not
> > relevant to privacy as long as the desired external behavior is met
> > and privacy is maintained.
> >
> > Tom
> >
> >> Dino
> >>
>