Jordi Paillissé Vilanova

Could Blockchain Help in Interdomain Routing Security?

Jordi Paillissé Vilanova
Contributors: Alberto Rodríguez Natal, Vina Ermagan, Fabio Maino, Albert Cabellos

Blockchain technology is attracting a lot of attention among the security community since it provides a way to exchange information among a set of distrusting entities without the use of digital certificates and centralised control. Blockchain provides means for distrusting parties to reach consensus in a distributed way. Although the main application of blockchains are financial systems, their use in the field of networking is currently being explored (e.g., Blockstack or Namecoin).

In this article, we discuss if a blockchain could be used to securely record the allocation and delegation of IP addresses, and explore its advantages and drawbacks. Additional information can be found in this IETF draft or in this ArXiv technical report

Blockchain primer

Conceptually, a blockchain is a distributed, secure and trustless database. It can also be regarded as a state machine with rules that clearly state which transitions can be performed. Participants in the blockchain communicate through a P2P network. The smallest data unit of a blockchain is a transaction. Users attach data to a transaction along with its signature and their associated public key. Usually, the attached data is an asset or a token, something that is unique and should not be replicated (e.g. coins in Bitcoin). Then they broadcast this transaction to the other participants. The rest of the nodes in the network temporarily store this transaction. At some fixed intervals in time, one of the nodes takes a set of these transactions and groups them in a block. It then broadcasts this block back to the network. When the other nodes receive this block they verify it, remove the transactions contained in the block from the temporary storage and add it after the previous block, thus creating a chain of blocks. It should be noted that all nodes store the entire blockchain locally. In addition, most blockchains give some sort of reward to nodes that add new blocks, although this is not strictly necessary.

Two basic mechanisms are used to protect the chained data: a chain of signatures and a consensus algorithm. The consensus algorithm is the central part of any blockchain and it controls the chaining of data blocks. Its main role is to provide a set of well-defined rules so that participants agree on a consistent view of the database. For this it has the following main functions:

  • First, forks (multiple chains) can exist, this may happen for instance due to varying network latency among participants. In this case the participants must agree on which is the valid chain.
  • Second, it must determine which participants are allowed to add new data blocks.  

Applicability for IP addresses

IP addresses share some fundamental characteristics with the coins or assets found in any blockchain, such as uniqueness or divisibility. Taking advantage of this, we can devise a blockchain to exchange IP prefixes just like coins are transferred in Bitcoin. With a series of transactions we can mimic the current allocation hierarchy of IP addresses in the blockchain and build a consistent view of the legitimate holders of IP prefixes. This way, a Regional Internet Registry can record the allocation of IP addresses to its customers in the chain (steps 1 and 2 in Figure 1 below), and ISPs can specify who can advertise these addresses (steps 3 and 4).


Figure 1: Using blockchain for IP allocations


A consensus algorithm for IP addresses

The two most popular consensus algorithms are: Proof of Work (PoW) and Proof of Stake (PoS). In Proof of Work, nodes have to solve a complex mathematical problem to add a block, thus requiring some computational effort (commonly know as mining). Proof of Stake takes a different approach: participants with more assets (or stake) in the blockchain are more likely to add blocks. With this, the control of the chain is given to entities who own more stake. For each new block, a signer is selected randomly from the list of participants (1), typically weighted according to their stake (2). This is shown in Figure 2.

Figure 2: Proof of Stake algorithm

Taking this into account, Proof of Work does not appear to be suitable for the IP address use case. In PoW the capability to add new blocks and the security of the chain itself depend on the computing power of the participants. However, a participant with large computing power is not necessarily interested in the well-being of the blockchain. Depending on the objectives of an attacker, certain attacks can become profitable. Namely, buying a large quantity of hardware to be able to rewrite the blockchain with false data (e.g., incorrect delegations of IP addresses). This is because the incentives of the participants in a blockchain for IP addresses are not linked with their computing power.

In contrast, with Proof of Stake, the capability to alter the blockchain remains within it. This aspect is of particular importance in the context of securing IP addresses: it would mean that ASes holding large blocks of IP addresses are more likely to add blocks. These parties have a reduced incentive in tampering the blockchain because they would suffer the consequences: an insecure Internet. Typically ASes that hold large blocks of IP address space have their business within the Internet and as such, have clear incentives in the correct operation and security of the Internet.

