Subject: [OPSEC] some questions about the blockchain draft presented at IETF 101

From: Sandra Murphy <[email-masked]>
Date: Wed, 21 Mar 2018 12:47:12 -0400

These questions were too long to ask the jabber scribe to relay.  At the scribe’s request, I summarized for the meeting, and promised a fuller version.  (Lucky you.)  And then question time was scraped.  Oh, well.

So here’s the full version.

Questions, then comments

Questions about some parts of the draft:

6.1.2.  Multi-signature transactions

   the holder of the block of
   addresses must trust the owners of the keys participating in the
   multi-signature transaction.

Since participants can generate their own keys, does this allow for sybil attacks - generating new “owners of the keys” in order to make a multi-signature succeed?

6.1.3.  Revocation transaction

   accepting the revocation
   transaction automatically when issued by the accepted authority

Does this re-introduce a centralized authority into the system?

Comments on certain statements made in the draft, and the relationship to IP address allocation and use:

“Cannot be assigned to two entities at the same time.”

The use of IP addresses shows shared authority over address space - more than one entity has authority over IP address space.  I’m not sure how that works in blockchain.

Example: If an ISP holding a /16 sub-delegates a /20 to a customer, it does not give up the ability to announce the /16.

Example: RIPE tells its members that they are responsible for their entire allocation, no matter if they have sub-delegated some of it to a customer.  And they carefully instruct their members how to use the authorization features of the RIPE database to ensure that they retain control over resources they have sub delegated.  And they have recently changed the authorization structure to make it possible to delete objects for resources that were sub-delegated out of resources they hold.  (Note: I’m not a part of the RIPE NCC.  RIPE NCC people present should speak up.)

“AS domains holding large blocks of IP addresses”

There are many organizations that hold IP addresses but do not hold AS numbers.  There are many organization that hold IP addresses and AS numbers, but have some other ISP originate announcements for them.  So an IP address to AS number mapping or vice versa is not possible or a fit to the way IP addresses are used.

“These parties have a reduced incentive in tampering the blockchain because they would suffer the consequences: an insecure Internet.”

I don’t see that this agrees with experience.  The Internet impact is sometimes deliberate (those who have deliberately impacted the routing of someone else’s prefix), sometimes a mistake (yesterday’s mis-origination of a Univ of Iowa’s prefix), and sometimes self-serving (spammers' mis-origination of prefixes for their own gain)

—Sandy

---

From: "Eric Vyncke (evyncke)" <[email-masked]>
Date: Mon, 26 Mar 2018 08:53:57 +0000

Adding Jordi to the recipients as he is not a Opsec mailing member AFAIK

-éric

On 21/03/18 17:47, "OPSEC on behalf of Sandra Murphy" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    Questions, then comments

    

    
       accepting the revocation

    

    

    

    
    —Sandy

    _______________________________________________
    OPSEC mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/opsec

---

From: Jordi Paillissé Vilanova <[email-masked]>
Date: Wed, 28 Mar 2018 21:14:28 +0200

Hi all,

Éric, thanks for adding me to the discussion.

Sandra, your comments are very welcome. Please find some responses inline.

Regards,

Jordi

El 26/03/18 a les 10:53, Eric Vyncke (evyncke) ha escrit:
> On 21/03/18 17:47, "OPSEC on behalf of Sandra Murphy"<[email-masked] on behalf of [email-masked]>  wrote:
>
Not exactly, only some keys are tied to the multi-signature transaction. 
If you generate a new key, it is not linked to it so you cannot affect 
its state. This section needs rewriting, I will update it shortly.
>      Does this re-introduce a centralized authority into the system?
I agree, this is exactly the tradeoff mentioned in sec. 6.1. An 
alternative approach could be this one:

 1. The registry issues a revocation transaction
 2. The holder of the prefix re-signs its prefix to prove it still holds
    its private key, and keeps the ownership of the prefix.
 3. If the prefix holder does not issue the aforementioned transaction
    in 24h, the registry recovers the prefix.

>      Example: RIPE tells its members that they are responsible for their entire allocation, no matter if they have sub-delegated some of it to a customer.  And they carefully instruct their members…
Thanks for the comment. I am not an expert in the mechanics of IP 
address allocations. However, since blockchains allow for complex 
management logic, this specificities can be integrated into them, 
typically in the code that validates new transactions.
>      There are many organizations that hold IP addresses but do not hold AS numbers.  There are many organization that hold IP addresses and AS numbers, but have some other ISP originate announceme…
The base unit in this blockchain are IP prefixes, so it's not a problem 
if you don't hold an AS number. In short, if you have more addresses you 
add more blocks. Again, I will clarify this in the draft.
>      I don’t see that this agrees with experience.  The Internet impact is sometimes deliberate (those who have deliberately impacted the routing of someone else’s prefix), sometimes a mistake (yes…
I see your point. Here we are making two assumptions. First, that a 
majority of the players are honest (typically consensus algorithms 
tolerate up to 1/3 of malicious players). Second, at present we are 
recording in the blockchain only the binding of IP prefix and AS no., 
but not BGP announcements, so we are not providing full BGP security. 
Does this make sense?

Thanks again for the comments!

Jordi