Re: [Din] [OPSEC] blockchain for IP addresses draft update

Jordi Paillissé Vilanova <jordip@ac.upc.edu> Wed, 04 July 2018 15:50 UTC

Return-Path: <jordip@ac.upc.edu>
X-Original-To: din@ietfa.amsl.com
Delivered-To: din@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C054130E6C; Wed, 4 Jul 2018 08:50:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 3zOPeRILVRne; Wed, 4 Jul 2018 08:50:33 -0700 (PDT)
Received: from roura.ac.upc.es (roura.ac.upc.es [147.83.33.10]) by ietfa.amsl.com (Postfix) with ESMTP id 93CF112785F; Wed, 4 Jul 2018 08:50:32 -0700 (PDT)
Received: from correu-1.ac.upc.es (correu-1.ac.upc.es [147.83.30.91]) by roura.ac.upc.es (8.13.8/8.13.8) with ESMTP id w64FoIqD012465; Wed, 4 Jul 2018 17:50:18 +0200
Received: from [147.83.35.232] (dync-35-232.ac.upc.es [147.83.35.232]) by correu-1.ac.upc.es (Postfix) with ESMTPSA id 1CED1283; Wed, 4 Jul 2018 17:50:13 +0200 (CEST)
To: "Roque Gagliano (rogaglia)" <rogaglia@cisco.com>, David Mazieres expires 2018-09-30 PDT <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>, "sidrops@ietf.org" <sidrops@ietf.org>, "din@irtf.org" <din@irtf.org>, Stephane Bortzmeyer <bortzmeyer@nic.fr>, "sandy@tislabs.com" <sandy@tislabs.com>, Greg Skinner <gregskinner0@icloud.com>, "leo@vegoda.org" <leo@vegoda.org>, "Alberto Rodriguez Natal (natal)" <natal@cisco.com>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>, "Fabio Maino (fmaino)" <fmaino@cisco.com>, Albert Cabellos <acabello@ac.upc.edu>, "opsec@ietf.org" <opsec@ietf.org>
References: <153028668788.30332.9615982545028670114.idtracker@ietfa.amsl.com> <fbe24301-9827-090d-d1e6-fd60fd2de7f7@ac.upc.edu> <87lgat633l.fsf@ta.scs.stanford.edu> <ee6d93bf-6f79-a4a9-9f1e-a786860f9c5b@ac.upc.edu> <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com>
From: =?UTF-8?Q?Jordi_Pailliss=c3=a9_Vilanova?= <jordip@ac.upc.edu>
Message-ID: <56694f02-cf91-8569-c57f-7f3c319a7e9f@ac.upc.edu>
Date: Wed, 4 Jul 2018 17:50:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <9BC0DE80-D827-414B-916B-C102C3460563@cisco.com>
Content-Type: multipart/alternative; boundary="------------C635D4B6DCE5FBC5E32EEF32"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/din/yqqtA-CqL_7800sZ_k7creFlTk4>
X-Mailman-Approved-At: Wed, 04 Jul 2018 21:08:57 -0700
Subject: Re: [Din] [OPSEC] blockchain for IP addresses draft update
X-BeenThere: din@irtf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: "Discussion of distributed Internet Infrastructure approaches, aspects such as Service Federation, and underlying technologies" <din.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/din>, <mailto:din-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/din/>
List-Post: <mailto:din@irtf.org>
List-Help: <mailto:din-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/din>, <mailto:din-request@irtf.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Jul 2018 15:50:40 -0000

Hi Roque,

We have built an open-source prototype [1], and it works like you 
mentioned: the genesis block includes the public keys that the RP has to 
trust. It is a one-time action in which you trust the source code and 
the keys contained in it.

Thanks for your comments, we'll include them in the next version.

Regards,

Jordi

[1] https://github.com/OpenOverlayRouter/blockchain-mapping-system


