IETF Logo Mail Archive

Re: Non routable IPv6 registry proposal

Christian Huitema <huitema@huitema.net> Fri, 22 January 2021 05:45 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61BD53A10E8 for <ietf@ietfa.amsl.com>; Thu, 21 Jan 2021 21:45:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.15
X-Spam-Level:
X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.262, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 u0l_O7jh00lg for <ietf@ietfa.amsl.com>; Thu, 21 Jan 2021 21:45:14 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEA603A10EB for <ietf@ietf.org>; Thu, 21 Jan 2021 21:45:13 -0800 (PST)
Received: from xse375.mail2web.com ([66.113.197.121] helo=xse.mail2web.com) by mx136.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1l2pFk-000Dx2-16 for ietf@ietf.org; Fri, 22 Jan 2021 06:45:09 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4DMSrf2KRdz3JRp for <ietf@ietf.org>; Thu, 21 Jan 2021 21:44:50 -0800 (PST)
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1l2pFa-0004T6-7U for ietf@ietf.org; Thu, 21 Jan 2021 21:44:50 -0800
Received: (qmail 22084 invoked from network); 22 Jan 2021 05:44:49 -0000
Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.146]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 22 Jan 2021 05:44:49 -0000
Subject: Re: Non routable IPv6 registry proposal
To: Phillip Hallam-Baker <phill@hallambaker.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, IETF Discussion Mailing List <ietf@ietf.org>
References: <CAMm+LwjNiE0P7RAVqzKMypNbh3=9BeqiWn_hGv3E=zX7-YmSXQ@mail.gmail.com> <72F969A9-AF94-47B6-B48C-B3CD4D9A7C72@strayalpha.com> <7cc9e38c-5a00-ec59-a8c2-10503cc40d50@si6networks.com> <CB1A6DF0-8CDD-495D-9F7B-80BF72F08C1E@strayalpha.com> <CAMm+LwjU2SQeydRJ7zcDORz+1-z634OCe34HMKTKHiQvg+4M7w@mail.gmail.com> <00a9feed-5e48-05de-b3ee-27d9a98c6be1@gmail.com> <CAMm+Lwgonpf7TgA-oHR+bk3LvKA2Dc5q-2uEan318D37vAkwAA@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Message-ID: <e822c970-745b-c57c-4fe2-622ac9c4eebe@huitema.net>
Date: Thu, 21 Jan 2021 21:44:50 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <CAMm+Lwgonpf7TgA-oHR+bk3LvKA2Dc5q-2uEan318D37vAkwAA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C042D5BCAF6FE5356DE05740"
Content-Language: en-US
X-Originating-IP: 66.113.197.121
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x9j7219Tb9QoiGKb6esGsuKj/EwzSHE5FGYwwjsNRPCP82 Mx5H9kmHoHUisa715KvmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7ImcaL7AIZCYu4mCZJxCTGWvKzxQ6V51u76v35b1wNe/MvdLom48E g3of4Y9DlgiJ0nAJ2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NQ/T3Op6Um662jkOH4Bxha99Q5P52x4uJZ5J61BsyVNec MM1uttU3nerrdzn9lqqMDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfHoLv56f7lG+I3MHK9HtkKtUoFIvD3sIcP1fhJPM6B/8xcyA vr+TNaPkgOSs7TalmpDLMs+LenTcUN4hdMuJYJyJ+dym1L8cD17Js0v4cp1M12ytzBdKjnL743WS 1vciWjcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/S7ZDgoOJpV4zOnViWzfrhde-FuE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jan 2021 05:45:15 -0000

On 1/21/2021 5:02 PM, Phillip Hallam-Baker wrote:

> On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter 
> <brian.e.carpenter@gmail.com <mailto:brian.e.carpenter@gmail.com>> wrote:
>
>     Putting two things together:
>     On 22-Jan-21 07:57, Phillip Hallam-Baker wrote:
>     ...
>     > A ULA->Public key registry provides exactly the right degree of
>     incentive. It allows us to take an area that is currently flaky as
>     heck and make it 'just work'. That area is VPN access.
>
>     Yes, but afaik you (or I) can't claim ownership of random numbers.
>     So if my ULA prefix is fd63:45eb:dc14::/48 and I provide a public
>     key for it, what's to stop you using the same prefix and providing
>     your own public key for it?
>
>
> The registry undertakes to only issue each prefix once and bind it to 
> a public key specified by the holder.
>
> The registry publishes the allocation in an append only log which is 
> attested by a blockchain type technique. So there is (almost) no scope 
> for the registry to defect.

How do you protect the registry against a Sybil attack?

-- Christian Huitema

v2.23.0 | Report a Bug | By Email