< draft-paillisse-sidrops-blockchain-01.txt		draft-paillisse-sidrops-blockchain-02.txt >
	Network Working Group J. Paillisse		Network Working Group J. Paillisse
	Internet-Draft UPC-BarcelonaTech		Internet-Draft UPC-BarcelonaTech
	Intended status: Informational A. Rodriguez-Natal		Intended status: Informational A. Rodriguez-Natal
	Expires: May 2, 2018 V. Ermagan		Expires: December 30, 2018 V. Ermagan
	F. Maino		F. Maino
	Cisco Systems		Cisco Systems
			L. Vegoda
			Individual
	A. Cabellos		A. Cabellos
	UPC-BarcelonaTech		UPC-BarcelonaTech
	October 29, 2017		June 28, 2018
	An analysis of the applicability of blockchain to secure IP addresses		An analysis of the applicability of blockchain to secure IP addresses
	allocation, delegation and bindings.		allocation, delegation and bindings.
	draft-paillisse-sidrops-blockchain-01.txt		draft-paillisse-sidrops-blockchain-02
	Abstract		Abstract
	This document analyzes how blockchain technology can be used to		This document analyzes how blockchain technology can be used to
	secure the allocation, delegation and binding to topological		secure the allocation, delegation and binding to topological
	information of the IP address space. The main outcomes of the		information of the IP address space. The main outcomes of the
	analysis are that blockchain is suitable in environments with		analysis are that blockchain is suitable in environments with
	multiple distrusting parties and that Proof of Stake is a potential		multiple distrusting parties and that Proof of Stake is a potential
	candidate for a consensus algorithm.		candidate for a consensus algorithm.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on May 2, 2018.		This Internet-Draft will expire on December 30, 2018.
	Copyright Notice		Copyright Notice
	Copyright (c) 2017 IETF Trust and the persons identified as the		Copyright (c) 2018 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3		2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3
	3. Blockchain in a nutshell . . . . . . . . . . . . . . . . . . 3		3. Blockchain in a nutshell . . . . . . . . . . . . . . . . . . 3
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.1.1. Chain of signatures . . . . . . . . . . . . . . . . . 4		3.1.1. Chain of signatures . . . . . . . . . . . . . . . . . 4
	3.1.2. Consensus algorithm . . . . . . . . . . . . . . . . . 5		3.1.2. Consensus algorithm . . . . . . . . . . . . . . . . . 5
	3.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 5		3.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.3. Description of consensus algorithms . . . . . . . . . . . 6		3.3. Description of consensus algorithms . . . . . . . . . . . 7
	3.3.1. Proof of Work (PoW) . . . . . . . . . . . . . . . . . 6		3.3.1. Proof of Work (PoW) . . . . . . . . . . . . . . . . . 7
	3.3.2. Proof of Stake (PoS) . . . . . . . . . . . . . . . . 7		3.3.2. Proof of Stake (PoS) . . . . . . . . . . . . . . . . 8
	4. Blockchain for IP addresses . . . . . . . . . . . . . . . . . 8		4. Blockchain for IP addresses . . . . . . . . . . . . . . . . . 9
	4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 8		4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 9
	4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.3. A consensus algorithm for IP addresses . . . . . . . . . 9		4.3. A consensus algorithm for IP addresses . . . . . . . . . 10
	5. Overview of the architecture . . . . . . . . . . . . . . . . 10		5. Overview of the architecture . . . . . . . . . . . . . . . . 11
	5.1. Pros and cons . . . . . . . . . . . . . . . . . . . . . . 13		5.1. Support for IPv6 and AS numbers . . . . . . . . . . . . . 13
	5.2. Security evaluation . . . . . . . . . . . . . . . . . . . 14		5.2. Pros and cons . . . . . . . . . . . . . . . . . . . . . . 14
	5.2.1. Attacks against a PoS-based consensus algorithm . . . 14		5.3. Security evaluation . . . . . . . . . . . . . . . . . . . 16
	5.2.2. Attacks against the P2P network . . . . . . . . . . . 16		5.3.1. Attacks against a PoS-based consensus algorithm . . . 16
	6. Other Considerations . . . . . . . . . . . . . . . . . . . . 17		5.3.2. Attacks against the P2P network . . . . . . . . . . . 17
	6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17		6. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1.1. Expiration time . . . . . . . . . . . . . . . . . . . 18		6.1. Expiration time . . . . . . . . . . . . . . . . . . . . . 20
	6.1.2. Multi-signature transactions . . . . . . . . . . . . 18		6.2. Multi-signature transactions . . . . . . . . . . . . . . 20
	6.1.3. Revocation transaction . . . . . . . . . . . . . . . 18		6.3. Revocation transaction . . . . . . . . . . . . . . . . . 20
	6.1.4. Out-of-band mechanisms . . . . . . . . . . . . . . . 19		6.4. Heartbeat transaction . . . . . . . . . . . . . . . . . . 20
	6.2. Storage management . . . . . . . . . . . . . . . . . . . 19		6.5. Out-of-band mechanisms . . . . . . . . . . . . . . . . . 21
	6.3. Proof of Networking? . . . . . . . . . . . . . . . . . . 20		6.6. A simple revocation protocol . . . . . . . . . . . . . . 21
	6.4. Configuration parameters . . . . . . . . . . . . . . . . 21		7. Other Considerations . . . . . . . . . . . . . . . . . . . . 21
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 21		7.1. Storage management . . . . . . . . . . . . . . . . . . . 21
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21		7.2. Proof of Networking? . . . . . . . . . . . . . . . . . . 22
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21		7.3. Configuration parameters . . . . . . . . . . . . . . . . 23
	10. Informative References . . . . . . . . . . . . . . . . . . . 22		7.4. PoS algorithm design particularities . . . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23		7.5. Candidate PoS consensus algorithms . . . . . . . . . . . 24
			7.6. Privacy concerns . . . . . . . . . . . . . . . . . . . . 25
			7.7. Governance . . . . . . . . . . . . . . . . . . . . . . . 26
			8. Implementations . . . . . . . . . . . . . . . . . . . . . . . 26
			9. Security Considerations . . . . . . . . . . . . . . . . . . . 26
			10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
			11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26
			12. Informative References . . . . . . . . . . . . . . . . . . . 27
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
	1. Introduction		1. Introduction
	Blockchain [Bitcoin] is attracting a lot of attention among the		Blockchain [Bitcoin] is attracting a lot of attention among the
	security community since it provides means for exchanging information		security community since it provides means for exchanging information
	among a set of distrusting entities without the use of digital		among a set of distrusting entities without the use of digital
	certificates and centralized control. Blockchain provides means for		certificates and centralized control. Blockchain provides means for
	the distrusting parties to reach consensus in a distributed way.		the distrusting parties to reach consensus in a distributed way.
	Formally, it is regarded as a new solution to the Byzantine Generals		Formally, it is regarded as a new solution to the Byzantine Generals
	problem, well-known in fault-tolerant distributed systems.		problem, well-known in fault-tolerant distributed systems
			[Byzantine].
	Although at the time of this writing the main application of		Although at the time of this writing the main application of
	blockchain are financial systems, their use in the field of		blockchain are financial systems, their use in the field of
	networking is being explored (e.g., [Hari2016]). Some successful		networking is being explored (e.g., [Hari2016]). Some successful
	systems exist such as [Blockstack] and [Namecoin], which aim at		systems exist such as [Blockstack] and [Namecoin], which aim at
	building a secure DNS.		building a secure naming system, providing a similar functionality to
			that of DNSSEC.
	The main goal of this document is to represent a first step towards		The main goal of this document is to represent a first step towards
	the understanding of the properties of blockchains and their		the understanding of the properties of blockchains and their
	applicability in the Internet infrastructure, specifically securing		applicability in the Internet infrastructure, specifically securing
	the allocation, delegation and bindings of IP addresses. First, it		the allocation, delegation and bindings of IP addresses. First, it
	introduces blockchain, then it analyzes how blockchain could be used		introduces blockchain, then it analyzes how blockchain could be used
	to secure the delegation of IP addresses. Finally, it presents an		to secure the delegation of IP addresses. Finally, it presents an
	initial design for such an infrastructure. This document also		initial design for such an infrastructure. This document also
	includes a preliminary security analysis of such system. It is		includes a preliminary security analysis of such system. It is
	important to note that the goal of this document is not to provide a		important to note that the goal of this document is not to provide a
	skipping to change at page 3, line 38 ¶		skipping to change at page 4, line 4 ¶
	includes a preliminary security analysis of such system. It is		includes a preliminary security analysis of such system. It is
	important to note that the goal of this document is not to provide a		important to note that the goal of this document is not to provide a
	complete architecture that secures IP address allocation, delegation		complete architecture that secures IP address allocation, delegation
	and bindings.		and bindings.
	2. Definition of Terms		2. Definition of Terms
	TBC		TBC
	3. Blockchain in a nutshell		3. Blockchain in a nutshell
	3.1. Overview		3.1. Overview
	Conceptually, a blockchain is a distributed, secure and trustless		Conceptually, a blockchain is a distributed, secure and trustless
	database. It can also be regarded as a state machine with rules that		database. It can also be regarded as a state machine with rules that
	clearly state which transitions can be performed. Participants in		clearly state which transitions can be performed. Participants in
	the blockchain communicate through a P2P network. The smallest data		the blockchain communicate through a P2P network. The smallest data
	unit of a blockchain is a transaction. Users attach data to a		unit of a blockchain is a transaction. Users attach data to a
	transaction along with its signature and their associated public key.		transaction along with its signature and their associated public key.
	Usually, the attached data is an asset or a token, something that is		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		unique and should not be replicated (e.g., coins in Bitcoin). Then
	they broadcast this transaction to the other participants. The rest		they broadcast this transaction to the other participants. The rest
	of the nodes in the network store temporarily this transaction. At		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		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		transactions and groups them in a block. It then broadcasts this
	block back to the network. When the other nodes receive this block		block back to the network. When the other nodes receive this block
	they verify it, remove the transactions contained in the block from		they verify it, remove the transactions contained in the block from
	the temporary storage and add it after the previous block, thus		the temporary storage and add it after the previous block, thus
	creating a chain of blocks. It should be noted that all nodes store		creating a chain of blocks. It should be noted that all nodes store
	the entire blockchain locally. In addition, most blockchains give		the entire blockchain locally. In addition, most blockchains give
	some sort of reward to nodes that add new blocks, although this is		some sort of reward to nodes that add new blocks, although this is
	not strictly necessary. Figure 1 presents an overview of the most		not strictly necessary. Figure 1 presents an overview of the most
	common elements in a block.		common elements in a block.
	+--------+---------------+----------------+---------------+		+--------+---------------+----------------+---------------+
	| Block | Hash(Previous | Hash(All Block | Block Creator |		| Block | Hash(Previous | Hash(All Block | Block Creator |
	| Number | Block) | Transactions) | Signature |		| Number | Block) | Transactions) | Signature |
	+--------+---------------+----------------+---------------+		+--------+---------------+----------------+---------------+
	| Transaction 1 |		| Transaction 1 |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Transaction 2 |		| Transaction 2 |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	+ ... +		+ ... +
	+ ... +		+ ... +
	+---------------------------------------------------------+		+---------------------------------------------------------+
	| Transaction N |		| Transaction N |
	+---------------------------------------------------------+		+---------------------------------------------------------+
	Figure 1.- Common structure of a block		Figure 1.- Common structure of a block
	Two basic mechanisms are used to protect the chained data: a chain of		Two basic mechanisms are used to protect the chained data: a chain of
	signatures and a consensus algorithm.		signatures and a consensus algorithm.
	3.1.1. Chain of signatures		3.1.1. Chain of signatures
	The chain of signatures operates at transaction level. Consider the		The chain of signatures operates at transaction level. Consider the
	sender and receiver of a token, each with its public-private keypair.		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		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		receiver's public key. It then puts together its public key, the
	signature, the data and the hash of the receiver's public key		signature, the data and the hash of the receiver's public key (Figure
	(Figure 2) to form a transaction.		2) to form a transaction.
	+-------------+-------------------+--------+---------------+		+-------------+-------------------+--------+---------------+
	| Sender | Signature Sender | Data | Hash(Receiver |		| Sender | Signature Sender | Data | Hash(Receiver |
	| Public Key | Private Key | | Public Key) |		| Public Key | Private Key | | Public Key) |
	+-------------+-------------------+--------+---------------+		+-------------+-------------------+--------+---------------+
	Figure 2.- Common transaction structure in a blockchain		Figure 2.- Common transaction structure in a blockchain
	In conclusion, the rules of the blockchain enforce that:		In conclusion, the rules of the blockchain enforce that:
	skipping to change at page 5, line 27 ¶		skipping to change at page 5, line 33 ¶
	o When an owner sends a token to the new owner, it irreversibly		o When an owner sends a token to the new owner, it irreversibly
	transfers the control of the contents to the new owner.		transfers the control of the contents to the new owner.
	3.1.2. Consensus algorithm		3.1.2. Consensus algorithm
	The consensus algorithm is the central part of blockchain and it		The consensus algorithm is the central part of blockchain and it
	controls the chaining of data blocks. The main role of the algorithm		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		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		on a consistent view of the database. For this it has the following
	main functions. First, forks (multiple chains) can exist, this may		main functions. First, forks (multiple chains) can exist. This may
	happen for instance due to varying network latency among		happen for instance due to varying network latency among
	participants. In this case the participants must agree on which is		participants. In this case the participants must agree on which is
	the valid chain. And second, another important function of the		the valid chain. And second, another important function of the
	consensus algorithm is to determine which participants are allowed to		consensus algorithm is to determine which participants are allowed to
	add a new data blocks. Section 3.3 contains more information		add new data blocks. Section 3.3 contains more information regarding
	regarding available consensus algorithms.		available consensus algorithms.
	It is important to note that regardless of the consensus algorithm,		It is important to note that regardless of the consensus algorithm,
	in blockchain data blocks are always added, never deleted nor		in blockchain data blocks are always added, never deleted nor
	modified. This creates a tamper-proof, shared ledger among all		modified. This creates a tamper-proof, shared ledger among all
	participants. Transactions can be tracked back by inspecting past		participants. Transactions can be tracked back by inspecting past
	blocks, thus enabling the verification of claims by certain parties.		blocks, thus enabling the verification of claims by certain parties.
	3.2. Features		3.2. Features
	The following list tries to briefly summarize the main		The following list tries to briefly summarize the main
	skipping to change at page 6, line 22 ¶		skipping to change at page 6, line 33 ¶
	Non-repudiation: All nodes share a common, immutable view on the		Non-repudiation: All nodes share a common, immutable view on the
	status of the blockchain, and blockchain provides non-repudiation		status of the blockchain, and blockchain provides non-repudiation
	mechanisms.		mechanisms.
	Censorship-resistant: Gaining control over a transaction involves		Censorship-resistant: Gaining control over a transaction involves
	having access to the associated private key.		having access to the associated private key.
	Append-only: Data is always added, but never modified nor deleted.		Append-only: Data is always added, but never modified nor deleted.
	Privacy: Entities participating in the blockchain can achieve		Privacy: Entities participating in the blockchain can achieve
	privacy using anonymous keys, i.e. randomly-generated keys not		privacy using anonymous keys, i.e. randomly-generated keys not
	related to their identity. In addition, a new keypair should be		related to their identity. In addition, a new keypair should be
	generated for each new transaction in order to prevent tracking		generated for each new transaction in order to prevent tracking
	[Bitcoin], section 10.		[Bitcoin], section 10.
	Slow updates: New transactions have to be verified, added to a block		Slow updates: New transactions have to be verified, added to a block
	and received by all nodes. This results in a delay since the		and received by all nodes. This results in a delay since the
	transaction is created until it is finally available to all the		transaction is created until it is finally available to all the
	nodes. This delay will depend on the consensus algorithm and the		nodes. This delay will depend on the consensus algorithm and the
	block creation rate.		block creation rate.
	skipping to change at page 6, line 45 ¶		skipping to change at page 7, line 13 ¶
	scalability issues.		scalability issues.
	3.3. Description of consensus algorithms		3.3. Description of consensus algorithms
	The two more popular consensus algorithms are: Proof of Work and		The two more popular consensus algorithms are: Proof of Work and
	Proof of Stake.		Proof of Stake.
	3.3.1. Proof of Work (PoW)		3.3.1. Proof of Work (PoW)
	In Proof of Work nodes have to solve a complex mathematical problem		In Proof of Work nodes have to solve a complex mathematical problem
	to add a block, thus requiring some computational effort, this is		to add a block, requiring some computational effort. This is
	commonly know as mining. For example in Bitcoin the problem is to		commonly known as mining. For example in Bitcoin the problem is to
	find a hash starting with a fixed amount of zeroes, the only known		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		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		one with most accumulated computing power, this chain is also the
	more expensive in terms of computing power to modify. This is		more expensive in terms of computing power to modify. This is
	because modifying a block going N blocks back from the tip of the		because modifying a block going N blocks back from the tip of the
	chain would require redoing the computations for all these N blocks.		chain would require redoing the computations for all these N blocks.
	As a result, an attacker should have more computational power than		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		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		chain. Overall, it is commonly assumed that if more than half of the
	nodes are honest the blockchain is considered as secure.		nodes are honest, the blockchain is considered secure.
	PoW offers relevant features, adding new blocks requires an external		PoW offers relevant features, adding new blocks requires an external
	resource (CPU power) that has an economical cost. However this also		resource (CPU power) that has an economical cost. However this also
	results in some relevant drawbacks:		results in some relevant drawbacks:
	Risk of overtaking: The security of PoW is entirely based on		Risk of takeover: The security of PoW is entirely based on
	computation power. This means that if an entity has access to		computation power. This means that if an entity has access to
	more than half of the total blockchain's computing power it can		more than half of the total blockchain's computing power it can
	control the chain. As a result and in order to keep blockchain		control the chain. As a result and in order to keep blockchain
	secure, the incentive of taking control of the chain must be lower		secure, the incentive of taking control of the chain must be lower
	than the cost of acquiring and operating the hardware that		than the cost of acquiring and operating the hardware that
	provides the equivalent to half of the participants computing		provides the equivalent to half of the participants computing
	power. This is hard to guarantee since the economy of the		power. This is hard to guarantee since the economy of the
	blockchain and the economy of the required hardware are		blockchain and the economy of the required hardware are
	independent. As an example an attacker can acquire the required		independent. As an example an attacker can acquire the required
	hardware and operate it, take control of the blockchain to obtain		hardware and operate it, take control of the blockchain to obtain
	an economical benefit and finally sell the hardware to reduce the		an economical benefit and finally sell the hardware to reduce the
	final cost of the attack.		final cost of the attack.
	Hardware dependency: Bitcoin automatically increases -over time- the		Hardware dependency: Bitcoin automatically increases -over time- the
	complexity of the mathematical problem that needs to be solved in		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.		order to add a block. This is done to account for Moore's law.
	As a result the community has designed mining specific hardware		As a result the community has designed mining specific hardware
	(ASICs) that provides a competitive advantage. In this context		(ASICs) that provides a competitive advantage. In this context
	blockchain becomes less democratic, since the cost of		blockchain becomes less democratic, since the cost of
	participating in it increases.		participating in it increases. On the other hand, several ASIC-
			resistant algorithms are in use in various cryptocurrencies. This
			is usually achieved with memory-intensive calculations or
			frequently changing the mining algorithm. Although they appear to
			be a promising alternative, vendors react by developing a silicon
			implementation of the algorithm. In this situation, the
			developers usually change the algorithm by means of a hard fork
			[monero]. Ultimately, this becomes an arms-race.
	Energy inefficiency: PoW requires large amounts of energy to perform		Energy inefficiency: PoW requires large amounts of energy to perform
	the computations (e.g., [miningfarm]).		the computations (e.g., [miningfarm]).
	3.3.2. Proof of Stake (PoS)		3.3.2. Proof of Stake (PoS)
	The main idea behind Proof of Stake is that participants with more		The main idea behind Proof of Stake is that participants with more
	assets (or stake) in the blockchain are more likely to add blocks.		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		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		stake. For each new block, a signer is pseudo-randomly selected from
	list of participants typically weighted according to their stake. A		the list of participants typically weighted according to their stake.
	fundamental assumption behind PoS is that such entities have more		A fundamental assumption behind PoS is that such entities have more
	incentives for honest behaviour since they have more assets in the		incentives for honest behaviour since they have more assets in the
	chain.		chain.
	Proof of Stake is seen as an alternative to PoW. At the time of this		Proof of Stake is seen as an alternative to PoW. At the time of this
	writing major players in the blockchain environment such as		writing, major players in the blockchain environment (such as
	[Ethereum] are preparing a shift towards PoS, moreover several		[Ethereum]) are preparing a shift towards PoS. Moreover, several
	blockchains based on PoS already exist (eg. [Peercoin]). The main		blockchains based on PoS already exist (eg. [Peercoin]). The main
	reason behind this paradigm shift is that PoS addresses some of PoW's		reason behind this paradigm shift is that PoS addresses some of PoW's
	main drawbacks:		main drawbacks:
	o It does not require special hardware nor computationally or		o It does not require special hardware nor computationally or
	energy-expensive calculations.		energy-expensive calculations.
	o An attacker must get hold of a significant part of the assets in		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		order to gain control of the blockchain. As opposed to PoS the
	investment required to gain control of the chain lies within the		investment required to gain control of the chain lies within the
	skipping to change at page 9, line 32 ¶		skipping to change at page 10, line 5 ¶
	o Cannot be assigned to two entities at the same time.		o Cannot be assigned to two entities at the same time.
	o Can be divided up to a certain limit.		o Can be divided up to a certain limit.
	Such similar properties make it possible to envisage a blockchain		Such similar properties make it possible to envisage a blockchain
	that allows its participants delegate IP address blocks, similarly to		that allows its participants delegate IP address blocks, similarly to
	how Bitcoin transfers coins. For example, IANA could write a		how Bitcoin transfers coins. For example, IANA could write a
	transaction allocating addresses to the RIRs, which in turn could		transaction allocating addresses to the RIRs, which in turn could
	allocate them to the LIRs, etc. Complex management logic can be		allocate them to the LIRs, etc. Complex management logic can be
	defined as needed for example, rejecting a transaction that allocates		defined as needed. (For example, rejecting a transaction that
	of a block of addresses originated by an entity that does not hold		allocates of a block of addresses originated by an entity that does
	that block. In addition, transactions accept multiple inputs and		not hold that block.) In addition, transactions accept multiple
	outputs, i.e. an arbitrary amount of public keys either as senders or		inputs and outputs, i.e. an arbitrary amount of public keys either
	receivers. This means that it is possible to break and merge blocks		as senders or receivers. This means that it is possible to break and
	of addresses as required. Section 5 provides more detailed		merge blocks of addresses as required. Section 5 provides more
	information about this architecture.		detailed information about this architecture.
	4.3. A consensus algorithm for IP addresses		4.3. A consensus algorithm for IP addresses
	As stated before, the consensus algorithm is a central part of a		As stated before, the consensus algorithm is a central part of a
	blockchain. The first consensus algorithm designed for blockchain		blockchain. The first consensus algorithm designed for blockchain
	was PoW, and it is a common choice for new blockchain		was PoW, and it is a common choice for new blockchain
	implementations. However it presents several drawbacks		implementations. However it presents several drawbacks
	(Section 3.3.1) for the IP address scenario.		(Section 3.3.1) for the IP address scenario.
	Using computing power as a means to secure blockchains has been		Using computing power as a means to secure blockchains has been
	skipping to change at page 10, line 14 ¶		skipping to change at page 10, line 36 ¶
	objectives of the attacker, certain attacks can become profitable.		objectives of the attacker, certain attacks can become profitable.
	Namely, buying a large quantity of hardware to be able to rewrite the		Namely, buying a large quantity of hardware to be able to rewrite the
	blockchain with false data (e.g., incorrect delegations of IP		blockchain with false data (e.g., incorrect delegations of IP
	addresses). This is because the incentives of the participants of		addresses). This is because the incentives of the participants of
	the IP addresses blockchain are not linked with their computing		the IP addresses blockchain are not linked with their computing
	power.		power.
	In contrast, with Proof of Stake the capability to alter the		In contrast, with Proof of Stake the capability to alter the
	blockchain remains within it. This aspect is of particular		blockchain remains within it. This aspect is of particular
	importance in the context of securing IP addresses: it would mean		importance in the context of securing IP addresses: it would mean
	that AS domains holding large blocks of IP addresses are more likely		that entities holding large blocks of IP addresses are more likely to
	to add blocks. These parties have a reduced incentive in tampering		add blocks. These parties have a reduced incentive in tampering the
	the blockchain because they would suffer the consequences: an		blockchain because they would suffer the consequences: an insecure
	insecure Internet. Typically ASes that hold large blocks of IP		Internet. Typically entities that hold large blocks of the IP
	address space have their business within the Internet and as such,		address space have their business within the Internet and as such,
	have clear incentives in the correct operation and security of the		have clear incentives in the correct operation and security of the
	Internet.		Internet.
	Furthermore, in such blockchain the risk of takeover is reduced		Furthermore, in such blockchain the risk of takeover is reduced
	compared to PoW, the reason is that accumulating a large amount of IP		compared to PoW. The reason is that accumulating a large amount of
	addresses is typically more complex than accumulating computing		IP addresses is typically more complex than accumulating computing
	power. The risk of takeover is also mitigated compared to other PoS-		power. The risk of takeover is also mitigated compared to other PoS-
	based blockchains. In this blockchain an attacker would buy tokens		based blockchains. In this blockchain an attacker would buy tokens
	from the other parties, who receive a monetary compensation to		from the other parties, who receive a monetary compensation to
	participate in the attack. However, in a blockchain for IP addresses		participate in the attack. However, in a blockchain for IP addresses
	this would mean buying IP addresses from other parties, who do not		this would mean buying IP addresses from other parties, who do not
	have a clear incentive to sell their blocks of addresses to the		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		attacker. Because of this, PoS appears to be a firm candidate for a
	consensus algorithm in a blockchain for securing IP addresses		consensus algorithm in a blockchain for securing IP addresses
	allocations and delegations.		allocations and delegations.
	skipping to change at page 13, line 32 ¶		skipping to change at page 13, line 36 ¶
	| ISP A | ISP A | 1.2/16 | Hash(ISP A |		| ISP A | ISP A | 1.2/16 | Hash(ISP A |
	| Public Key 2 | Private Key 2 | AS no. | Public Key 3) |		| Public Key 2 | Private Key 2 | AS no. | Public Key 3) |
	| | | 12345 | |		| | | 12345 | |
	+--------------+-----------------+-----------+----------------+		+--------------+-----------------+-----------+----------------+
	Figure 8.- Example binding of AS number to prefix		Figure 8.- Example binding of AS number to prefix
	Additional and more complex operations can be defined if the		Additional and more complex operations can be defined if the
	management logic requires it. For instance, several signatures (from		management logic requires it. For instance, several signatures (from
	different parties) can be required to consider a transaction valid,		different parties) can be required to consider a transaction valid,
	etc.		restrict permissions for customer sub-delegations, etc.
	5.1. Pros and cons		5.1. Support for IPv6 and AS numbers
			The allocation and delegation of IPv6 addresses and AS numbers is
			equivalent to that of IPv4, maintaining the IANA -> RIR -> LIR
			hierarchy. For example, for IPv6:
			+--------------+------------------+-----------+----------------+
			| IANA v6 | Signature IANA | Allocate | Hash(IANA v6 |
			| Public Key 1 | v6 Private Key 1 | 0::/0 | Public Key 2) |
			+--------------+------------------+-----------+----------------+
			+--------------+------------------+-----------+----------------+
			| | | Rest of | Hash(IANA v6 |
			| IANA v6 | Signature IANA | space | Public Key 3) |
			| Public Key 2 | v6 Private Key 2 +-----------+----------------+
			| | | Allocate | Hash(IANA v6 |
			| | | 2000::/3 | Public Key 4) |
			+--------------+------------------+-----------+----------------+
			+--------------+------------------+------------+------------------+
			| | | Rest of | Hash(IANA v6 |
			| IANA v6 | Signature IANA | space | Public Key 5) |
			| Public Key 4 | v6 Private Key 2 +------------+------------------+
			| | | Allocate | Hash(AFRINIC v6 |
			| | | 2c00::/12 | Public Key 1) |
			+--------------+------------------+------------+------------------+
			+--------------+-------------------+-----------+-----------------+
			| | | Rest of | Hash(AFRINIC v6 |
			| AFRINIC v6 | Signature AFRINIC | space | Public Key 2) |
			| Public Key 1 | v6 Private Key 1 +-----------+-----------------+
			| | | Allocate | Hash(ISP A v6 |
			| | | 2c0c::/15 | Public Key 1) |
			+--------------+-------------------+-----------+-----------------+
			Figure 9.- IPv6 allocation transactions. From top to bottom:
			genesis transaction, global unicast allocation, AFRINIC allocation
			and LIR allocation.
			The process is equivalent for AS numbers. Besides, in the context of
			a multi-signature scheme, it is also possible to ask the holder of
			the AS number to confirm the binding of its AS number to a particular
			prefix.
			5.2. Pros and cons
	In this section we analyze the pros and cons of this architecture		In this section we analyze the pros and cons of this architecture
	compared to traditional PKI infraestructures:		compared to traditional PKI infraestructures:
	Advantages:		Advantages:
	o Decentralized: No central entity controls the blockchain, it is		o Decentralized: No central entity controls the blockchain, it is
	shared among all participants.		shared among all participants.
	o No CAs, CRLs or certificates needed: No digital certificates,		o No CAs, CRLs or certificates needed: No digital certificates,
	skipping to change at page 14, line 29 ¶		skipping to change at page 15, line 37 ¶
	However, in PoS it is necessary to periodically authenticate the		However, in PoS it is necessary to periodically authenticate the
	chain state out-of-band to prevent some attacks.		chain state out-of-band to prevent some attacks.
	o Simplified management: since CAs are not required, their		o Simplified management: since CAs are not required, their
	management overhead is avoided.		management overhead is avoided.
	o Auditable: allocations and delegations can be tracked back in the		o Auditable: allocations and delegations can be tracked back in the
	blockchain to determine if they originate from the legitimate		blockchain to determine if they originate from the legitimate
	holder.		holder.
			o Limited legal liability: since users control their private keys,
			Internet Registries cannot be held legally responsible of their
			loss. In turn, this can foster the creation of a unified registry
			instead of the current five. Ultimately, this would ease cross-
			registry resource transfers.
			o No single point of failure: again, due to the fact that each user
			controls its private key, the compromise of a user's key does not
			compromise the entire system. This starkly contrasts with the
			compromise of a CA, which can potentially invalidate all
			downstream certificates.
			o Simplified state update: PKIs need specific subsystems to update
			its state (e.g. issue/revoke certificates). On the other hand,
			in a blockchain all these operations are embedded in it thanks to
			its transactional nature.
	Drawbacks:		Drawbacks:
	o PoS does not rely on strong cryptographic guarantees: As opposed		o PoS does not rely on strong cryptographic guarantees: As opposed
	to PKI-based systems that rely on strong and well-established		to PKI-based systems that rely on strong and well-established
	cryptographic mechanisms, PoS-based infraestructures ultimately		cryptographic mechanisms, PoS-based infraestructures ultimately
	rely on the good behaviour of the high-stakers.		rely on the good behaviour of the high-stakers.
	o Costly bootstrapping: When a node is activated it has to download		o Costly bootstrapping: When a node is activated it has to download
	and verify the entire blockchain.		and verify the entire blockchain.
	o Large storage required: The blockchain grows forever as more		o Large storage required: The blockchain grows forever as more
	blocks are added, blocks cannot be removed.		blocks are added, blocks cannot be removed.
	5.2. Security evaluation		5.3. Security evaluation
	5.2.1. Attacks against a PoS-based consensus algorithm		5.3.1. Attacks against a PoS-based consensus algorithm
	This section presents a list of the most relevant attacks against a		This section presents a list of the most relevant attacks against a
	Proof of Stake algorithm and how to mitigate them.		Proof of Stake algorithm and how to mitigate them.
	5.2.1.1. Stake grinding		5.3.1.1. Stake grinding
	Stake grinding refers to the manipulation of the consensus algorithm		Stake grinding refers to the manipulation of the consensus algorithm
	in order to progressively obtain more stake, with the goal of signing		in order to progressively obtain more stake, with the goal of signing
	blocks more frequently with the ultimate goal of taking control of		blocks more frequently with the ultimate goal of taking control of
	the blockchain. It proceeds as follows: when the attacker has to		the blockchain. It proceeds as follows: when the attacker has to
	sign a block, it computes all the possible blocks (varying the data		sign a block, it computes all the possible blocks (varying the data
	inside them) to find a combination that gives the highest possibility		inside them) to find a combination that gives the highest possibility
	of signing another block in the future. It then signs this block and		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		sends it to the network. This procedure is repeated for all the next
	signing opportunities. Over time, the attacker will sign more and		signing opportunities. Over time, the attacker will sign more and
	more blocks until the consensus algorithm will always select the		more blocks until the consensus algorithm will always select the
	attacker to sign all blocks, thereby having taken control of the		attacker to sign all blocks, thereby having taken control of the
	blockchain.		blockchain.
	To prevent this attack, the source of randomness used to select the		To prevent this attack, the source of randomness used to select the
	signers has to be hard to alter or to predict.		signers has to be hard to alter or to predict.
	5.2.1.2. Nothing at stake		5.3.1.2. Nothing at stake
	Nothing at stake is one of the fundamental drawbacks of Proof of		Nothing at stake is one of the fundamental drawbacks of Proof of
	Stake and requires careful design based on the incentives of the		Stake and requires careful design based on the incentives of the
	participants. In common PoS designs, the signers of the new block		participants. In common PoS designs, the signers of the new block
	receive an economical incentive (e.g., Ethereum). However this does		receive an economical incentive (e.g., Ethereum). However this does
	not hold in the IP address scenario, since participants should not		not hold in the IP address scenario, since participants should not
	receive any incentive. The incentive is, as stated before, achieving		receive any incentive. The incentive is, as stated before, achieving
	a consistent view of the IP address space and having a secure		a consistent view of the IP address space and having a secure
	Internet.		Internet.
	5.2.1.3. Range attacks		5.3.1.3. Range attacks
	A range attack is performed by creating a fork some blocks back from		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		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		as 'Risk of takeover' in Section 3.3.1. In this scenario, the
	attacker has privately fabricated a chain which (according to the		attacker has privately fabricated a chain which (according to the
	consensus algorithm rules) will be selected over the original one.		consensus algorithm rules) will be selected over the original one.
	Benefits of this attack include gaining more stake on the blockchain		Benefits of this attack include gaining more stake on the blockchain
	(this attack could be part of a stake grinding attack) or rewriting		(this attack could be part of a stake grinding attack) or rewriting
	the transaction history to erase a payment made in the original		the transaction history to erase a payment made in the original
	blockchain.		blockchain.
	The simplest solution to this attack is adding a revert limit to the		The simplest solution to this attack is adding a revert limit to the
	blockchain, forbidding forks going back more than N blocks. This		blockchain, forbidding forks going back more than N blocks. This
	provides a means to solidify the blockchain. However, nodes that		provides a means to solidify the blockchain. However, nodes that
	have been offline for more than N blocks will need an external source		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		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		out of band. This is why a PoS blockchain is not purely trustless
	and requires a small amount of trust.		and requires a small amount of trust.
	5.2.1.4. Lack of participation		5.3.1.4. Monopolies
			A monopoly refers to a single party controlling enough IP addresses
			so it can sign a significant proportion of new blocks, thus being
			able to decide which information is written in the chain (e.g., a 51
			% attack in Bitcoin). However and in this use-case, this is of less
			concern since parties do not have a clear incentive to alter normal
			chain operation. In order to successfully launch this attack a party
			should control more than 50% of the IP blocks, while this is
			difficult to achieve and participants do not have a clear incentive
			to sell/give away blocks of IPs, the attacker would also impact its
			own infrastructure, making the Internet less secure. Section 7.4
			contains more details regarding monopolies.
			5.3.1.5. Lack of participation
	Participants in a PoS algorithm will not always sign a block, since		Participants in a PoS algorithm will not always sign a block, since
	they might be offline when they are selected or lack incentives.		they might be offline when they are selected or lack incentives.
	Because of this, the final fraction of high-stakers that sign blocks		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		can be very different from the full set of high-stakers. The direct
	consequence of this situation is that the portion of participants		consequence of this situation is that the portion of participants
	that decide what goes into the blockchain can be a small set of		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		nodes. If this participation is low enough, it can leave the control
	of the blockchain to a small amount of people/oligarchy, thus rising		of the blockchain to a small amount of people/oligarchy, thus rising
	security concerns.		security concerns.
	5.2.2. Attacks against the P2P network		5.3.2. Attacks against the P2P network
	This section presents attacks directed towards the underlying P2P		This section presents attacks directed towards the underlying P2P
	network used to exchange information among the participants of the		network used to exchange information among the participants of the
	blockchain.		blockchain.
	5.2.2.1. DDOS attacks		5.3.2.1. DDOS attacks
	Since blockchains are inherently based on P2P architectures, they		Since blockchains are inherently based on P2P architectures, they
	present a higher degree of resistance to DDOS attacks than		present a higher degree of resistance to DDOS attacks than
	centralized server architectures, provided that the network has a		centralized server architectures, provided that the network has a
	significant number of participants. In addition, it is always		significant number of participants. In addition, it is always
	possible to keep an offline copy of the blockchain.		possible to keep an offline copy of the blockchain.
	5.2.2.2. Transaction flooding		5.3.2.2. Transaction flooding
	A special type of DDOS attack consists in creating a large amount of		A special type of DDOS attack consists in creating a large amount of
	legit transactions that transfer a small amount of tokens (i.e.		legit transactions that transfer a small amount of tokens (i.e.
	delegate a lot of small IP prefixes). If the number of transactions		delegate a lot of small IP prefixes). If the number of transactions
	is large enough, the addition of new transactions can be		is large enough, the addition of new transactions can be
	significantly delayed because not all of them fit into a single		significantly delayed because not all of them fit into a single
	block. The effectiveness of the attack also depends on the		block. The effectiveness of the attack also depends on the
	throughput of the blockchain (transactions/second). Simple solutions		throughput of the blockchain (transactions/second). Simple solutions
	may be to limit the granularity upon which IP addresses can be split.		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		Of course, only the legitimate holder of a large amount of IP address
	can perform this attack.		can perform this attack.
	5.2.2.3. Routing attacks		5.3.2.3. Routing attacks
	The underlying P2P network in blockchains does not typically use any		The underlying P2P network in blockchains does not typically use any
	security mechanism, e.g. node authentication or integrity of network		security mechanism, e.g. node authentication or integrity of network
	protocol messages. This enables potentially disruptive attacks. For		protocol messages. This enables potentially disruptive attacks. For
	example, specially located rogue nodes could drop new transactions,		example, specially located rogue nodes could drop new transactions,
	which would block updates on the blockchain and leave legit nodes		which would block updates on the blockchain and leave legit nodes
	uncommunicated. The effectiveness of this kind of attacks depends on		uncommunicated. The effectiveness of this kind of attacks depends on
	how the P2P algorithm selects peers and the topology of the P2P		how the P2P algorithm selects peers and the topology of the P2P
	network.		network.
	However, the most potentially dangerous attack of this type are		However, the most potentially dangerous attack of this type are
	network partitions, i.e. isolating a group of nodes from the rest of		network partitions, i.e. isolating a group of nodes from the rest of
	the network so they cannot communicate each other (e.g.,		the network so they cannot communicate each other (e.g.,
	[Apostolaki2017]). The consequence of this attack is that two		[Apostolaki2017]). The consequence of this attack is that two
	versions of the blockchain are created, one at each network		versions of the blockchain are created, one at each network
	partition. When the partition disappears and the nodes reconnect one		partition. When the partition disappears and the nodes reconnect one
	of the two chains will be discarded, causing a service disruption.		of the two chains will be discarded, causing a service disruption.
	It is worth noting that Bitcoin has suffered similar attacks		It is worth noting that Bitcoin has suffered similar attacks
	[realrouteattack].		[realrouteattack].
	5.2.2.4. Transaction censorship		5.3.2.4. Transaction censorship
	When a node adds a block it chooses arbitrarily which transactions		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 into it, i.e. no specific rules control how transactions
	are added to a block. This enables a node to selectively add some		are added to a block. This enables a node to selectively add some
	transactions and intentionally exclude others, with the consequence		transactions and intentionally exclude others, with the consequence
	that some transactions may be never added to the blockchain. In the		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		context of IP addresses, this may be performed by a competing ISP to
	prevent another ISP from executing a certain modification. Possible		prevent another ISP from executing a certain modification. Possible
	solutions revolve around:		solutions revolve around:
	o Giving more priority to older transactions (similarly to Bitcoin).		o Giving more priority to older transactions (similarly to Bitcoin).
	o Punishing nodes that exhibit this kind of behaviour, e.g. removing		o Punishing nodes that exhibit this kind of behaviour, e.g.
	part of their block of IP addresses or lowering their chance of		removing part of their block of IP addresses or lowering their
	adding blocks.		chance of adding blocks.
	6. Other Considerations
	6.1. Revocation		6. Revocation
	Due to the irreversible nature of transactions, once a block of IP		Due to the irreversible nature of transactions, once a block of IP
	addresses has been allocated to an entity it is not possible to		addresses has been allocated to an entity it is not possible to
	modify or remove it, as opposed to CRLs (Certificate Revocation		modify or remove it, as opposed to CRLs (Certificate Revocation
	Lists). However, due to operational issues (compromised or lost		Lists). However, due to operational issues (compromised or lost
	keys, human mistake, holder misbehaviour, etc) it is critical to		keys, human mistake, holder misbehaviour, etc) it is critical to
	provide a way to recover a block of addresses. Moreover, since IP		provide a way to recover a block of addresses. Moreover, since IP
	addresses are a finite public good they cannot be lost. Taking into		addresses are a finite public good they cannot be lost. Taking into
	account that a blockchain can enforce any rules its participants		account that a blockchain can enforce any rules its participants
	agree upon, this section presents some possible approaches to		agree upon, this section presents some possible approaches to
	skipping to change at page 18, line 17 ¶		skipping to change at page 20, line 5 ¶
	all these mechanisms there is a fundamental tradeoff between trusting		all these mechanisms there is a fundamental tradeoff between trusting
	an upstream provider of the addresses and retaining full control of		an upstream provider of the addresses and retaining full control of
	the block of addresses.		the block of addresses.
	Regardless of the revocation policy and as opposed to traditional PKI		Regardless of the revocation policy and as opposed to traditional PKI
	systems, each IP prefix delegation only depends on the private key of		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		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		or a chain of certificates. Only by means of this private key the IP
	delegation can be altered.		delegation can be altered.
	6.1.1. Expiration time		6.1. Expiration time
	A simple approach to allow revocation is adding a lease time (i.e,		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		time-to-live) to the blocks of addresses. After the lease ends, the
	new holder of the address block automatically becomes the previous		new holder of the address block automatically becomes the previous
	one, or addresses are transferred to a default holder. As stated		one, or addresses are transferred to a default holder. As stated
	before, this revocation procedure should be enforced by the rules of		before, this revocation procedure should be enforced by the rules of
	the blockchain, this means that participants would not recognise		the blockchain, this means that participants would not recognise
	expired allocations as valid.		expired allocations as valid.
	6.1.2. Multi-signature transactions		6.2. Multi-signature transactions
	A multi-signature transaction is a transaction that admits more than		A multi-signature transaction is a transaction with more than one
	one authorized signer. In other words, a transaction is considered		associated public key. In other words, a transaction is considered
	valid if it has, for instance, 2 out of 5 valid signatures. This		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		way, 3 keys can be lost but with the renaming 2 keys the block of
	addresses can be recovered. This approach exemplifies the		addresses can be recovered. This approach exemplifies the
	aforementioned tradeoff in trust, since the holder of the block of		aforementioned tradeoff in trust, since the holder of the block of
	addresses must trust the owners of the keys participating in the		addresses must trust the owners of the keys participating in the
	multi-signature transaction.		multi-signature transaction. For instance, if some of these keys are
			owned by IANA or an Internet Registry, we can return part of the
			control over the allocation to them.
	6.1.3. Revocation transaction		6.3. Revocation transaction
	A simpler approach than multi-signature transactions is creating a		A simpler approach than multi-signature transactions is creating a
	'revocation' transaction. When a block of address is required to be		'revocation' transaction. When a block of address is required to be
	reassigned without the consent of the current holder, a revocation		reassigned without the consent of the current holder, a revocation
	transaction (specifying the new holder) is inserted in the		transaction (specifying the new holder) is inserted in the
	blockchain. This transaction should be issued either by a		blockchain. This transaction should be issued either by a
	consensuated authority or by a disputing entity. The revocation		consensuated authority or by a disputing entity. The revocation
	transaction should be resolved by either accepting the revocation		transaction should be resolved by either accepting the revocation
	transaction automatically when issued by the accepted authority or by		transaction automatically when issued by the accepted authority or by
	means of out-of-band mechanisms when issued by a disputing party.		means of out-of-band mechanisms when issued by a disputing party.
	6.1.4. Out-of-band mechanisms		6.4. Heartbeat transaction
			Another approach involves issuing a heartbeat transaction every N
			days, signalling to the network that the holder still owns the key
			associated with that particular resource. If the holder fails to
			issue this transaction, the blockchain considers that the resource is
			automatically returned to the registry.
			6.5. Out-of-band mechanisms
	Disputes regarding transactions can be resolved by means of out-of-		Disputes regarding transactions can be resolved by means of out-of-
	band mechanisms, e.g, discussion, court, etc. In order to reflect		band mechanisms, e.g, discussion, court, etc. In order to reflect
	the decision of this out-of-band mechanism the blockchain must be		the decision of this out-of-band mechanism the blockchain must be
	modified. Since this represents a deviation from the rules, it must		modified. Since this represents a deviation from the rules, it must
	be done through a hard blockchain fork. Although cumbersome and		be done through a hard blockchain fork. Although cumbersome and
	complex, this is feasible from a technical standpoint.		complex, this is feasible from a technical standpoint.
	6.2. Storage management		6.6. A simple revocation protocol
			Here we present a simple revocation protocol to handle accidental key
			loss:
			1. On detecting the key loss, the holder notifies the registry, e.g.
			via e-mail.
			2. The registry issues a revocation transaction, similar to the one
			in section Section 6.3.
			3. The current holder has a fixed period of time to issue a
			transaction re-claiming the resource. This transaction must be
			signed by the private key associated with the claimed resource.
			4. If the holder issues the transaction, it retains the resource.
			5. Otherwise, after the fixed time interval, the blockchain
			considers that the resource is returned to the registry, so it
			can be re-allocated.
			This protocol combines two of the aforementioned techniques, and
			allows to balance power between resource holders and registries.
			Registries can revoke lost or unclaimed resources, while address
			holders can retain them if the registry misbehaves or its key is
			compromised. However, it should be noted that this protocol does not
			protect from stolen keys.
			The time interval can be different depending on the nature of the
			revocating entity. For example, IANA -> RIR allocations could wait a
			couple of weeks, whereas RIR -> LIR allocations could go faster with
			a 72 hours notification period.
			7. Other Considerations
			7.1. Storage management
	The never ending size of the blockchain presents a potential		The never ending size of the blockchain presents a potential
	scalability issue. At the time of this writing, mature blockchains		scalability issue. At the time of this writing, mature blockchains
	like Bitcoin require more than 100 GB of storage. Simply deleting or		like Bitcoin require more than 100 GB of storage. Simply deleting or
	summarizing old transactions degrades the security of PoW-based		summarizing old transactions degrades the security of PoW-based
	chains, since their security relies on the computing power required		chains, since their security relies on the computing power required
	to generate them. The longer they are, the harder they are to		to generate them. The longer they are, the harder they are to
	attack.		attack.
	However, PoS-based chains do not rely on computing power and hence,		However, PoS-based chains do not rely on computing power and hence,
	skipping to change at page 20, line 23 ¶		skipping to change at page 22, line 34 ¶
	+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+
	9.2 Write present state to special reset blocks		9.2 Write present state to special reset blocks
	+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+
	| r0 | r1 | r2 | r3 | r4 | 0 | 1 | ...		| r0 | r1 | r2 | r3 | r4 | 0 | 1 | ...
	+-----+-----+-----+-----+-----+-----+-----+		+-----+-----+-----+-----+-----+-----+-----+
	9.3 Continue working after the reset blocks		9.3 Continue working after the reset blocks
	Figure 9.- A simple technique to reduce blockchain storage		Figure 10.- A simple technique to reduce blockchain storage
	This approach reduces bootstrapping cost, it is worth noting that		This approach reduces bootstrapping cost, it is worth noting that
	this strategy requires trust on the reset blocks, such blocks can be		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		obtained with an out-of-band mechanism (see Section 5.3.1.3 for
	further information).		further information).
	6.3. Proof of Networking?		7.2. Proof of Networking?
	In this section we speculate how one could design an equivalent of		In this section we speculate how one could design an equivalent of
	Proof-of-Work (PoW) for networks. Conceptually, PoW is a proof of		Proof-of-Work (PoW) for networks. Conceptually, PoW is a proof of
	computational resources, can we devise a proof of networking		computational resources, can we devise a proof of networking
	resources? It could be thought that a PoW equivalent may exist in		resources? It could be thought that a PoW equivalent may exist in
	the context of networks, i.e., an equivalent to spending computer		the context of networks, i.e., an equivalent to spending computer
	cycles in a network. Some resources unique to networks are		cycles in a network. Some resources unique to networks are
	bandwidth, computation of checksums, number of BGP peers, etc.		bandwidth, computation of checksums, number of BGP peers, etc.
	Hence, we could envisage a blockchain secured by the resources		Hence, we could envisage a blockchain secured by the resources
	inherent to its participating computer networks. As long as half of		inherent to its participating computer networks. As long as half of
	the resources were controlled by honest members, security is		the resources were controlled by honest members, security is
	skipping to change at page 21, line 13 ¶		skipping to change at page 23, line 25 ¶
	however it does not satisfy two key features present in PoW:		however it does not satisfy two key features present in PoW:
	o Asymmetry: the proof has to be hard to generate but fast to		o Asymmetry: the proof has to be hard to generate but fast to
	verify.		verify.
	o Verifiability: it has to be possible to embed the proof in the		o Verifiability: it has to be possible to embed the proof in the
	block in order to account for the spending of resources.		block in order to account for the spending of resources.
	In this context, Proof-of-Networking is an open research issue .		In this context, Proof-of-Networking is an open research issue .
	6.4. Configuration parameters		7.3. Configuration parameters
	Configuration parameters refer to a set of values:		Configuration parameters refer to a set of values:
	o Block creation rate		o Block creation rate
	o Maximum block size		o Maximum block size
	o Other parameters related to the consensus algorithm		o Other parameters related to the consensus algorithm
	These parameters, beyond regulating the operation of the blockchain		These parameters, beyond regulating the operation of the blockchain
	also have an influence on its performance. For example, a small		also have an influence on its performance. For example, a small
	block size increases propagation speed (thus consensus can be reached		block size increases propagation speed (thus consensus can be reached
	faster) but reduces the number of transactions per second that the		faster) but reduces the number of transactions per second that the
	blockchain can handle. As an example, in Bitcoin, the 10-minute		blockchain can handle. As an example, in Bitcoin, the 10-minute
	block creation rate seeks to balance fast confirmation times and		block creation rate seeks to balance fast confirmation times and
	reduced probability of forks [Antonopoulos2015]. Experimental		reduced probability of forks [Antonopoulos2015]. Experimental
	deployments and operational requirements should help tuning such		deployments and operational requirements should help tuning such
	parameters.		parameters.
	7. Security Considerations		7.4. PoS algorithm design particularities
			The particular use case of IP addresses presents some characteristics
			that the PoS algorithm should take into account:
			Monopoly prevention: As described in section Section 5.3.1.4,
			monopolies can pose a threat to a PoS blockchain. In order to
			prevent a small number of large-stakers from controlling the
			chain, we can design the PoS algorithm to have a smart mapping of
			IP prefixes to the weight of the random selection. A potential
			solution could be fine-tuning the weighting of IP addresses
			(slightly biasing the choice towards medium-sized holders), in
			order to reduce the power of high stakers. This can provide an
			upper-bound of the maximum number of addresses that a party can
			hold to avoid monopolies (ideally as high as possible).
			IPv6 support: Large parts of the IPv6 address space remain
			unallocated and still owned by IANA (at the time of writing this
			document, less than 0.5% of v6 address space has been allocated to
			the RIRs). The PoS algorithm should ignore this space (not count
			it) to avoid IANA signing nearly all v6 blocks and thus,
			preventing an IANA monopoly.
			IPv4/v6 stake isolation: Since there are more IPv6 addresses than
			IPv4, this creates an imbalance of power in a PoS blockchain:
			randomly selecting from both pools of addresses naturally causes
			v6 holders signing more blocks than v4 holders. Thus, some kind
			of isolation between v4 and v6 stake is required. For example, we
			could alternatively generate blocks with only v4 or v6
			transactions, signed by a v4 or v6 holder, respectively.
			7.5. Candidate PoS consensus algorithms
			There are several existing PoS algorithms that could satisfy the
			requirements of a blockchain for IP addresses. The following list
			presents three of them that have been claimed by the authors to be
			proven mathematically correct. A substantial difference among them
			is the supported portion of offline participants. The list does not
			pretend to be exhaustive.
			Algorand: [Algorand] leverages a multi-step protocol to provide a
			verifiable random selection of the block signer. The most
			relevant features of Algorand are:
			* A cryptographic sortition mechanism to randomly select the
			participants in each step of the protocol, based on Verifiable
			Random Functions [I-D.irtf-cfrg-vrf].
			* The decoupling of block creation and block signing, to avoid
			stake grinding attacks.
			* A new Byzantine Agreement protocol (BA*) to achieve consensus.
			* Player replaceability: Algorand uses a different set of
			participants for each of its steps. Thus, malicious
			participants from one step cannot influence the following.
			* Upper bound of 1/3 of dishonest players.
			Ouroboros: [Ouroboros] presents a similar approach to Algorand:
			first, it selects a subset of users. Then, these users perform
			the random selection by means of a secure multiparty computation.
			As opposed to Algorand, however, this subset lasts for several
			blocks, called epochs. In addition, Ouroboros assumes that the
			majority of participants are online when they have to participate
			in the protocol, and that they remain offline only short periods
			of time.
			Snow White: The [SnowWhite] protocol improves on the previous two by
			supporting also large amounts of offline participants, as long as
			the majority of online members are honest. They call this
			property 'Robustly Reconfigurable Consensus'. Snow White also
			leverages a random function to decide if a participant has to sign
			a block, and defines epochs similarly to Ouroboros: after each
			epoch, participants for the new one are calculated.
			7.6. Privacy concerns
			In order to protect privacy, the blockchain should not contain
			Personally Identifiable Information (PII). This is due to the fact
			that data in the blockchain cannot be removed and that it is a public
			ledger, accessible by anyone. Instead, PII like contact emails or
			postal addresses should be stored in the Registry's database (e.g.
			RIPE Database). Ideally, the blockchain should contain the minimum
			amount of data for correct operation, that is: public keys, blocks of
			IP addresses, AS numbers and their bindings (figure 11).
			Public Private
			+---------------------+ +-----------------------+
			| Blockchain | +-----------+ | Registry Database |
			| |<---|Update |<---| |
			| Pairs of (Prefix, | |prefix, key| | *Registry Policies |
			| Public key) | |pair | | *Contact data |
			| | +-----------+ | |
			+---------------------+ +-----------------------+
			Figure 11.- Data flow between Registry and blockchain
			7.7. Governance
			Blockchain does not mean anarchy. In fact, any blockchain requires a
			governing entity that determines its rules and ensures that all of
			its participants agree on its operation. The need of governance is
			illustrated by the recent Bitcoin Cash fork [Bitcoincash]. Due to a
			disagreement among Bitcoin users, they created a Bitcoin hard fork
			called Bitcoin Cash. This split the Bitcoin blockchain in two,
			causing some confusion. Proper governance should avoid such
			situations.
			This particular use case is not an exception: all concerned parties
			(IANA, RIRs, ISPs, etc) should reach consensus regarding which rules
			are enforced in the blockchain. For example, dispute resolution or
			revocation procedures.
			8. Implementations
			There are several implementations to secure the allocation of IP
			prefixes. They present different scopes and levels of maturity.
			o IPchain uses a Proof of Stake algorithm and is specifically
			tailored for the allocation of IP addresses. Its performance has
			been evaluated [IPchain], and has been open-sourced
			[IPchain-repo].
			o [BGPCoin] runs on top of the Ethereum blockchain and provides
			similar features to IPchain. It has not been possible to find
			open-source code.
			o Another project identically named BGPCoin is designed to allow
			ISPs to exchange peering agreements and route advertisements by
			means of a blockchain [BGPCoin-repo]. It uses a hybrid PoW/PoS
			algorithm and has its own cryptocurrency.
			9. Security Considerations
	This document aims to understand the security implications of using		This document aims to understand the security implications of using
	the blockchain technology to secure IP addresses allocation.		the blockchain technology to secure IP addresses allocation.
	8. IANA Considerations		10. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	9. Acknowledgements		11. Acknowledgements
	The authors wish to thank Jordi Herrera-Joancomarti, Andreu		The authors wish to thank Jordi Herrera-Joancomarti, Andreu
	Rodriguez-Donaire and Jordi Baylina for their helpful discussions		Rodriguez-Donaire and Jordi Baylina for their helpful discussions
	about Bitcoin and blockchain technology, as well as Leo Vegoda for		about Bitcoin and blockchain technology, as well as Marco Chiesa for
	his insights regarding revocation mechanisms.		the heartbeat transaction idea.
	10. Informative References		12. Informative References
			[Algorand]
			Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and N.
			Zeldovich, "Algorand: Scaling byzantine agreements for
			cryptocurrencies. Proceedings of the 26th Symposium on
			Operating Systems Principles (pp. 51-68). ACM.", 2017.
	[Antonopoulos2015]		[Antonopoulos2015]
	Antonopoulos, A., "Mastering Bitcoin, available online:		Antonopoulos, A. M., "Mastering Bitcoin, available online:
	http://chimera.labs.oreilly.com/books/1234000001802/		http://chimera.labs.oreilly.com/books/1234000001802/
	index.html", 2015.		index.html", 2015.
	[Apostolaki2017]		[Apostolaki2017]
	Apostolaki, M., Zohar, A., and L. Vanbever, "Hijacking		Apostolaki, M., Zohar, A., and L. Vanbever, "Hijacking
	Bitcoin: Routing Attacks on Cryptocurrencies. 2017 IEEE		Bitcoin: Routing Attacks on Cryptocurrencies. 2017 IEEE
	Symposium on Security and Privacy (SP).", 2017.		Symposium on Security and Privacy (SP). ", 2017.
			[BGPCoin-repo]
			BGPCoin GitHub repository, , "https://github.com/bgpcoin",
			2018.
			[BGPCoin] Xing, Q., Wang, B., and X. Wang, "POSTER: BGPCoin: A
			Trustworthy Blockchain-based Resource Management Solution
			for BGP Security. ACM Conference on Computer and
			Communications Security (CCS) 2017", 2017.
	[Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash		[Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash
	System. https://bitcoin.org/bitcoin.pdf", 2008.		System. https://bitcoin.org/bitcoin.pdf", 2008.
			[Bitcoincash]
			Bitcoin split in two, here's what that means, , "http://
			money.cnn.com/2017/08/01/technology/business/bitcoin-cash-
			new-currency/index.html", 2017.
	[Blockstack]		[Blockstack]
	Ali, et al., M., "Blockstack : A Global Naming and Storage		Ali, et al., M., "Blockstack : A Global Naming and Storage
	System Secured by Blockchains, USENIX Annual Technical		System Secured by Blockchains, USENIX Annual Technical
	Conference", 2016.		Conference", 2016.
			[Byzantine]
			Lamport, L., Shostak, R., and M. Pease, "The Byzantine
			Generals Problem. ACM Transactions on Programming
			Languages and Systems", 1982.
	[Ethereum]		[Ethereum]
	The Ethereum project, "https://www.ethereum.org/", 2016.		The Ethereum project, , "https://www.ethereum.org/", 2016.
	[Hari2016]		[Hari2016]
	Hari, A. and T. Lakshman, "The Internet Blockchain: A		Hari, A. and T. Lakshman, "The Internet Blockchain: A
	Distributed, Tamper-Resistant Transaction Framework for		Distributed, Tamper-Resistant Transaction Framework for
	the Internet. Fifteenth ACM Workshop on Hot Topics in		the Internet. Fifteenth ACM Workshop on Hot Topics in
	Networks", 2016.		Networks", 2016.
	[miningfarm]		[I-D.irtf-cfrg-vrf]
	Inside a mining farm, "http://www.bbc.com/future/		Goldberg, S., Reyzin, L., Papadopoulos, D., and J. Vcelak,
	story/20160504-we-looked-inside-a-secret-chinese-bitcoin-		"Verifiable Random Functions (VRFs)", draft-irtf-cfrg-
	mine", 2016.		vrf-01 (work in progress), March 2018.
			[IPchain-repo]
			IPchain GitHub repository, , "https://github.com/
			OpenOverlayRouter/blockchain-mapping-system", 2018.
			[IPchain] Paillisse, J., Ferriol, M., Garcia, E., Latif, H., Piris,
			C., Lopez, A., Kuerbis, B., Rodriguez-Natal, A., Ermagan,
			V., Maino, Fabio., and A. Cabellos, "IPchain: Securing IP
			Prefix Allocation and Delegation with Blockchain, arXiv
			preprint: https://arxiv.org/abs/1805.04439", 2018.
	[Namecoin]		[Namecoin]
	Namecoin, "https://namecoin.org/", 2011.		Namecoin, , "https://namecoin.org/", 2011.
			[Ouroboros]
			Kiayias, A., Russell, A., David, B., and R. Oliynykov,
			"Ouroboros: A provably secure proof-of-stake blockchain
			protocol. Annual International Cryptology Conference (pp.
			357-388). Springer, Cham.", 2017.
	[Peercoin]		[Peercoin]
	The Peercoin cryptocurrency, "https://peercoin.net/",		The Peercoin cryptocurrency, , "https://peercoin.net/",
			2016.
			[SnowWhite]
			Bentov, I., Pass, R., and E. Shi, "Snow White: Provably
			Secure Proofs of Stake. IACR Cryptology ePrint Archive,
			2016, 919.", 2016.
			[miningfarm]
			Inside a mining farm, , "http://www.bbc.com/future/story/
			20160504-we-looked-inside-a-secret-chinese-bitcoin-mine",
	2016.		2016.
			[monero] Monero PoW algorithm update, , "https://www.ethnews.com/
			monero-team-mulls-changing-pow-algorithm-to-preempt-asic-
			miners", 2018.
	[realrouteattack]		[realrouteattack]
	Hacker Redirects Traffic From 19 Internet Providers to		Hacker Redirects Traffic From 19 Internet Providers to
	Steal Bitcoins, "https://www.wired.com/2014/08/isp-		Steal Bitcoins, , "https://www.wired.com/2014/08/isp-
	bitcoin-theft/", 2014.		bitcoin-theft/", 2014.
	Authors' Addresses		Authors' Addresses
	Jordi Paillisse		Jordi Paillisse
	UPC-BarcelonaTech		UPC-BarcelonaTech
	c/ Jordi Girona 1-3		c/ Jordi Girona 1-3
	Barcelona, Catalonia 08034		Barcelona, Catalonia 08034
	Spain		Spain
	skipping to change at page 23, line 38 ¶		skipping to change at page 30, line 4 ¶
	Email: vermagan@cisco.com		Email: vermagan@cisco.com
	Fabio Maino		Fabio Maino
	Cisco Systems		Cisco Systems
	170 Tasman Drive		170 Tasman Drive
	San Jose, CA		San Jose, CA
	USA		USA
	Email: fmaino@cisco.com		Email: fmaino@cisco.com
			Leo Vegoda
			Individual
			4712 Admiralty Way, #152
			Marina del Rey, CA 90292
			USA
			Email: leo@vegoda.org
	Albert Cabellos		Albert Cabellos
	UPC-BarcelonaTech		UPC-BarcelonaTech
	c/ Jordi Girona 1-3		c/ Jordi Girona 1-3
	Barcelona, Catalonia 08034		Barcelona, Catalonia 08034
	Spain		Spain
	Email: acabello@ac.upc.edu		Email: acabello@ac.upc.edu
End of changes. 79 change blocks.
	125 lines changed or deleted		452 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/