Blockchain technology is receiving a lot of attention these days as a solution in numerous application domains. Triggered by research proposals and discussions in a variety of forums, we got together with a number of RIPE NCC employees to look at blockchain and its applicability to registration of Internet number resources. From our analysis we conclude that there are a number of issues that, at least for now, mean there is no benefit to using blockchain technology in the registry system.
An introduction to blockchain
Blockchain technology provides a public ledger, in essence, it is a transaction log that is shared in a peer-to-peer network. The type of transaction can, in theory, be anything. Most well known, of course, are the Bitcoin and other “crypto-currencies” where a token or part thereof can be exchanged in return for goods or services. But in theory it can be any transaction in which a public key is associated with a particular resource, e.g. it can also be used on an IP address prefix. The corresponding private key can then be used to initiate a transaction with that resource: the transfer of an IP prefix or ASN to another public key, or a statement about contact information related to an IP prefix or ASN, or route authorisations for an IP prefix. So, the resource itself is protected by proof of ownership of the private key.
The great innovation in blockchain technology is the way these transactions are processed and confirmed, which is based on a formal consensus model agreed to by the network of blockchain participants. This is a sharp contrast from the Internet Registry model and Public Key Infrastructure, where transactions are authenticated and confirmed by a central authority.
Different types of consensus models exist, such as Proof of Work or a Trusted Node model. A full and detailed explanation of each of these models would go too far for this article. What is important to know is that consensus models are designed to ensure that a) the distributed network agrees on transactions, and b) past transactions become engrained: they will always remain visible, and they cannot be modified.
It is the removal of the single authority that makes some people think about applying blockchain technology to Internet resources, whether it be IP addresses or DNS labels. The primary argument being that the consensus model would mitigate against the risk of capture of the authority, a risk that some people believe exists in the current model.
Issues applying blockchain to Internet number resources
Contact information and personal data related to resources
There is much more to Internet number resources than ensuring that a (single) authoritative holder exists. The RIPE Database provides publicly available contact information, such as organisation names and addresses, abuse handling mailboxes, and information on administrative and technical contacts.
In theory, such contact information could be brought into the blockchain as well. But this might conflict with data protection measures such as GDPR. Some of this data contains names and addresses of real people and there would be restrictions on such data such as the right to be forgotten. Or at least such data are removed when no longer needed. The immutable nature of the ledger when it concerns passed transactions might mean that the blockchain fails to comply with such restrictions.
One could devise a model in which the information in the ledger ties the holders to the resource while linking to an external database that provides the contact and other information. However, this would inevitably result in inconsistencies between these systems. Especially if the resource holder in the blockchain could be updated without updating the contact database simultaneously.
Operations and address policy
It has been previously assumed that IP addresses share a lot in common with crypto-currencies because addresses have a unique owner, address prefixes are divisible and addresses are transferable.
However, these assumptions do not always hold. IP addresses are not owned, but the right to use them is held. This may seem like a subtle difference, in most practical cases it is, but it does mean that there are restrictions on holdership coming from address policy set by the RIR community.
Sometimes live networks are transferred, which might mean that the receiving (new) holder already needs to make statements about resources, e.g. routing information, before the resource is formally transferred from the originating holder. Also, for instance in case of sub-allocations, some authority regarding the control of contact details or routing information might be transferred to another party, while the holdership of the resource remains with the original holder.
IP addresses are also not always transferable, for instance the current RIPE policy introduces a 24-month restriction on subsequent transfers upon receiving a prefix via allocation or transfer.
Finally, in rare occasions, the address policy and service agreements allow for resources to be reclaimed from holders and be returned to the pool of available resources.
Use of smart contracts
Some blockchains use the concept of ‘smart contracts’ that allow arbitrary data and logic to be embedded in the Blockchain. Ethereum is a blockchain implementation that, in addition to being a crypto-currency, provides a generic blockchain platform that supports such smart contracts that can be extended to implement new types of blockchains. Such contracts could be used to set limits on resource transactions, in accordance with address policy, unfortunately this is not without problems and risks.
By definition, these contracts are unmodifiable. There are two main issues with this: the rules are complex and the risk of introducing human error in implementation is a realistic one. In the case of Ethereum, this has led to at least one serious issue where over USD 30m was stolen; and once published, the rules can no longer be changed.
The latter means that address policy, once committed to in a smart contract, can no longer be changed or adapted by the community. Not even when market circumstances or operational requirements change that would warrant such a change.
Key loss or roll over
Unless the blockchain contains information regarding the organisation holding the resource (despite the issues around personal data), a key roll operation within a single holder organisation will be indistinguishable from a transfer to another organisation.
Currently, such transactions are processed and administered by an RIR staff member, who can make the assessment to what rules to apply, for instance whether or not to set the 24-month moratorium on further transfers of the resource. The question remains about whether the code of the smart contract could make such subtle distinctions or what the impact would be if it couldn't.
Secondly, in a blockchain, when one loses the private key, one loses the ability to make any updates to the resources protected by that key. This is especially problematic for Internet number resources. To some extent, such resources can be considered lost and no longer usable by the holder.
Having to renumber a network is a costly and time-consuming operation and whilst this is underway, the inability to make changes to or statements about the old resources might introduce further operational problems.
And that is assuming that replacement resources would be available immediately and at little costs. This might be the case for IPv6, but IPv4 addresses are scarce and hard to come by. Losing access to an IPv4 prefix range would not only have a negative impact to the original holder, but unless over time recovered to the free pool, could also be regarded as having a negative impact on the Internet community at large as it further reduces the number of available addresses.
Reclamation of unused addresses, for instance when a holder goes out of business, is a challenge by itself. Policy says such resources should be returned and become available again after a cool-down period. It is unclear how a blockchain could support such a mechanism in a reliable and accountable fashion. Some people have suggested this could be solved by the smart contract, but in such case there would be a significant time-out period involved or the burden to renew the registration might become too high.
There are ways to mitigate against some of these issues by storing a set of backup keys in a friendly place, for example, but there is no strict guarantee. Alternatively, the RIRs could remain authoritative, so that they could re-delegate resources to a new key held by the resource holder. However, introducing this hierarchy in the blockchain would defeat one of the primary motivations to safeguard the system against capture.
Risk of capture
The introduction of a consensus model could protect the system against capture of single authority, but that does not mean a blockchain itself is completely immune to capture. Several scenarios have been described in which a single entity could exert control over a blockchain. In the simplest model this would imply gaining control of a 50% +1 majority, for instance by quickly spawning a large quantity of client nodes that participate in the consensus making.
But recent research has also revealed more sophisticated attacks based on routing manipulation, that could split the blockchain and isolate nodes from taking part in the consensus making process. This is particularly interesting in a case where the information contained in the blockchain is expected to enable networks to protect themselves against such manipulation attacks.
Complexity in deployment
The RIR system and whois-based RIR databases have been in use for decades and many networks rely on the information provided from these systems for their day-to-day operations. Apart from the time it would take to develop, test and deploy a blockchain based alternative, the Internet industry cannot be expected to change to this new system overnight on a so-called flag day.
Parallel use of the old legacy APIs and databases would be needed, where whois and alternatives such as the RDAP and the RPKI would have to be modified to make the information in the blockchain available for backwards compatibility, at least for some period. But such a system would also mean that users would once again become reliant on the single authority of the entity controlling these legacy interfaces, with the same vulnerabilities the blockchain aims to remove.
Also, depending on the exact model, the amount of free available resources currently under the control of the RIRs could mean that the RIRs would also have a majority stake in the consensus model. This de-facto would mean that one-sided updates could still be made.
On the surface, blockchain has some very appealing aspects: it provides a distributed, verifiable and complete audit of information regarding events that happened. This helps resilience, because everyone has a copy, and provides resistance against capture: there is no central authority who can change things, and history is always preserved.
However, when applied to Internet number resources, we see issues around personal data that cannot be deleted, restrictions coming from address policy, key loss, and complexity in deployment.
Furthermore, we have not observed any large-scale outages or significant attempts to manipulate registration data via capture to date. Therefore, we conclude that, for the time being, these issues do not outweigh the perceived benefits of blockchain technology.
update 28/8/2018: fixed a typo
Comments are disabled on articles published more than a year ago. If you'd like to inform us of any issues, please reach out to us via the contact form here.
Valentino Di Donato •
Thanks for the article. Do you have any link to the research proposals you refer to in the abstract?
Hide one reply
Marco Hogewoning •
One of the research groups recently published on https://arxiv.org/abs/1807.10528, but I've also seen preliminary work in ITU-T regarding strengthening interdomain routing with blockchain solutions.
Stéphane Bortzmeyer •
Saying that automatic contracts ("smart contracts" is the marketing BS) cannot be changed ("these contracts are unmodifiable") is not strictly true. To quote an old saying "every problem in computer science can be solved with one more indirection". So, you can have a pointer to the current version of the code of the smart contract, and changing the code by adding a new version of the pointer. Of course, this adds complexities and security risks but it shows that there are ways to modify automatic contracts, for instance to follow a change in policies. The description of the "51 % attack" is very sketchy ("quickly spawning a large quantity of client nodes that participate in the consensus making"). In a real blockchain, techniques like proof-of-work and proof-of-stake prevent this trivial Sybil attack. But there is a subtler reason why the "51 % attack" is overhyped: it is easily detectable (the Bitcoin Core code, for instance, logs it). So, honest miners will see it. It will not be easy to recover from the attack (the honest miners will have to fork) but it cannot be stealthy.
Hide 2 replies
Marco Hogewoning •
Hey Stéphane, As the text suggests, for many issues a work around might be available. The key point is that while a work around (in theory) might exist, the question is whether such a work around would actually still deliver on the promise and the additional complexity would be worth it. As for the 50%+1, it was mostly for illustration, as you rightfully point out that is the most simple attack and it is relatively easy to detect. However, as you also note, the fact that you can easily detect it does not automatically imply a roll back of the offending transaction is easy as well. I am sure we haven't covered every possible attack or remedy, but in discussing whether blockchain is a suitable addition to the registry system, we should certainly take a very good look at all the attack vectors and the numerous examples that are around where such attacks have been successfully executed against a blockchain.
alain durand •
There are many ways to mount a 51% attack. They all come from the fact that trusting a blockchain is akin to trusting the result of an election when you don't know who the voters are nor how many they are... Some carefully crafted denial of service attack followed by a graduated release of miners could leave the chain very vulnerable to a 51% attack using a relatively limited number of "partisan" miners... Of course such an attack will be detected, but it is not clear if it can be easily rolled back. It has also the potential to force a fork in the blockchain, as we now have seen several times in various cryptocurrency chains. Such. fork would certainly not be a good news for the stability of the internet...