El 04/07/18 a les 14:09, Roque Gagliano (rogaglia) ha escrit:
>
> Hi Jordi,
>
> Very good document.
>
> I hate to ask things without providing code but I believe it would be 
> great if you add a section regarding the “relying party”, how would 
> the validation algorithm would look like and what is the bootstrap 
> process. I can see that some public key info would need to be known by 
> the RP.
>
> Regards,
>
> Roque
>
> *From: *OPSEC <opsec-bounces@ietf.org> on behalf of Jordi Paillissé 
> Vilanova <jordip@ac.upc.edu>
> *Date: *Wednesday 4 July 2018 at 13:28
> *To: *David Mazieres expires 2018-09-30 PDT 
> <mazieres-pebagr7ysjghwpqkcqqnjjf4ta@temporary-address.scs.stanford.edu>du>, 
> "sidrops@ietf.org" <sidrops@ietf.org>rg>, "din@irtf.org" <din@irtf.org>rg>, 
> Stephane Bortzmeyer <bortzmeyer@nic.fr>fr>, "sandy@tislabs.com" 
> <sandy@tislabs.com>om>, Greg Skinner <gregskinner0@icloud.com>om>, 
> "leo@vegoda.org" <leo@vegoda.org>rg>, "Alberto Rodriguez Natal (natal)" 
> <natal@cisco.com>om>, "Vina Ermagan (vermagan)" <vermagan@cisco.com>om>, 
> "Fabio Maino (fmaino)" <fmaino@cisco.com>om>, Albert Cabellos 
> <acabello@ac.upc.edu>du>, "opsec@ietf.org" <opsec@ietf.org>
> *Subject: *Re: [OPSEC] [Din] blockchain for IP addresses draft update
>
> Hi David,
>
> Indeed, we did not delve deeper into the PoS algorithm. This depends 
> on the specific implementation, our opinion is that an Algroand-like 
> would be a good option, and if it can tolerate a large portion of 
> offline participants even better. In addition, we think that punishing 
> or deposit mechanisms are not desirable because they don't fit the 
> characteristics of the scenario. Overall the incentive is "a more 
> secure Internet", we believe that this is well-aligned with the 
> economical interests of the participants.
>
> Regarding SCP, the fact that you only need to trust your neighbours 
> may prove very convenient in this scenario. As you said, it reflects 
> current Internet trust schemes, this basically means that BGP Peering 
> = Trust = Stellar quorum slices. We'll look into this for the next 
> iteration of the draft.
>
> Thanks
>
> Jordi
>
> El 02/07/18 a les 17:59, David Mazieres ha escrit:
>
>     Jordi Paillissé Vilanova<jordip@ac.upc.edu> <mailto:jordip@ac.upc.edu>  writes:
>
>         (apologies for cross-posting)
>
>         Dear all,
>
>         We have submitted a new version of the draft addressing comments
>
>         received both on the mailing list and IETF meetings.
>
>         Thanks to all of you for taking the time to read the draft :)
>
>         Regards,
>
>         Jordi
>
>     Very interesting draft.  One high-level comment, I would avoid terms
>
>     like "tamper-proof" or really anything-"proof" except possibly in the
>
>     context of information-theoretic security, in favor of tamper-resistant.
>
>     This is particularly important in the context of blockchains that have
>
>     experienced a number of forks in practice and where it would likely take
>
>     only a few tens of millions of dollars a day to tamper with history.
>
>     I think the draft would benefit from a much finer-grained consideration
>
>     of several different forms of proof-of-stake, because there are a number
>
>     of assertions that do not hold for all forms of proof of stake.  E.g.,
>
>     will there be delegation like peercoin, randomization like algorand,
>
>     penalties like Casper, sleepy nodes like snowwhite?
>
>     And while of course I'm biased on this issue, I think that a
>
>     Byzantine-agreement-based approach like SCP
>
>     (https://datatracker.ietf.org/doc/draft-mazieres-dinrg-scp/) would work
>
>     better than PoS.  SCP is well matched to the Internet peering model,
>
>     which we already know is a workable decentralized governance model.  You
>
>     may not agree, but it would at least be nice for the document to explain
>
>     why you reject this approach.
>
>     David
>
>
>