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:
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 protected] on
behalf of [email protected]> wrote:
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?
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.
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?
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.
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.)
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.
“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.
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.
“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)
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
—Sandy
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
_______________________________________________
OPSEC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/opsec
