Re: [Ila] [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: ila@ietfa.amsl.com
Delivered-To: ila@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A07212DA0A for <ila@ietfa.amsl.com>; Thu, 22 Feb 2018 11:53:28 -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 0FgGuqj-4Gi8 for <ila@ietfa.amsl.com>; Thu, 22 Feb 2018 11:53:25 -0800 (PST)
Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::22b]) (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 2462F12DA1C for <ila@ietf.org>; Thu, 22 Feb 2018 11:53:15 -0800 (PST)
Received: by mail-wr0-x22b.google.com with SMTP id m5so11802765wrg.1 for <ila@ietf.org>; Thu, 22 Feb 2018 11:53:15 -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=I+3LDqLXGOjd4QFqVL9KY4zxTYqJemX7cb1SkV+Olawe/zg9aeBGlSxiywE0rg11r/ Kx6IjEPdM3U/iT6cJ8tVlNunyRfDPawAHxjTYGtrRIHbZEM81tvojPf7uYXBRuB+RSUt 5IcXWJjCeS+LS9yS9s2zLmumOeEXHb+r3Khdkafzb4NuqV3Ur5IHwfjjanR8LZw9ct12 glgdUjUMI+/RzfVOhrUSZmsEL7qHmKrCaYX5mIuzbqKDcQGj5um0uOWXVIEReRebR/eN mwkTjWvrskostwMlt9S2jyeEkV8NapleEaLGrHQi7yn5O/zpesQjPMstm2XVwQZdp26r 132w==
X-Gm-Message-State: APf1xPDDPmM2n1+Tj//qJCvaYYkATdceiTV6U+APjQLmagSP79f2sVJ5 Mv6z7uuYud27w/jIVGFJjEDPG3kcZTsqgeoIEwUojw==
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/ila/oFDqNnbWUUVNTOsHASvPfTisVIw>
Subject: Re: [Ila] [5gangip] Fwd: New Version Notification for draft-herbert-ipv6-prefix-address-privacy-00.txt
X-BeenThere: ila@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Identifier Locator Addressing <ila.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ila>, <mailto:ila-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ila/>
List-Post: <mailto:ila@ietf.org>
List-Help: <mailto:ila-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ila>, <mailto:ila-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Feb 2018 19:53:28 -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