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.

Conclusions

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