Subject: [Sidrops] blockchain for IP addresses draft update

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Fri, 29 Jun 2018 19:14:08 +0200

(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

-------- Missatge reenviat --------
Assumpte: 	New Version Notification for 
draft-paillisse-sidrops-blockchain-02.txt
Data: 	Fri, 29 Jun 2018 08:38:07 -0700
De: 	[email-masked]
A: 	Alberto Rodriguez-Natal <[email-masked]>, Vina Ermagan 
<[email-masked]>, Leo Vegoda <[email-masked]>, Albert Cabellos 
<[email-masked]>, Albert Cabellos-Aparicio <[email-masked]>, 
Jordi Paillisse <[email-masked]>, Fabio Maino <[email-masked]>

A new version of I-D, draft-paillisse-sidrops-blockchain-02.txt
has been successfully submitted by Jordi Paillisse and posted to the
IETF repository.

Name:		draft-paillisse-sidrops-blockchain
Revision:	02
Title:		An analysis of the applicability of blockchain to secure IP addresses allocation, delegation and bindings.
Document date:	2018-06-28
Group:		Individual Submission
Pages:		30
URL:            https://www.ietf.org/internet-drafts/draft-paillisse-sidrops-blockchain-02.txt
Status:         https://datatracker.ietf.org/doc/draft-paillisse-sidrops-blockchain/
Htmlized:       https://tools.ietf.org/html/draft-paillisse-sidrops-blockchain-02
Htmlized:       https://datatracker.ietf.org/doc/html/draft-paillisse-sidrops-blockchain
Diff:           https://www.ietf.org/rfcdiff?url2=draft-paillisse-sidrops-blockchain-02

Abstract:
    This document analyzes how blockchain technology can be used to
    secure the allocation, delegation and binding to topological
    information of the IP address space.  The main outcomes of the
    analysis are that blockchain is suitable in environments with
    multiple distrusting parties and that Proof of Stake is a potential
    candidate for a consensus algorithm.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: David Mazieres <[email-masked]>
Date: Mon, 02 Jul 2018 08:59:10 -0700

> Thanks to all of you for taking the time to read the draft :)

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

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Wed, 4 Jul 2018 13:28:11 +0200

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

---

From: "Roque Gagliano (rogaglia)" <[email-masked]>
Date: Wed, 4 Jul 2018 12:09:08 +0000

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 <[email-masked]> on behalf of Jordi Paillissé Vilanova <[email-masked]>
Date: Wednesday 4 July 2018 at 13:28
To: David Mazieres expires 2018-09-30 PDT <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, Stephane Bortzmeyer <[email-masked]>, "[email-masked]" <[email-masked]>, Greg Skinner <[email-masked]>, "[email-masked]" <[email-masked]>, "Alberto Rodriguez Natal (natal)" <[email-masked]>, "Vina Ermagan (vermagan)" <[email-masked]>, "Fabio Maino (fmaino)" <[email-masked]>, Albert Cabellos <[email-masked]>, "[email-masked]" <[email-masked]>
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

Jordi Paillissé Vilanova <[email-masked]><mailto:[email-masked]> writes:

Dear all,

Regards,

Jordi

David

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Wed, 4 Jul 2018 17:50:13 +0200

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 <[email-masked]> on behalf of Jordi Paillissé 
> Vilanova <[email-masked]>
> *Date: *Wednesday 4 July 2018 at 13:28
> *To: *David Mazieres expires 2018-09-30 PDT 
> <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, 
> Stephane Bortzmeyer <[email-masked]>, "[email-masked]" 
> <[email-masked]>, Greg Skinner <[email-masked]>, 
> "[email-masked]" <[email-masked]>, "Alberto Rodriguez Natal (natal)" 
> <[email-masked]>, "Vina Ermagan (vermagan)" <[email-masked]>, 
> "Fabio Maino (fmaino)" <[email-masked]>, Albert Cabellos 
> <[email-masked]>, "[email-masked]" <[email-masked]>
> *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
>
>     Jordi Paillissé Vilanova<[email-masked]> <mailto:[email-masked]>  writes:
>