Re: [Pidloc] PIdLoc Webex

Dino Farinacci <farinacci@gmail.com> Fri, 07 December 2018 18:16 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 671D3130F88 for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 10:16:35 -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 XSWHEIos3okV for <pidloc@ietfa.amsl.com>; Fri, 7 Dec 2018 10:16:33 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (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 7D783130EC7 for <pidloc@ietf.org>; Fri, 7 Dec 2018 10:16:33 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id c9so8458219itj.1 for <pidloc@ietf.org>; Fri, 07 Dec 2018 10:16:33 -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=jPRMRxfHIKl8/08HW2/jdsJK6D6zqhDSjh3Tev5Ht3Q=; b=hxTaBXjA4K9Oaj36NeHXLszNk0U3qHuxK5XPAwc3R/Po2sJ+625++NJJjO43C6gYCx O+mJFP6j70cmiUNY61hqiB0R0Hqg2ZhDAFyUa8+zPWn0/86CZrGlYsnYp7U8dIH4/IQf YmKpviCYb9Fc9L3u1ERX3VbJh3y1BLMAmw5LEMWJ+VtAbphzONoW65qBOXgnzVCeDlIH mgrJr/BxiIFScur2dZdLVImkmamBmGZZQTCtJoDm/gCrXF/fFn1YyP0dp9PweTGo37QE 4qPM+ibdT0+hEDgHmYuQ5fLRhq2KzA8YSey9uGh1nnIsXaaLba7VyzwV6/041YXQkfUO uTkg==
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=jPRMRxfHIKl8/08HW2/jdsJK6D6zqhDSjh3Tev5Ht3Q=; b=nD7iAgqRI+LqXRqLbp4AMfTwLklgSqXi6SDAC0hyR8rqVl9ZI+oETzcSKAAYMhPEzI b3WuYFt1gOL1SGTJ5rP8PXRFL211s/x9hnybQe7SeP+gOZlLPEOCkpWl4kU0M48A/7po XKiNxHaHT1xu8R+/gLG2QDo4v9ieURaxArbiP5BMiUqwZiY6Ux90VGb0ennDQ7vqi9im FW3mWQnN4MDMHEvakmbsK4dWlRt8beyCmXD1c1/r3ra/y4neTVurjyluK8mCk1H9TjNy 0MN9YUsCYbQolUd3IToWcCKJhmAD5N8TJ+7PG4V+f1dIgiRNrrb5wWBfcpupGfhph4QP uXTg==
X-Gm-Message-State: AA+aEWaxtaepgW21eR4CcdztNIlxfVOpNknJ0kuQ5kFUnBnqoVGNI/8o T86htM+EB9JS9vBKgdftBi8=
X-Google-Smtp-Source: AFSGD/VYKmxSuMCynxgo0S1s54g3Vutnn64prbSuT5KrvEa3NJmP/Kq0K7wtFDfyLBvFFtTGPojvww==
X-Received: by 2002:a02:8244:: with SMTP id q4mr2731340jag.43.1544206592842; Fri, 07 Dec 2018 10:16:32 -0800 (PST)
Received: from [172.19.131.149] ([8.46.73.106]) by smtp.gmail.com with ESMTPSA id w8-v6sm2286768ita.18.2018.12.07.10.16.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Dec 2018 10:16:31 -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: <CAPDqMeoRBD0qFFgnwpZghaNz7aHJA_mXfc16ainwjDhXQMQ+ew@mail.gmail.com>
Date: Fri, 7 Dec 2018 10:16:18 -0800
Cc: "<Dirk.von-Hugo@telekom.de>" <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: <3BB55FFA-D711-43AB-A788-AD7AA300D7DF@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>
To: Tom Herbert <tom@quantonium.net>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/pidloc/FYNh3IIunjHOMmLGLAg3XeIvIHU>
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:16:35 -0000

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

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