Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt

Tom Herbert <tom@quantonium.net> Thu, 22 February 2018 19:53 UTC

Return-Path: <tom@quantonium.net>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5751A12DA03 for <int-area@ietfa.amsl.com>; Thu, 22 Feb 2018 11:53:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 uf8DXsUgKRaR for <int-area@ietfa.amsl.com>; Thu, 22 Feb 2018 11:53:28 -0800 (PST)
Received: from mail-wr0-x22c.google.com (mail-wr0-x22c.google.com [IPv6:2a00:1450:400c:c0c::22c]) (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 2467512DA24 for <int-area@ietf.org>; Thu, 22 Feb 2018 11:53:15 -0800 (PST)
Received: by mail-wr0-x22c.google.com with SMTP id l43so11814543wrc.2 for <int-area@ietf.org>; Thu, 22 Feb 2018 11:53:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=quantonium-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jsXw7SGi0TD7hB01UNn7+C7G+TtDRPFo12OCwDYhYdY=; b=1RwwvY57QpuZoB/VhTgx/BVjwjlk4bOhaZXFBQI8o5lct3FRpiicQnkY70HnLJ7TvK y1qWQgx9c/pqiHVjLlm9tqjNuZabilcJUBxvK1snTzzaURA6ZXhFHXaywpoLaL8xcMSg Z8wXvo4W26K4DMfvDnj9Mssq2O5+JoWXWiEVTiuo5V8s2uMRBhVVsPFTdyrs/Y7xSxV7 hhY5m8HU8huO/ry+fUwJ62J1XJe6FbNBD1V/xVkIIPYhWiNFQyFntqCuVu7vYQgdvNFk sRrJ69b/IzQBVtrSzLoaBIz3laUqEtFX0dROrxHTyZ0APgPUSIDgGblKwXR/3NeDt+Rj 6Kuw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jsXw7SGi0TD7hB01UNn7+C7G+TtDRPFo12OCwDYhYdY=; b=Q8pjnUMIDF6jq8AjVi3VZUCzZo8cvusM999onu0vZ+D2IFrzfGwERKWq87ArYxvTaY 5ByaP8j3wULAf+k5+Y3LssoBsMVUVFiqPMHpLLdrooO7ahTSSk1Vp1mjXGO/hpp69MZT XVy4A/LqWsqaCXjk1icUBtpw2A45zJNqEfRZCCsBXZC9eiT1vbMfiSbU5VAXCyTbWdwH 63x8wYtoWMv7GOIdehUFOWkBj33yPcL60mwiWw5KgTTfIc5FlM+JHO2/YAI/ORMJSeC1 z28Cw64kK0Yonf+rVSkojQZzL/dJXGdjk0Y5fWCtYmM0m7nrrbIXnRqLqCs+Z9oYbKnC j01Q==
X-Gm-Message-State: APf1xPCP3qY5VeP0oiZmBEz7ZffnRT6OCxYnlkz9WtS1mAY2Xu5u/zcz /VCOfvLAhN0iJdPcXSQuplZBXPlguUhM1zarxVKPFg==
X-Google-Smtp-Source: AH8x225mADQyFdoSrk0wPz47Ls7lslp2u0nkwzm10opcx65u+x5IcX2HmJ13CzVZJaKZ9Miulew4vtkQ/0HRaw0UMsM=
X-Received: by 10.223.131.133 with SMTP id 5mr6773261wre.153.1519329193559; Thu, 22 Feb 2018 11:53:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.223.135.74 with HTTP; Thu, 22 Feb 2018 11:53:13 -0800 (PST)
Received: by 10.223.135.74 with HTTP; Thu, 22 Feb 2018 11:53:13 -0800 (PST)
In-Reply-To: <CAKD1Yr3p0P3zC_QFzQrGKAh+0eO3-rTG6_ZkWsO36dFHmk8rfQ@mail.gmail.com>
References: <151906718318.18731.8986618406430268357.idtracker@ietfa.amsl.com> <CAPDqMeqajavRJ85fUkrdxg1Bjz54kHuWfqbnGgpM7Br7T6MVmQ@mail.gmail.com> <alpine.DEB.2.20.1802211549260.3478@uplift.swm.pp.se> <CAPDqMerU9k4DEQrMi8qyneYB=i=1qnuwRiUf8FQoGrd_QxUmZQ@mail.gmail.com> <alpine.DEB.2.20.1802211654010.3478@uplift.swm.pp.se> <CAPDqMepCnAniuCFPu+TGPJ=qOO9khXUJw3RECPvPDtU8HEAOxw@mail.gmail.com> <CAKD1Yr3p0P3zC_QFzQrGKAh+0eO3-rTG6_ZkWsO36dFHmk8rfQ@mail.gmail.com>
From: Tom Herbert <tom@quantonium.net>
Date: Thu, 22 Feb 2018 11:53:13 -0800
Message-ID: <CAPDqMeozvP88jveJSZZZ8GX28LDKLkSC3YvSvs083VRy6dEp1g@mail.gmail.com>
To: Lorenzo Colitti <lorenzo@google.com>
Cc: Mikael Abrahamsson <swmike@swm.pp.se>, ila@ietf.org, int-area@ietf.org, 5GANGIP <5gangip@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c0d2940e120030565d26441"
Archived-At: <https://mailarchive.ietf.org/arch/msg/int-area/s8LkrPu6DHRkjHhg9xKVDjKKAok>
Subject: Re: [Int-area] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 19:53:29 -0000

On Feb 21, 2018 10:38 PM, "Lorenzo Colitti" <lorenzo@google.com> wrote:

On Thu, Feb 22, 2018 at 10:51 AM, Tom Herbert <tom@quantonium.net> wrote:

> The hidden aggregation method is intended to make scaling possible.
> Each assigned block results in on entry in mapping system so total
> amount of state is num_hosts*num_blocks per host. e.g. in a network of
> 10M nodes with 100 blocks per host that's 1B entries in the mapping
> system-- should be able to scale that.


I have a fundamental problem with the assertion "should be able to scale to
1B mapping entries" given that a) current routing hardware capabilities are
three orders of magnitude away from that, and b) anyone on the Internet can
mount a state exhaustion attack on the mapping system simply by originating
a packet to any IPv6 address in the domain.

Personally I don't think this work should progress until we have line of
sight to a system that can actually do that.


Lorenzo,

The intent of this draft is to articulate a problem that may be worth
working on. It's not to specify the solution, although I think it makes
sense to at least suggest some possible paths for a solution to establish
that the problem is solvable. Also, there is not necessarily just one
possible solution. The draft mentions possibly of hybrid assignment of
addresses for different privacy requirements, and how NAT is an existing
technique that  can provide strong privacy in addressing (I hope there is a
better solution that does not rely on NAT).

Tom