Re: [Pidloc] PIdLoc Webex

Tom Herbert <tom@quantonium.net> Fri, 07 December 2018 17:32 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 87EFA130F2B for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 09:32:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 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] 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 EnAsVq9Hqjcb for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 09:32:21 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 AC831130E78 for <pidloc@ietf.org>; Fri, 7 Dec 2018 09:32:21 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id o19so8019559itg.5 for <pidloc@ietf.org>; Fri, 07 Dec 2018 09:32:21 -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=dgzKHelpaGDWpFV40ed9GjPePiH/m8h7vACzj2MYXHI=; b=GBWDism1mpIC7rhj2/3E2UVQHXx24pIyF0GEwDZQBUymrW3nU81d3FvI0ejeAou2dv HzBbbjFXck21O5CC52TrFyC0XL1l9UZDuOXUPZWMAGtSIOM1BCZZiQ/E5A2E9Iwx2Ic3 EKEfNiuA53EB14envM3liHW8UxehR+tnPMzVy72hLrwt8ci94zPXYvJyoaAzBFKpxleZ pISGqwkrN4GwmnG/5fBT7w5ltMLcByaJCOV3lIVx02B0Inmof5bwFCSokcURInnu+ntA KwIM6ptR3LWNJsWlxuyEU8COCfrCOmPCqCgiwBh6ESTqeeDwiybDNIQ5albmCbGvpOSx dSZQ==
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=dgzKHelpaGDWpFV40ed9GjPePiH/m8h7vACzj2MYXHI=; b=cAAhy+HOBsriDsO/PrWcw6QeVTNCUv7XlijYMDTgPxJ756edhxRiCxbDA3lX2DqVPe 4N7/BFqwVYqBdOLJY9KIgrFapNlIV4bu9Pfo1g1nIabVnoUUCytWw6E3ojqro3SNHTcQ s1wFHgoi08QSkyNClruUSas3jF8aY3YvV0dxMN7Y8M9M/W0ws77gGVeireMAoDGaMFqU EE54TegrCrYtkQ+42M1Vf/WsGqBm0E+X5/wMKA0GqxRi3Oz+UAMwmvMfbc1cCJUmaYGa VuYzCqfLXX4ThuqxbuAnbBwU8qSHKKAfwfb9+pOZwS849sQVmO6gCHq5eQ2phTkoYKFK AynA==
X-Gm-Message-State: AA+aEWYaNe9RlomebLefU/vItLOBegkT5edsY52rZlyeY6ToNozLQnAo qkf+WySm2Yv53aM3JUAMtFTYMMVheCCjyjXcj7aYRw==
X-Google-Smtp-Source: AFSGD/XsrvltWD2PaWdko6Nb/dT4Do5APNNH2JXsVhqqz7H71+2K8lduMWwHA3O13qoa/SnPumjAXpqq156wmME7Hsw=
X-Received: by 2002:a02:7e95:: with SMTP id g21mr2426783jae.114.1544203940637; Fri, 07 Dec 2018 09:32:20 -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>
In-Reply-To: <5CDE5968-FF04-4F8D-96F6-5CE51445B3CC@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 7 Dec 2018 09:32:07 -0800
Message-ID: <CAPDqMeoRBD0qFFgnwpZghaNz7aHJA_mXfc16ainwjDhXQMQ+ew@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/5D1tg91T6Zjd1QphVFCshfRalo8>
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 17:32:24 -0000

On Wed, Dec 5, 2018 at 2:42 PM Dino Farinacci <farinacci@gmail.com> wrote:
>
> > Dino,
> >
> > Just run your mapping system in a closed and presumably secured
> > network. Every service provider can run their own mapping system and
> > there's no need or value to build global mapping databases.
>
> Yes, of course. That has always been an opiton and many enterprises are doing that today.
>
> >
> >> That’s the best any design can hope for. The IP header can only be sent in the clear.
> >>
> > In order to communicate with Internet hosts plain text addresses are
> > used in packets. The are identifiers in idloc terminology and they are
>
> In headers in particular. I hope you agree it can be avoided in payloads.
>
> > exposed to the whole Internet. It's the privacy properties of these
> > that are of interest. For instance, today many service providers
> > assign a /64 to their users. So, that means that if a third party on
> > the Internet observes two flow with source addresses sharing the same
> > sixty-four bit prefix they can deduce that the source is the same (the
> > same user in case of personal devices). What is really needed for
> > privacy is to use a different uncorrelatable address per flow. Under
>
> Agree.
>
> > certain conditions, CGNAT provides that today which is why law
> > enforcement agencies are terrified of it. In lieu of NAT, idloc could
> > key to provide this privacy without resorting to NAT. See
> > draft-herbert-ipv6-prefix-address-privacy-00.
> >
> > Tom
>
> Understand. But randomized addresses assign to tail site can still be achieved without the high-cost of managing a CGNAT. You only need to route back to that randomized/ephemeral address for a short period of time. In fact, the ISP can withdraw the route when it wants the tail site to use another address.

That's where the scaling problem comes in. A mapping system should
scale to support a billion mappings in a single network, maybe
something like a 100M devices and ten mappings (identifiers) per
device. That is manageable. For instance if entries are 50 bytes then
the whole mapping database could fit in 50G of memory. But, if end
hosts use a different source IPv6 address for each connection, then
the number of mappings that would be needed increases by several order
of magnitude. That is not so manageable. Assuming end hosts might want
up to a thousand ephemeral addresses at a time, the memory requirement
is now 50T and this puts a lot of pressure on the network when
mappings need to be moved around. The alternative discussed in
draft-herbert-ipv6-prefix-address-privacy-00 is "hidden aggregation"
whereby the network is able to aggregate some number of addresses
(identifiers) to the same mapping, but outside of the network no
relation between addresses can be drawn.

Tom

>
> Dino
>
>