Re: [Pidloc] PIdLoc Webex

Dino Farinacci <farinacci@gmail.com> Fri, 07 December 2018 19:46 UTC

Return-Path: <farinacci@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 E5C71130E96 for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 11:46:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham 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 sFHbPvM3tNAQ for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 11:46:05 -0800 (PST)
Received: from mail-it1-x12c.google.com (mail-it1-x12c.google.com [IPv6:2607:f8b0:4864:20::12c]) (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 0E62A1200D7 for <pidloc@ietf.org>; Fri, 7 Dec 2018 11:46:05 -0800 (PST)
Received: by mail-it1-x12c.google.com with SMTP id a6so8837883itl.4 for <pidloc@ietf.org>; Fri, 07 Dec 2018 11:46:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l8Um04/TC6rFlFBQtzmhTQmVmAzOkdTE2ggOvaHJlJE=; b=A2ub8oC/5sXrNMttivpZnzWDu0LXeiDCkOF4u9pSC43MJsdB6F0FP9Ot1x4iZ9V3cd xIXzzfTWMtlQ+nB6tIyb7za8qk12KsQMncliU3UQXijCQ4166dtdy4onrPPNo4KlJKCd Z0i53kwzOoo4lFZotE6Igg9MKURyA1id4lCB6xGWHzAL1BazMUG4cJhMDH+jT0xPO4d6 f/WijK1M+4sMVs/uurk0rAqP04WwM7tCAbIOb3w/nFr3GgP1YArF7HEzODw0OYWV2Yg0 +UM3br9JrwdWVeJ3NtqqwqyWFM971n0EDG+vBSTULIA6uTWdrUgosHAqpGF7QwdodFpI Dbcg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=l8Um04/TC6rFlFBQtzmhTQmVmAzOkdTE2ggOvaHJlJE=; b=tjN+3NnBteFVm5p8aMJRCWTyeLf4ZMxbY2NSXGSt8+h5xzLkdjMGP4B/7u/f+99utJ gD8tGFqyKoY9jcnuzKUx8KmOUTcvDWuK7JnUXTQ+rJHpwNFa89fBeBCvt3wW+1/cBYrZ 5rmkANx+gp0m9M2MuiP41SW8kA5AAWswmii/6lQoAQhsvVMFDBFqJHJD5K/azx3nbgYv nAn4ht9ZfijIZ+V4WTe785SKrfeu6R25jvWy+zdKAVt3eiS6WSlocg/K6N+2smGKIyHP 6dD2lF3CN5gsg8WaI8AJ4SjNmkOrBTNhGo+Fp5PA/h8kyti5d0QVIIWa4RAFVN6mz5t2 DoTw==
X-Gm-Message-State: AA+aEWbN1tX/nR8SWqFlOGT3AEI7+BAFCs1tKETQ0egUoOnnaUrzxIAg CKkaZyFEHaSYoLdoz0Bsudg=
X-Google-Smtp-Source: AFSGD/Wi8vJ836jlQOfY3PRLyN02YGdzaMk6W3uySP1CXyIZo4L2cIWtKRC1pCuVR3lYjeQDZ2DpDw==
X-Received: by 2002:a02:7e5d:: with SMTP id h90mr3097664jac.106.1544211964285; Fri, 07 Dec 2018 11:46:04 -0800 (PST)
Received: from [172.19.131.149] ([8.46.73.106]) by smtp.gmail.com with ESMTPSA id u126sm2071949ita.1.2018.12.07.11.46.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 11:46:03 -0800 (PST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Dino Farinacci <farinacci@gmail.com>
In-Reply-To: <CAPDqMepPQ_0NAK7ip6vX7x-Ge9k3DWEViNg=37WQPDS5eTvFCg@mail.gmail.com>
Date: Fri, 7 Dec 2018 11:45:56 -0800
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-Transfer-Encoding: quoted-printable
Message-Id: <490EDBBB-CD3D-4552-BE93-38651B913D13@gmail.com>
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>
To: Tom Herbert <tom@quantonium.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/y4_HO8POs5m27NfATdCUlknVtuI>
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: Fri, 07 Dec 2018 19:46:07 -0000

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

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