Re: [Pidloc] PIdLoc Webex

Behcet Sarikaya <sarikaya2012@gmail.com> Tue, 11 December 2018 15:28 UTC

Return-Path: <sarikaya2012@gmail.com>
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 D449B12DF72 for <pidloc@ietfa.amsl.com>; Tue, 11 Dec 2018 07:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 68Cxv7HmrT-y for <pidloc@ietfa.amsl.com>; Tue, 11 Dec 2018 07:28:51 -0800 (PST)
Received: from mail-wm1-x32f.google.com (mail-wm1-x32f.google.com [IPv6:2a00:1450:4864:20::32f]) (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 CC2B1130DCD for <pidloc@ietf.org>; Tue, 11 Dec 2018 07:28:47 -0800 (PST)
Received: by mail-wm1-x32f.google.com with SMTP id f81so2683496wmd.4 for <pidloc@ietf.org>; Tue, 11 Dec 2018 07:28:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=y+pFnLuWDvJjDh5tRISYbtEl+LZhGPPiwVKeeIfHYNU=; b=bz6TL5Y8iBSVIB2oz8t4DZOtxJc+bBL7lTCHmqAvDAgQEEZoFZjWYzjgBsEaOgPvn2 ChiEjUxXkCPCjlCur/RgGYfUh6+/fcfNGvzNob5ngJtbb5I9drgzsQsBi+PhruWwqwAf +wXmu3OzQOh+h3bA5ifVneGIW3PbPL9UlQrpIGEXOeXXQh8PryNFFaAUf0qTsmMwq9PW vUiig5ET1eTkYEMrDzOjC5qTgh+Co0uytHNzf5ujFVUv1BtFQEjDgjrnM1MlNbPIvLh5 r2Pqw3w+pglCicqrZe4n3DFCYk4XhQfCli9tK2R67VioCcTzKUsMA/VFqp9IWlbbTJWc Fy9Q==
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:reply-to :from:date:message-id:subject:to:cc; bh=y+pFnLuWDvJjDh5tRISYbtEl+LZhGPPiwVKeeIfHYNU=; b=DH+xns6hxJN/Brf7seLnt/JIUQiPEWkgMztglEb8z0NecFCvLg5wW5u64dgj/tKe1y 5+UwEE4xoMcgrwqBswMgifBGRCW4mHtvugc67KXtgL76Ocu7Uuyc3l8S8AZY2be/Y4M+ n5apouAfpih6dAbH1BntSaSQZVqDMs+KTapGcVnrk2FeK1Qw+cFxnY8qeEp1cCY+BPUM nJWtkOZnKrcSGJq6UyDnSCUrBK0jRO89Bf6B50SoQKbmN7Wl1KAmdc7BYhBjEnfiOJPn eyp47yOLojUUS3qQ2cMddL8bof9n/QPm8Vs2Q3J7QkWKMqYn4bp1cFxZ9Ud/V3g57YJZ q7UA==
X-Gm-Message-State: AA+aEWYVB8e4B4wH1pZiyl0htDCtW86An4pH8pyktqdApF/4x/HzxjBu tZy2rcT9zggRiGXoWkyF8PrgC8TMzfXZofGhLTD0Yw==
X-Google-Smtp-Source: AFSGD/WUTZAl7lN4GHZpu8QTKhREijMsUdRUEdtqYhtB3LxWIqpH14y2jQsiYsEoGx/wUsnV43tfkZnCsAeg/NbmvOk=
X-Received: by 2002:a7b:c142:: with SMTP id z2mr2905127wmi.102.1544542126199; Tue, 11 Dec 2018 07:28:46 -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> <CAPDqMeoFWssJKUj4grDLfeo7Hbdi+sMWxiWoytP_ZxBXsLf4ew@mail.gmail.com> <664C3E70-748F-477A-BB7A-047B0CA803F7@gmail.com> <CAPDqMepJsHLjSmLXYEzwQQ=aSApUQXJmqaP7ku42fBb+5aUtEA@mail.gmail.com> <F204ED47-486F-4913-B2B0-8290AF3FE491@gmail.com>
In-Reply-To: <F204ED47-486F-4913-B2B0-8290AF3FE491@gmail.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Tue, 11 Dec 2018 09:28:34 -0600
Message-ID: <CAC8QAcex+gV8bKD3pzvcNmeHVzwE3JpuLa6Fmxkn=Kie6pdiQg@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: Tom Herbert <tom@quantonium.net>, 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>, Luigi Iannone <ggx@gigix.net>, erik@zededa.com, pidloc@ietf.org, "Bogineni, Kalyani" <Kalyani.Bogineni@verizonwireless.com>
Content-Type: multipart/alternative; boundary="000000000000c5da03057cc0bcb3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/xGzx09fD_a2KrdzLi-qSvbt1cEI>
X-Mailman-Approved-At: Tue, 11 Dec 2018 07:44:02 -0800
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: Tue, 11 Dec 2018 15:28:53 -0000

On Mon, Dec 10, 2018 at 11:51 AM Dino Farinacci <farinacci@gmail.com>; wrote:

> Me too.
>
>

That is one reason why we have these Webex's. To discuss what was discussed
so far and to project to the next steps. In the process try to understand
what people want.

Dirk is going to announce the next Webex time and date and we hope that
everyone attends the call.

 Behcet

> Dino
>
> > On Dec 10, 2018, at 9:49 AM, Tom Herbert <tom@quantonium.net>; wrote:
> >
> >> On Mon, Dec 10, 2018 at 9:36 AM Dino Farinacci <farinacci@gmail.com>;
> wrote:
> >>
> >> Yes I know. And you have mentioned this before. Are you trying to make
> a new point or repeating an old one?
> >
> > I am trying to understand what problem this group is intending to solve.
> >
> >>
> >> Dino
> >>
> >>>> On Dec 10, 2018, at 7:39 AM, Tom Herbert <tom@quantonium.net>; wrote:
> >>>>
> >>>> 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
> >>>>>>
> >>>>
>