Network Working Group J. Paillisse
Internet-Draft UPC-BarcelonaTech
Intended status: Informational A. Rodriguez-Natal
Expires: May 2, 2018 V. Ermagan
F. Maino
Cisco Systems
A. Cabellos
UPC-BarcelonaTech
October 29, 2017
An analysis of the applicability of blockchain to secure IP addresses
allocation, delegation and bindings.
draft-paillisse-sidrops-blockchain-01.txt
Abstract
This document analyzes how blockchain technology can be used to
secure the allocation, delegation and binding to topological
information of the IP address space. The main outcomes of the
analysis are that blockchain is suitable in environments with
multiple distrusting parties and that Proof of Stake is a potential
candidate for a consensus algorithm.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2018.
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
Paillisse, et al. Expires May 2, 2018 [Page 1]
Internet-Draft Blockchain for IP addresses October 2017
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
3. Blockchain in a nutshell . . . . . . . . . . . . . . . . . . 3
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1.1. Chain of signatures . . . . . . . . . . . . . . . . . 4
3.1.2. Consensus algorithm . . . . . . . . . . . . . . . . . 5
3.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. Description of consensus algorithms . . . . . . . . . . . 6
3.3.1. Proof of Work (PoW) . . . . . . . . . . . . . . . . . 6
3.3.2. Proof of Stake (PoS) . . . . . . . . . . . . . . . . 7
4. Blockchain for IP addresses . . . . . . . . . . . . . . . . . 8
4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 8
4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. A consensus algorithm for IP addresses . . . . . . . . . 9
5. Overview of the architecture . . . . . . . . . . . . . . . . 10
5.1. Pros and cons . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Security evaluation . . . . . . . . . . . . . . . . . . . 14
5.2.1. Attacks against a PoS-based consensus algorithm . . . 14
5.2.2. Attacks against the P2P network . . . . . . . . . . . 16
6. Other Considerations . . . . . . . . . . . . . . . . . . . . 17
6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17
6.1.1. Expiration time . . . . . . . . . . . . . . . . . . . 18
6.1.2. Multi-signature transactions . . . . . . . . . . . . 18
6.1.3. Revocation transaction . . . . . . . . . . . . . . . 18
6.1.4. Out-of-band mechanisms . . . . . . . . . . . . . . . 19
6.2. Storage management . . . . . . . . . . . . . . . . . . . 19
6.3. Proof of Networking? . . . . . . . . . . . . . . . . . . 20
6.4. Configuration parameters . . . . . . . . . . . . . . . . 21
7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
10. Informative References . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Paillisse, et al. Expires May 2, 2018 [Page 2]
Internet-Draft Blockchain for IP addresses October 2017
1. Introduction
Blockchain [Bitcoin] is attracting a lot of attention among the
security community since it provides means for exchanging information
among a set of distrusting entities without the use of digital
certificates and centralized control. Blockchain provides means for
the distrusting parties to reach consensus in a distributed way.
Formally, it is regarded as a new solution to the Byzantine Generals
problem, well-known in fault-tolerant distributed systems.
Although at the time of this writing the main application of
blockchain are financial systems, their use in the field of
networking is being explored (e.g., [Hari2016]). Some successful
systems exist such as [Blockstack] and [Namecoin], which aim at
building a secure DNS.
The main goal of this document is to represent a first step towards
the understanding of the properties of blockchains and their
applicability in the Internet infrastructure, specifically securing
the allocation, delegation and bindings of IP addresses. First, it
introduces blockchain, then it analyzes how blockchain could be used
to secure the delegation of IP addresses. Finally, it presents an
initial design for such an infrastructure. This document also
includes a preliminary security analysis of such system. It is
important to note that the goal of this document is not to provide a
complete architecture that secures IP address allocation, delegation
and bindings.
2. Definition of Terms
TBC
3. Blockchain in a nutshell
3.1. Overview
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 store temporarily 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
Paillisse, et al. Expires May 2, 2018 [Page 3]
Internet-Draft Blockchain for IP addresses October 2017
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. Figure 1 presents an overview of the most
common elements in a block.
+--------+---------------+----------------+---------------+
| Block | Hash(Previous | Hash(All Block | Block Creator |
| Number | Block) | Transactions) | Signature |
+--------+---------------+----------------+---------------+
| Transaction 1 |
+---------------------------------------------------------+
| Transaction 2 |
+---------------------------------------------------------+
+ ... +
+ ... +
+---------------------------------------------------------+
| Transaction N |
+---------------------------------------------------------+
Figure 1.- Common structure of a block
Two basic mechanisms are used to protect the chained data: a chain of
signatures and a consensus algorithm.
3.1.1. Chain of signatures
The chain of signatures operates at transaction level. Consider the
sender and receiver of a token, each with its public-private keypair.
To change the owner of a token, the sender signs the data and the
receiver's public key. It then puts together its public key, the
signature, the data and the hash of the receiver's public key
(Figure 2) to form a transaction.
Paillisse, et al. Expires May 2, 2018 [Page 4]
Internet-Draft Blockchain for IP addresses October 2017
+-------------+-------------------+--------+---------------+
| Sender | Signature Sender | Data | Hash(Receiver |
| Public Key | Private Key | | Public Key) |
+-------------+-------------------+--------+---------------+
Figure 2.- Common transaction structure in a blockchain
In conclusion, the rules of the blockchain enforce that:
o The owner of the receiver private key has total control over the
contents of the transaction. In Bitcoin this translates in a
central property: only this owner can spend a coin.
o When an owner sends a token to the new owner, it irreversibly
transfers the control of the contents to the new owner.
3.1.2. Consensus algorithm
The consensus algorithm is the central part of blockchain and it
controls the chaining of data blocks. The main role of the algorithm
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. And second, another important function of the
consensus algorithm is to determine which participants are allowed to
add a new data blocks. Section 3.3 contains more information
regarding available consensus algorithms.
It is important to note that regardless of the consensus algorithm,
in blockchain data blocks are always added, never deleted nor
modified. This creates a tamper-proof, shared ledger among all
participants. Transactions can be tracked back by inspecting past
blocks, thus enabling the verification of claims by certain parties.
3.2. Features
The following list tries to briefly summarize the main
characteristics of the blockchain technology:
Decentralized: No central entity controls the blockchain, it is
shared among all participants.
No CAs: No digital certificates, Certification Authorities or CRLs
are needed.
Paillisse, et al. Expires May 2, 2018 [Page 5]
Internet-Draft Blockchain for IP addresses October 2017
Limited prior trust: It is not required to trust other nodes. It is
worth noting that some consensus algorithms rely on some limited
levels of trust.
Tamper-proof: Since data can be only added but never modified,
attempts to alter previous records are detected.
Non-repudiation: All nodes share a common, immutable view on the
status of the blockchain, and blockchain provides non-repudiation
mechanisms.
Censorship-resistant: Gaining control over a transaction involves
having access to the associated private key.
Append-only: Data is always added, but never modified nor deleted.
Privacy: Entities participating in the blockchain can achieve
privacy using anonymous keys, i.e. randomly-generated keys not
related to their identity. In addition, a new keypair should be
generated for each new transaction in order to prevent tracking
[Bitcoin], section 10.
Slow updates: New transactions have to be verified, added to a block
and received by all nodes. This results in a delay since the
transaction is created until it is finally available to all the
nodes. This delay will depend on the consensus algorithm and the
block creation rate.
Large storage: The size of the blockchain keeps growing forever,
because data blocks are always added. This may result in
scalability issues.
3.3. Description of consensus algorithms
The two more popular consensus algorithms are: Proof of Work and
Proof of Stake.
3.3.1. Proof of Work (PoW)
In Proof of Work nodes have to solve a complex mathematical problem
to add a block, thus requiring some computational effort, this is
commonly know as mining. For example in Bitcoin the problem is to
find a hash starting with a fixed amount of zeroes, the only known
way to solve this problem is by brute force. The valid chain is the
one with most accumulated computing power, this chain is also the
more expensive in terms of computing power to modify. This is
because modifying a block going N blocks back from the tip of the
chain would require redoing the computations for all these N blocks.
Paillisse, et al. Expires May 2, 2018 [Page 6]
Internet-Draft Blockchain for IP addresses October 2017
As a result, an attacker should have more computational power than
the power required to create the N blocks to be able to modify the
chain. Overall, it is commonly assumed that if more than half of the
nodes are honest the blockchain is considered as secure.
PoW offers relevant features, adding new blocks requires an external
resource (CPU power) that has an economical cost. However this also
results in some relevant drawbacks:
Risk of overtaking: The security of PoW is entirely based on
computation power. This means that if an entity has access to
more than half of the total blockchain's computing power it can
control the chain. As a result and in order to keep blockchain
secure, the incentive of taking control of the chain must be lower
than the cost of acquiring and operating the hardware that
provides the equivalent to half of the participants computing
power. This is hard to guarantee since the economy of the
blockchain and the economy of the required hardware are
independent. As an example an attacker can acquire the required
hardware and operate it, take control of the blockchain to obtain
an economical benefit and finally sell the hardware to reduce the
final cost of the attack.
Hardware dependency: Bitcoin automatically increases -over time- the
complexity of the mathematical problem that needs to be solved in
order to add a block. This is done to account for Moore's law.
As a result the community has designed mining specific hardware
(ASICs) that provides a competitive advantage. In this context
blockchain becomes less democratic, since the cost of
participating in it increases.
Energy inefficiency: PoW requires large amounts of energy to perform
the computations (e.g., [miningfarm]).
3.3.2. Proof of Stake (PoS)
The main idea behind Proof of Stake is that 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 typically weighted according to their stake. A
fundamental assumption behind PoS is that such entities have more
incentives for honest behaviour since they have more assets in the
chain.
Proof of Stake is seen as an alternative to PoW. At the time of this
writing major players in the blockchain environment such as
[Ethereum] are preparing a shift towards PoS, moreover several
Paillisse, et al. Expires May 2, 2018 [Page 7]
Internet-Draft Blockchain for IP addresses October 2017
blockchains based on PoS already exist (eg. [Peercoin]). The main
reason behind this paradigm shift is that PoS addresses some of PoW's
main drawbacks:
o It does not require special hardware nor computationally or
energy-expensive calculations.
o An attacker must get hold of a significant part of the assets in
order to gain control of the blockchain. As opposed to PoS the
investment required to gain control of the chain lies within the
chain, and does not involve using external resources.
On the other side, Proof of Stake introduces new sources of attacks:
o In Proof of Stake the signer is selected randomly among the
stakers. In this context attackers can manipulate the source of
randomness to sign more blocks and ultimately gain control over
the chain.
o As opposed to PoW, creating forks is very inexpensive, since no
computational power is required. The PoS must provide means to
select the valid chain, which is typically the longer one.
o Collusions of high-stakers can create alternate chains which can
appear to be valid.
4. Blockchain for IP addresses
4.1. Problem statement
The objective of this section is to analyze if an infrastructure
using blockchain can provide a similar degree of security to
traditional PKI-based architectures. Specifically we aim to secure:
o Binding of IP address blocks to the holder (private key holder).
o The allocations and delegations of IP address blocks among their
holders.
o Binding of IP address blocks to their topological locators (eg.
AS numbers allocations).
This information is public and shared among a set of distrusting
entities over the Internet. The architecture must be able to:
o Allow anyone to verify the legitimate holder of a block of
addresses
Paillisse, et al. Expires May 2, 2018 [Page 8]
Internet-Draft Blockchain for IP addresses October 2017
o Let participating entities allocate address blocks without
requiring a trusted third party.
o Restrict the allocation of a block of addresses to only its
legitimate holder.
o Prevent data modification without the consent of its holder.
4.2. Analysis
The main rationale behind using blockchain to secure IP address
allocations is that IPs can be understood as coins, both concepts
share some fundamental characteristics:
o They are unambiguously allocated to entities.
o Can be transferred between them.
o Cannot be assigned to two entities at the same time.
o Can be divided up to a certain limit.
Such similar properties make it possible to envisage a blockchain
that allows its participants delegate IP address blocks, similarly to
how Bitcoin transfers coins. For example, IANA could write a
transaction allocating addresses to the RIRs, which in turn could
allocate them to the LIRs, etc. Complex management logic can be
defined as needed for example, rejecting a transaction that allocates
of a block of addresses originated by an entity that does not hold
that block. In addition, transactions accept multiple inputs and
outputs, i.e. an arbitrary amount of public keys either as senders or
receivers. This means that it is possible to break and merge blocks
of addresses as required. Section 5 provides more detailed
information about this architecture.
4.3. A consensus algorithm for IP addresses
As stated before, the consensus algorithm is a central part of a
blockchain. The first consensus algorithm designed for blockchain
was PoW, and it is a common choice for new blockchain
implementations. However it presents several drawbacks
(Section 3.3.1) for the IP address scenario.
Using computing power as a means to secure blockchains has been
proved to work in financial environments. However, the capability to
add new blocks and the security of the chain itself depends on the
computing power of the participants, which is not always aligned with
their interest in the well-being of the blockchain. Depending on the
Paillisse, et al. Expires May 2, 2018 [Page 9]
Internet-Draft Blockchain for IP addresses October 2017
objectives of the 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 of
the IP addresses blockchain 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 AS domains 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.
5. Overview of the architecture
This architecture mimics the hierarchy of IP address allocation
present in today's Internet, with IANA on top of it. All nodes trust
IANA's public key, which writes a genesis transaction assigning all
of the address space to itself (figure 3).
+--------------+-----------------+-----------+----------------+
| IANA | Signature IANA | Allocate | Hash(IANA |
| Public Key 1 | Private Key 1 | 0/0 | Public Key 2) |
+--------------+-----------------+-----------+----------------+
Figure 3.- Genesis transaction
Paillisse, et al. Expires May 2, 2018 [Page 10]
Internet-Draft Blockchain for IP addresses October 2017
It then begins allocating each block of addresses to the IP address
holders. Each transaction allocates part of the address space to the
legitimate holder, and the rest of space is given back to IANA using
a new keypair (figure 4).
+--------------+-----------------+-----------+----------------+
| | | Rest of | Hash(IANA |
| IANA | Signature IANA | space | Public Key 3) |
| Public Key 2 | Private Key 2 +-----------+----------------+
| | | Allocate | Hash(APNIC |
| | | 1/8 | Public Key 1) |
+--------------+-----------------+-----------+----------------+
Figure 4.- Example allocation transaction
In turn, all the parties in the hierarchy allocate or delegate
address blocks following the current allocation hierarchy. When a
party wants to verify the allocation of a block of addresses, it
downloads the blockchain and verifies all the blocks and transactions
up to the genesis block, for which it has trust. Figure 5 presents
an example of allocation of one prefix to each of the RIRs.
Paillisse, et al. Expires May 2, 2018 [Page 11]
Internet-Draft Blockchain for IP addresses October 2017
+--------------+-----------------+-----------+----------------+
| | | Rest of | Hash(IANA |
| | | space | Public Key 4) |
| | +-----------+----------------+
| | | Allocate | Hash(RIPE |
| | | 5/8 | Public Key 1) |
| | +-----------+----------------+
| | | Allocate | Hash(APNIC |
| IANA | Signature IANA | 14/8 | Public Key 2) |
| Public Key 3 | Private Key 3 +-----------+----------------+
| | | Allocate | Hash(ARIN |
| | | 23/8 | Public Key 1) |
| | +-----------+----------------+
| | | Allocate | Hash(AFRINIC |
| | | 102/8 | Public Key 1) |
| | +-----------+----------------+
| | | Allocate | Hash(LACNIC |
| | | 200/8 | Public Key 1) |
+--------------+-----------------+-----------+----------------+
Figure 5.- Example multi-output allocation transaction
Inside the blockchain the typical operations to manage blocks of IP
addresses can be defined, such as the delegation of prefixes (figure
6). This helps to enforce the rules of IP addresses management. For
instance, since this transaction is marked as a delegation, if the
new owner created an allocation transaction it would be rejected by
the other nodes, because the parent transaction does not have the
privileges to perform it.
+--------------+-----------------+-----------+----------------+
| | | Rest of | Hash(APNIC |
| APNIC | Signature APNIC | space | Public Key 3) |
| Public Key 1 | Private Key 1 +-----------+----------------+
| | | Delegate | Hash(ISP A |
| | | 1.2/16 | Public Key 1) |
+--------------+-----------------+-----------+----------------+
Figure 6.- Example delegation transaction
Performing a key rollover is simple, because each transaction has its
associated public key, and only depends on the previous transaction.
In other words, rekeying means changing the public key only in the
Paillisse, et al. Expires May 2, 2018 [Page 12]
Internet-Draft Blockchain for IP addresses October 2017
holder's transaction. This can be done adding a new transaction with
the same data but transferring it to a new public key also controlled
by the initial holder (figure 7). This approach lets each entity
decide its rekeying policies independently.
+--------------+-----------------+-----------+----------------+
| ISP A | Signature ISP A | Delegate | Hash(ISP A |
| Public Key 1 | Private Key 1 | 1.2/16 | Public Key 2) |
+--------------+-----------------+-----------+----------------+
Figure 7.- Example key rollover of a prefix delegation
It is worth noting that this chain can define as many operations as
required, for instance storing the binding of AS numbers to the IP
prefixes they announce (figure 8).
+--------------+-----------------+-----------+----------------+
| | Signature | Bind | |
| ISP A | ISP A | 1.2/16 | Hash(ISP A |
| Public Key 2 | Private Key 2 | AS no. | Public Key 3) |
| | | 12345 | |
+--------------+-----------------+-----------+----------------+
Figure 8.- Example binding of AS number to prefix
Additional and more complex operations can be defined if the
management logic requires it. For instance, several signatures (from
different parties) can be required to consider a transaction valid,
etc.
5.1. Pros and cons
In this section we analyze the pros and cons of this architecture
compared to traditional PKI infraestructures:
Advantages:
o Decentralized: No central entity controls the blockchain, it is
shared among all participants.
o No CAs, CRLs or certificates needed: No digital certificates,
Certification Authorities or CRLs are needed.
Paillisse, et al. Expires May 2, 2018 [Page 13]
Internet-Draft Blockchain for IP addresses October 2017
o 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.
o 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).
o Limited prior trust: It is not required to trust other nodes.
However, in PoS it is necessary to periodically authenticate the
chain state out-of-band to prevent some attacks.
o Simplified management: since CAs are not required, their
management overhead is avoided.
o Auditable: allocations and delegations can be tracked back in the
blockchain to determine if they originate from the legitimate
holder.
Drawbacks:
o 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 infraestructures ultimately
rely on the good behaviour of the high-stakers.
o Costly bootstrapping: When a node is activated it has to download
and verify the entire blockchain.
o Large storage required: The blockchain grows forever as more
blocks are added, blocks cannot be removed.
5.2. Security evaluation
5.2.1. Attacks against a PoS-based consensus algorithm
This section presents a list of the most relevant attacks against a
Proof of Stake algorithm and how to mitigate them.
Paillisse, et al. Expires May 2, 2018 [Page 14]
Internet-Draft Blockchain for IP addresses October 2017
5.2.1.1. Stake grinding
Stake grinding refers to the manipulation of the consensus algorithm
in order to progressively obtain more stake, with the goal of signing
blocks more frequently with the ultimate goal of taking control of
the blockchain. It proceeds as follows: when the attacker has to
sign a block, it computes all the possible blocks (varying the data
inside them) to find a combination that gives the highest possibility
of signing another block in the future. It then signs this block and
sends it to the network. This procedure is repeated for all the next
signing opportunities. Over time, the attacker will sign more and
more blocks until the consensus algorithm will always select the
attacker to sign all blocks, thereby having taken control of the
blockchain.
To prevent this attack, the source of randomness used to select the
signers has to be hard to alter or to predict.
5.2.1.2. Nothing at stake
Nothing at stake is one of the fundamental drawbacks of Proof of
Stake and requires careful design based on the incentives of the
participants. In common PoS designs, the signers of the new block
receive an economical incentive (e.g., Ethereum). However this does
not hold in the IP address scenario, since participants should not
receive any incentive. The incentive is, as stated before, achieving
a consistent view of the IP address space and having a secure
Internet.
5.2.1.3. Range attacks
A range attack is performed by creating a fork some blocks back from
the tip of the chain. It is conceptually similar to the attack named
as 'Risk of overtaking' in Section 3.3.1. In this scenario, the
attacker has privately fabricated a chain which (according to the
consensus algorithm rules) will be selected over the original one.
Benefits of this attack include gaining more stake on the blockchain
(this attack could be part of a stake grinding attack) or rewriting
the transaction history to erase a payment made in the original
blockchain.
The simplest solution to this attack is adding a revert limit to the
blockchain, forbidding forks going back more than N blocks. This
provides a means to solidify the blockchain. However, nodes that
have been offline for more than N blocks will need an external source
that indicates the correct chain. It has been proposed to do this
out of band. This is why a PoS blockchain is not purely trustless
and requires a small amount of trust.
Paillisse, et al. Expires May 2, 2018 [Page 15]
Internet-Draft Blockchain for IP addresses October 2017
5.2.1.4. Lack of participation
Participants in a PoS algorithm will not always sign a block, since
they might be offline when they are selected or lack incentives.
Because of this, the final fraction of high-stakers that sign blocks
can be very different from the full set of high-stakers. The direct
consequence of this situation is that the portion of participants
that decide what goes into the blockchain can be a small set of
nodes. If this participation is low enough, it can leave the control
of the blockchain to a small amount of people/oligarchy, thus rising
security concerns.
5.2.2. Attacks against the P2P network
This section presents attacks directed towards the underlying P2P
network used to exchange information among the participants of the
blockchain.
5.2.2.1. DDOS attacks
Since blockchains are inherently based on P2P architectures, they
present a higher degree of resistance to DDOS attacks than
centralized server architectures, provided that the network has a
significant number of participants. In addition, it is always
possible to keep an offline copy of the blockchain.
5.2.2.2. Transaction flooding
A special type of DDOS attack consists in creating a large amount of
legit transactions that transfer a small amount of tokens (i.e.
delegate a lot of small IP prefixes). If the number of transactions
is large enough, the addition of new transactions can be
significantly delayed because not all of them fit into a single
block. The effectiveness of the attack also depends on the
throughput of the blockchain (transactions/second). Simple solutions
may be to limit the granularity upon which IP addresses can be split.
Of course, only the legitimate holder of a large amount of IP address
can perform this attack.
5.2.2.3. Routing attacks
The underlying P2P network in blockchains does not typically use any
security mechanism, e.g. node authentication or integrity of network
protocol messages. This enables potentially disruptive attacks. For
example, specially located rogue nodes could drop new transactions,
which would block updates on the blockchain and leave legit nodes
uncommunicated. The effectiveness of this kind of attacks depends on
Paillisse, et al. Expires May 2, 2018 [Page 16]
Internet-Draft Blockchain for IP addresses October 2017
how the P2P algorithm selects peers and the topology of the P2P
network.
However, the most potentially dangerous attack of this type are
network partitions, i.e. isolating a group of nodes from the rest of
the network so they cannot communicate each other (e.g.,
[Apostolaki2017]). The consequence of this attack is that two
versions of the blockchain are created, one at each network
partition. When the partition disappears and the nodes reconnect one
of the two chains will be discarded, causing a service disruption.
It is worth noting that Bitcoin has suffered similar attacks
[realrouteattack].
5.2.2.4. Transaction censorship
When a node adds a block it chooses arbitrarily which transactions
are added into it, i.e. no specific rules control how transactions
are added to a block. This enables a node to selectively add some
transactions and intentionally exclude others, with the consequence
that some transactions may be never added to the blockchain. In the
context of IP addresses, this may be performed by a competing ISP to
prevent another ISP from executing a certain modification. Possible
solutions revolve around:
o Giving more priority to older transactions (similarly to Bitcoin).
o Punishing nodes that exhibit this kind of behaviour, e.g. removing
part of their block of IP addresses or lowering their chance of
adding blocks.
6. Other Considerations
6.1. Revocation
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. Taking into
account that a blockchain can enforce any rules its participants
agree upon, this section presents some possible approaches to
implement revocation, such approaches should not be considered as
mutually exclusive. The revocation procedure must be discussed among
the community to achieve consensus between the relevant players
(IANA, RIRs, ISPs, institutions, etc).
Paillisse, et al. Expires May 2, 2018 [Page 17]
Internet-Draft Blockchain for IP addresses October 2017
All these mechanisms present different balances of power between the
current holder and the entity whose asset is being revoked. Behind
all these mechanisms there is a fundamental tradeoff between trusting
an upstream provider of the addresses and retaining full control of
the block of addresses.
Regardless of the revocation policy and as opposed to traditional PKI
systems, each IP prefix delegation only depends on the private key of
the holder of such IP block. As such, it does not need to trust a CA
or a chain of certificates. Only by means of this private key the IP
delegation can be altered.
6.1.1. Expiration time
A simple approach to allow revocation is adding a lease time (i.e,
time-to-live) to the blocks of addresses. After the lease ends, the
new holder of the address block automatically becomes the previous
one, or addresses are transferred to a default holder. As stated
before, this revocation procedure should be enforced by the rules of
the blockchain, this means that participants would not recognise
expired allocations as valid.
6.1.2. Multi-signature transactions
A multi-signature transaction is a transaction that admits more than
one authorized signer. In other words, a transaction is considered
valid if it has, for instance, 2 out of 5 valid signatures. This
way, 3 keys can be lost but with the renaming 2 keys the block of
addresses can be recovered. This approach exemplifies the
aforementioned tradeoff in trust, since the holder of the block of
addresses must trust the owners of the keys participating in the
multi-signature transaction.
6.1.3. Revocation transaction
A simpler approach than multi-signature transactions is creating a
'revocation' transaction. When a block of address is required to be
reassigned without the consent of the current holder, a revocation
transaction (specifying the new holder) is inserted in the
blockchain. This transaction should be issued either by a
consensuated authority or by a disputing entity. The revocation
transaction should be resolved by either accepting the revocation
transaction automatically when issued by the accepted authority or by
means of out-of-band mechanisms when issued by a disputing party.
Paillisse, et al. Expires May 2, 2018 [Page 18]
Internet-Draft Blockchain for IP addresses October 2017
6.1.4. Out-of-band mechanisms
Disputes regarding transactions can be resolved by means of out-of-
band mechanisms, e.g, discussion, court, etc. In order to reflect
the decision of this out-of-band mechanism the blockchain must be
modified. Since this represents a deviation from the rules, it must
be done through a hard blockchain fork. Although cumbersome and
complex, this is feasible from a technical standpoint.
6.2. Storage management
The never ending size of the blockchain presents a potential
scalability issue. At the time of this writing, mature blockchains
like Bitcoin require more than 100 GB of storage. Simply deleting or
summarizing old transactions degrades the security of PoW-based
chains, since their security relies on the computing power required
to generate them. The longer they are, the harder they are to
attack.
However, PoS-based chains do not rely on computing power and hence,
space-saving strategies do not degrade the security. For instance a
simple solution could be to, once the PoS-based chain reaches a
certain storage size, summarize a subset of the older transactions.
In what follows we overview this strategy:
Paillisse, et al. Expires May 2, 2018 [Page 19]
Internet-Draft Blockchain for IP addresses October 2017
+-----+-----+-----+-----+-----------------+-----+-----+-----+
| 0 | 1 | 2 | 3 | ..... |47832|47833|47834|
+-----+-----+-----+-----+-----------------+-----+-----+-----+
9.1 Old blockchain
+-----+-----+-----+-----+-----+
| r0 | r1 | r2 | r3 | r4 |
+-----+-----+-----+-----+-----+
9.2 Write present state to special reset blocks
+-----+-----+-----+-----+-----+-----+-----+
| r0 | r1 | r2 | r3 | r4 | 0 | 1 | ...
+-----+-----+-----+-----+-----+-----+-----+
9.3 Continue working after the reset blocks
Figure 9.- A simple technique to reduce blockchain storage
This approach reduces bootstrapping cost, it is worth noting that
this strategy requires trust on the reset blocks, such blocks can be
obtained with an out-of-band mechanism (see Section 5.2.1.3 for
further information).
6.3. Proof of Networking?
In this section we speculate how one could design an equivalent of
Proof-of-Work (PoW) for networks. Conceptually, PoW is a proof of
computational resources, can we devise a proof of networking
resources? It could be thought that a PoW equivalent may exist in
the context of networks, i.e., an equivalent to spending computer
cycles in a network. Some resources unique to networks are
bandwidth, computation of checksums, number of BGP peers, etc.
Hence, we could envisage a blockchain secured by the resources
inherent to its participating computer networks. As long as half of
the resources were controlled by honest members, security is
guaranteed. For example, bandwidth could be a potential candidate;
however it does not satisfy two key features present in PoW:
Paillisse, et al. Expires May 2, 2018 [Page 20]
Internet-Draft Blockchain for IP addresses October 2017
o Asymmetry: the proof has to be hard to generate but fast to
verify.
o Verifiability: it has to be possible to embed the proof in the
block in order to account for the spending of resources.
In this context, Proof-of-Networking is an open research issue .
6.4. Configuration parameters
Configuration parameters refer to a set of values:
o Block creation rate
o Maximum block size
o Other parameters related to the consensus algorithm
These parameters, beyond regulating the operation of the blockchain
also have an influence on its performance. For example, a small
block size increases propagation speed (thus consensus can be reached
faster) but reduces the number of transactions per second that the
blockchain can handle. As an example, in Bitcoin, the 10-minute
block creation rate seeks to balance fast confirmation times and
reduced probability of forks [Antonopoulos2015]. Experimental
deployments and operational requirements should help tuning such
parameters.
7. Security Considerations
This document aims to understand the security implications of using
the blockchain technology to secure IP addresses allocation.
8. IANA Considerations
This memo includes no request to IANA.
9. Acknowledgements
The authors wish to thank Jordi Herrera-Joancomarti, Andreu
Rodriguez-Donaire and Jordi Baylina for their helpful discussions
about Bitcoin and blockchain technology, as well as Leo Vegoda for
his insights regarding revocation mechanisms.
Paillisse, et al. Expires May 2, 2018 [Page 21]
Internet-Draft Blockchain for IP addresses October 2017
10. Informative References
[Antonopoulos2015]
Antonopoulos, A., "Mastering Bitcoin, available online:
http://chimera.labs.oreilly.com/books/1234000001802/
index.html", 2015.
[Apostolaki2017]
Apostolaki, M., Zohar, A., and L. Vanbever, "Hijacking
Bitcoin: Routing Attacks on Cryptocurrencies. 2017 IEEE
Symposium on Security and Privacy (SP).", 2017.
[Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
System. https://bitcoin.org/bitcoin.pdf", 2008.
[Blockstack]
Ali, et al., M., "Blockstack : A Global Naming and Storage
System Secured by Blockchains, USENIX Annual Technical
Conference", 2016.
[Ethereum]
The Ethereum project, "https://www.ethereum.org/", 2016.
[Hari2016]
Hari, A. and T. Lakshman, "The Internet Blockchain: A
Distributed, Tamper-Resistant Transaction Framework for
the Internet. Fifteenth ACM Workshop on Hot Topics in
Networks", 2016.
[miningfarm]
Inside a mining farm, "http://www.bbc.com/future/
story/20160504-we-looked-inside-a-secret-chinese-bitcoin-
mine", 2016.
[Namecoin]
Namecoin, "https://namecoin.org/", 2011.
[Peercoin]
The Peercoin cryptocurrency, "https://peercoin.net/",
2016.
[realrouteattack]
Hacker Redirects Traffic From 19 Internet Providers to
Steal Bitcoins, "https://www.wired.com/2014/08/isp-
bitcoin-theft/", 2014.
Paillisse, et al. Expires May 2, 2018 [Page 22]
Internet-Draft Blockchain for IP addresses October 2017
Authors' Addresses
Jordi Paillisse
UPC-BarcelonaTech
c/ Jordi Girona 1-3
Barcelona, Catalonia 08034
Spain
Email: jordip@ac.upc.edu
Alberto Rodriguez-Natal
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: natal@cisco.com
Vina Ermagan
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: vermagan@cisco.com
Fabio Maino
Cisco Systems
170 Tasman Drive
San Jose, CA
USA
Email: fmaino@cisco.com
Albert Cabellos
UPC-BarcelonaTech
c/ Jordi Girona 1-3
Barcelona, Catalonia 08034
Spain
Email: acabello@ac.upc.edu
Paillisse, et al. Expires May 2, 2018 [Page 23]