Furthermore, in such blockchain the risk of takeover is reduced compared to PoW, the reason is that accumulating a large amount of IP addresses is typically more complex than accumulating computing power. The risk of takeover is also mitigated compared to other PoS-based blockchains. In this blockchain, an attacker would buy tokens from the other parties, who receive a monetary compensation to participate in the attack. However, in a blockchain for IP addresses, this would mean buying IP addresses from other parties who do not have a clear incentive to sell their blocks of addresses to the attacker. Because of this, PoS appears to be a firm candidate for a consensus algorithm in a blockchain for securing IP addresses allocations and delegations. 

Revocation: a special case for IP addresses

Due to the irreversible nature of transactions, once a block of IP addresses has been allocated to an entity it is not possible to modify or remove it, as opposed to CRLs (Certificate Revocation Lists). However, due to operational issues (compromised or lost keys, human mistake, holder misbehaviour, etc.,) it is critical to provide a way to recover a block of addresses. Moreover, since IP addresses are a finite public good they cannot be lost, in contrast to crypto-currencies: the loss of a coin only causes damage to its owner, not the entire community.

Taking into account that a blockchain can enforce any rules its participants agree upon, we can devise some simple revocation protocols, such as adding a timeout to the allocations or creating a special revocation transaction that can only be issued by the registries, among others. 

Despite these considerations, the revocation procedure must be discussed among the community to achieve consensus between the relevant players (IANA, RIRs, ISPs, institutions, etc), considering that behind any revocation mechanism there is a fundamental tradeoff between trusting an upstream provider of the addresses and retaining full control of the block of addresses.

Advantages and drawbacks

In this section we outline the pros and cons of such blockchain compared to traditional PKI infrastructures:


  • Decentralised: No central entity controls the blockchain, it is shared among all participants.
  • No digital certificates, Certification Authorities or CRLs are needed.
  • Simplified rekeying: A key rollover can easily be performed by issuing a new transaction allocating the prefixes to a new keypair controlled by the same holder. This process can be performed without involving any third party.
  • Censorship-resistant: since the control of a transaction is completely under the holder of the private key, the revocation of IP addresses without the legitimate holder's permission involves obtaining its private key. Even if the private key of the previous owner was compromised, ownership of the current transaction is still preserved, as opposed to the compromise of a CA's private key (or a misbehaving CA). As discussed previously, this situation is not always desirable in the context of IP addresses and special mechanisms are required to balance power between providers and customers.
  • Limited prior trust: It is not required to trust other nodes. However, in some PoS algorithms it is necessary to periodically authenticate the chain state out-of-band to prevent some attacks.
  • Simplified management: since CAs are not required, their management overhead is avoided.
  • Auditable: allocations and delegations can be tracked back in the blockchain to determine if they originate from the legitimate holder. 


  • PoS does not rely on strong cryptographic guarantees: As opposed to PKI-based systems that rely on strong and well-established cryptographic mechanisms, PoS-based infrastructures ultimately rely on the good behaviour of the high-stakers.
  • Costly bootstrapping: When a node is activated it has to download and verify the entire blockchain.
  • Large storage required: The blockchain grows forever as more blocks are added, blocks cannot be removed. 

Experimental results

We have built an open source prototype and made it publicly available on GitHub. We ran an experiment with nine blockchain nodes with the final objective of storing all the 260k IP prefixes allocated by the five Regional Internet Registries, respecting the IANA > Registry > Organisation hierarchy. As Figure 3 below shows, we wrote 150k prefixes in the chain, which required around one GB of storage. It took approximately seven hours to download and verify the entire chain.

Figure 3: Results of blockchain experiment



In this report, we have discussed how blockchain could store the allocation and delegation of IP prefixes and AS numbers. We have outlined its advantages over existing systems, such as simplified management or flexible trust models, and the benefits of a Proof of Stake consensus algorithm in this particular context. Finally, we have presented an early estimation of chain size and bootstrap time of such blockchain. However, several questions remain open, such as the balance of power between providers and customers, enforcement of RIPE’s policies, incentives for adoption or deployment cost.


Note that Jordi was a RACI fellow at RIPE 76 in Marseille. He presented this experiment in the Open Source working group session.

About the author

Jordi Paillissé Vilanova Based in Barcelona

Jordi Paillissé received his degree in Telecommunications Engineering (2013) from the Technical University of Catalonia (Spain). He has been a visiting student in École Polytechnique Fédérale de Lausanne (Switzerland). He is currently a PhD candidate in Computer Architecture at the Technical University of Catalonia. His main research interests are future Internet architectures, Software-Defined Networking and blockchain applications for the Internet.

Comments 0