From nobody Thu Jan 21 21:45:17 2021 Return-Path: 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 ; 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 ; 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 ; 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 ) 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 ; 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 ) 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 ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jan 2021 05:44:49 -0000 Subject: Re: Non routable IPv6 registry proposal To: Phillip Hallam-Baker , Brian E Carpenter Cc: Michael Richardson , IETF Discussion Mailing List References: <72F969A9-AF94-47B6-B48C-B3CD4D9A7C72@strayalpha.com> <7cc9e38c-5a00-ec59-a8c2-10503cc40d50@si6networks.com> <00a9feed-5e48-05de-b3ee-27d9a98c6be1@gmail.com> From: Christian Huitema Message-ID: 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: 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: X-BeenThere: ietf@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IETF-Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jan 2021 05:45:15 -0000 This is a multi-part message in MIME format. --------------C042D5BCAF6FE5356DE05740 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 1/21/2021 5:02 PM, Phillip Hallam-Baker wrote: > On Thu, Jan 21, 2021 at 2:56 PM Brian E Carpenter > > 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 --------------C042D5BCAF6FE5356DE05740 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

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


--------------C042D5BCAF6FE5356DE05740--