Re: [Pidloc] PIdLoc Webex

Tom Herbert <tom@quantonium.net> Fri, 07 December 2018 18:37 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 69B37130F8E for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 10:37:58 -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 m-wvWJuJwoSr for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 10:37:56 -0800 (PST)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 AF060130F8A for <pidloc@ietf.org>; Fri, 7 Dec 2018 10:37:56 -0800 (PST)
Received: by mail-io1-xd30.google.com with SMTP id k7so4029613iob.6 for <pidloc@ietf.org>; Fri, 07 Dec 2018 10:37:56 -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=vLXahF6s/tmibENiFKiQa3rTglqBVS1Fa/sskwXfX5M=; b=Tg69S2Y//MhWX7OEID7a1AJuHApj9mmqo1UflD3YOFkHfYK1BpfvAeTsLrlGjjFZLE J5SfkUEKCFgeZdBZF7uS3phiPcDcKkRccxxN8U/LG44qlhqPQbFJVgmbAMGfiSEpkMPu 7aR2ZtsvlNkXJWUpjy7XAS3UZXw12gKRAYqF9rXHqoksRp6koW9Skh48Eiht4LO+bYPN hcz2OBofLeOj2P6S5CiJDvKL00zd0vpFc8KJL2v+KZEqbLkcLBudJKItSUTu02DS9dXG mmIXtw3c0YtfhV11zwd35PpUNa0Oi9NT9rkqkz3Mmd1JHX97qJ1idVTUtV5fhSE78Tu9 v2vg==
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=vLXahF6s/tmibENiFKiQa3rTglqBVS1Fa/sskwXfX5M=; b=FQQ5Q4u/gOdjEnlhYZRp2O3wrpMfVoA66lXt8TyTuNAMirhz25QAQXB2f8P/ifvYXE YDoMPH/rcPMPnu5ZQKdhU7jDOdZX+8UtqxvtzNWJ/CXrkG/Ue/iPYMIYo43UOTFJsooM dP72vyrfN0m2xtL/z+UkscscSCxmWg9Ki3lFE7+I9apMiyaM5/aFKgHExPsKTHX7ams7 zR4OB0SF73PwODGCEj+5IFWHZek1CoXmPR4H52m6Ipv4HYRfD/GBp2LkcuJW8wh+GTT+ LOi3gb2IlbKNMEXsPYUrEpYK6Xry8OwWXYuKcM9Eb1znzEDdfOHt2X6wYXjztPaJiYud z0Lg==
X-Gm-Message-State: AA+aEWZ3wiKjcOVnJzVn0DiY9y6DayLxokpEEfpavtRZ+0+KN5UMed6I 65QsSl7YXzp0tadgx0OcX0qlnARGZ3VOOmZZD9hNLw==
X-Google-Smtp-Source: AFSGD/VTLWnIJXMht2KkpWoEdv6wKVVa+PXFEFqQVjNfbFqWDoZb6rgiyefGR9fjR8Kv5qXJp8j2H165qH5aGNybzCg=
X-Received: by 2002:a6b:ab83:: with SMTP id u125mr2517373ioe.211.1544207875735; Fri, 07 Dec 2018 10:37:55 -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>
In-Reply-To: <3BB55FFA-D711-43AB-A788-AD7AA300D7DF@gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Fri, 7 Dec 2018 10:37:43 -0800
Message-ID: <CAPDqMermOi_avv24f9=mawUJ3HAvLjqv3CbhziOL5pWCLbtDdA@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/F6_qJJPE3iCEfTWJN1hwvyrJ2io>
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 18:37:58 -0000

On Fri, Dec 7, 2018 at 10:16 AM Dino Farinacci <farinacci@gmail.com> wrote:
>
> >> 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.
>
> You are bringing up a different issue now. And we have discussed this at length before. But as long as you have an underlay and plaintext headers, you still lose privacy even when EIDs are obfuscated.
>
The underlay protocol is not relevant to privacy, it is only the
mechanism used in a closed provider's network to deliver packets to
their destination. Outside of the network, only plain IP packets are
seen. It is the privacy attributes of the packets visible to the world
that are interesting.

> If you put LISP xTRs inside of an ISP, then you have hidden aggregation of the RLOC addresses and any user addresses (EIDs) are obfuscated from payload encryption (i.e. lisp-crypto).
>
> Dino