idnits 2.17.1 draft-paillisse-sidrops-blockchain-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 28, 2018) is 2122 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-15) exists of draft-irtf-cfrg-vrf-01 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Paillisse 3 Internet-Draft UPC-BarcelonaTech 4 Intended status: Informational A. Rodriguez-Natal 5 Expires: December 30, 2018 V. Ermagan 6 F. Maino 7 Cisco Systems 8 L. Vegoda 9 Individual 10 A. Cabellos 11 UPC-BarcelonaTech 12 June 28, 2018 14 An analysis of the applicability of blockchain to secure IP addresses 15 allocation, delegation and bindings. 16 draft-paillisse-sidrops-blockchain-02 18 Abstract 20 This document analyzes how blockchain technology can be used to 21 secure the allocation, delegation and binding to topological 22 information of the IP address space. The main outcomes of the 23 analysis are that blockchain is suitable in environments with 24 multiple distrusting parties and that Proof of Stake is a potential 25 candidate for a consensus algorithm. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on December 30, 2018. 44 Copyright Notice 46 Copyright (c) 2018 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 63 3. Blockchain in a nutshell . . . . . . . . . . . . . . . . . . 3 64 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3.1.1. Chain of signatures . . . . . . . . . . . . . . . . . 4 66 3.1.2. Consensus algorithm . . . . . . . . . . . . . . . . . 5 67 3.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.3. Description of consensus algorithms . . . . . . . . . . . 7 69 3.3.1. Proof of Work (PoW) . . . . . . . . . . . . . . . . . 7 70 3.3.2. Proof of Stake (PoS) . . . . . . . . . . . . . . . . 8 71 4. Blockchain for IP addresses . . . . . . . . . . . . . . . . . 9 72 4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 9 73 4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4.3. A consensus algorithm for IP addresses . . . . . . . . . 10 75 5. Overview of the architecture . . . . . . . . . . . . . . . . 11 76 5.1. Support for IPv6 and AS numbers . . . . . . . . . . . . . 13 77 5.2. Pros and cons . . . . . . . . . . . . . . . . . . . . . . 14 78 5.3. Security evaluation . . . . . . . . . . . . . . . . . . . 16 79 5.3.1. Attacks against a PoS-based consensus algorithm . . . 16 80 5.3.2. Attacks against the P2P network . . . . . . . . . . . 17 81 6. Revocation . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 6.1. Expiration time . . . . . . . . . . . . . . . . . . . . . 20 83 6.2. Multi-signature transactions . . . . . . . . . . . . . . 20 84 6.3. Revocation transaction . . . . . . . . . . . . . . . . . 20 85 6.4. Heartbeat transaction . . . . . . . . . . . . . . . . . . 20 86 6.5. Out-of-band mechanisms . . . . . . . . . . . . . . . . . 21 87 6.6. A simple revocation protocol . . . . . . . . . . . . . . 21 88 7. Other Considerations . . . . . . . . . . . . . . . . . . . . 21 89 7.1. Storage management . . . . . . . . . . . . . . . . . . . 21 90 7.2. Proof of Networking? . . . . . . . . . . . . . . . . . . 22 91 7.3. Configuration parameters . . . . . . . . . . . . . . . . 23 92 7.4. PoS algorithm design particularities . . . . . . . . . . 23 93 7.5. Candidate PoS consensus algorithms . . . . . . . . . . . 24 94 7.6. Privacy concerns . . . . . . . . . . . . . . . . . . . . 25 95 7.7. Governance . . . . . . . . . . . . . . . . . . . . . . . 26 96 8. Implementations . . . . . . . . . . . . . . . . . . . . . . . 26 97 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 98 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 26 100 12. Informative References . . . . . . . . . . . . . . . . . . . 27 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 Blockchain [Bitcoin] is attracting a lot of attention among the 106 security community since it provides means for exchanging information 107 among a set of distrusting entities without the use of digital 108 certificates and centralized control. Blockchain provides means for 109 the distrusting parties to reach consensus in a distributed way. 110 Formally, it is regarded as a new solution to the Byzantine Generals 111 problem, well-known in fault-tolerant distributed systems 112 [Byzantine]. 114 Although at the time of this writing the main application of 115 blockchain are financial systems, their use in the field of 116 networking is being explored (e.g., [Hari2016]). Some successful 117 systems exist such as [Blockstack] and [Namecoin], which aim at 118 building a secure naming system, providing a similar functionality to 119 that of DNSSEC. 121 The main goal of this document is to represent a first step towards 122 the understanding of the properties of blockchains and their 123 applicability in the Internet infrastructure, specifically securing 124 the allocation, delegation and bindings of IP addresses. First, it 125 introduces blockchain, then it analyzes how blockchain could be used 126 to secure the delegation of IP addresses. Finally, it presents an 127 initial design for such an infrastructure. This document also 128 includes a preliminary security analysis of such system. It is 129 important to note that the goal of this document is not to provide a 130 complete architecture that secures IP address allocation, delegation 131 and bindings. 133 2. Definition of Terms 135 TBC 137 3. Blockchain in a nutshell 138 3.1. Overview 140 Conceptually, a blockchain is a distributed, secure and trustless 141 database. It can also be regarded as a state machine with rules that 142 clearly state which transitions can be performed. Participants in 143 the blockchain communicate through a P2P network. The smallest data 144 unit of a blockchain is a transaction. Users attach data to a 145 transaction along with its signature and their associated public key. 146 Usually, the attached data is an asset or a token, something that is 147 unique and should not be replicated (e.g., coins in Bitcoin). Then 148 they broadcast this transaction to the other participants. The rest 149 of the nodes in the network temporarily store this transaction. At 150 some fixed intervals in time, one of the nodes takes a set of these 151 transactions and groups them in a block. It then broadcasts this 152 block back to the network. When the other nodes receive this block 153 they verify it, remove the transactions contained in the block from 154 the temporary storage and add it after the previous block, thus 155 creating a chain of blocks. It should be noted that all nodes store 156 the entire blockchain locally. In addition, most blockchains give 157 some sort of reward to nodes that add new blocks, although this is 158 not strictly necessary. Figure 1 presents an overview of the most 159 common elements in a block. 161 +--------+---------------+----------------+---------------+ 162 | Block | Hash(Previous | Hash(All Block | Block Creator | 163 | Number | Block) | Transactions) | Signature | 164 +--------+---------------+----------------+---------------+ 165 | Transaction 1 | 166 +---------------------------------------------------------+ 167 | Transaction 2 | 168 +---------------------------------------------------------+ 169 + ... + 170 + ... + 171 +---------------------------------------------------------+ 172 | Transaction N | 173 +---------------------------------------------------------+ 175 Figure 1.- Common structure of a block 177 Two basic mechanisms are used to protect the chained data: a chain of 178 signatures and a consensus algorithm. 180 3.1.1. Chain of signatures 181 The chain of signatures operates at transaction level. Consider the 182 sender and receiver of a token, each with its public-private keypair. 183 To change the owner of a token, the sender signs the data and the 184 receiver's public key. It then puts together its public key, the 185 signature, the data and the hash of the receiver's public key (Figure 186 2) to form a transaction. 188 +-------------+-------------------+--------+---------------+ 189 | Sender | Signature Sender | Data | Hash(Receiver | 190 | Public Key | Private Key | | Public Key) | 191 +-------------+-------------------+--------+---------------+ 193 Figure 2.- Common transaction structure in a blockchain 195 In conclusion, the rules of the blockchain enforce that: 197 o The owner of the receiver private key has total control over the 198 contents of the transaction. In Bitcoin this translates in a 199 central property: only this owner can spend a coin. 201 o When an owner sends a token to the new owner, it irreversibly 202 transfers the control of the contents to the new owner. 204 3.1.2. Consensus algorithm 206 The consensus algorithm is the central part of blockchain and it 207 controls the chaining of data blocks. The main role of the algorithm 208 is to provide a set of well-defined rules so that participants agree 209 on a consistent view of the database. For this it has the following 210 main functions. First, forks (multiple chains) can exist. This may 211 happen for instance due to varying network latency among 212 participants. In this case the participants must agree on which is 213 the valid chain. And second, another important function of the 214 consensus algorithm is to determine which participants are allowed to 215 add new data blocks. Section 3.3 contains more information regarding 216 available consensus algorithms. 218 It is important to note that regardless of the consensus algorithm, 219 in blockchain data blocks are always added, never deleted nor 220 modified. This creates a tamper-proof, shared ledger among all 221 participants. Transactions can be tracked back by inspecting past 222 blocks, thus enabling the verification of claims by certain parties. 224 3.2. Features 226 The following list tries to briefly summarize the main 227 characteristics of the blockchain technology: 229 Decentralized: No central entity controls the blockchain, it is 230 shared among all participants. 232 No CAs: No digital certificates, Certification Authorities or CRLs 233 are needed. 235 Limited prior trust: It is not required to trust other nodes. It is 236 worth noting that some consensus algorithms rely on some limited 237 levels of trust. 239 Tamper-proof: Since data can be only added but never modified, 240 attempts to alter previous records are detected. 242 Non-repudiation: All nodes share a common, immutable view on the 243 status of the blockchain, and blockchain provides non-repudiation 244 mechanisms. 246 Censorship-resistant: Gaining control over a transaction involves 247 having access to the associated private key. 249 Append-only: Data is always added, but never modified nor deleted. 251 Privacy: Entities participating in the blockchain can achieve 252 privacy using anonymous keys, i.e. randomly-generated keys not 253 related to their identity. In addition, a new keypair should be 254 generated for each new transaction in order to prevent tracking 255 [Bitcoin], section 10. 257 Slow updates: New transactions have to be verified, added to a block 258 and received by all nodes. This results in a delay since the 259 transaction is created until it is finally available to all the 260 nodes. This delay will depend on the consensus algorithm and the 261 block creation rate. 263 Large storage: The size of the blockchain keeps growing forever, 264 because data blocks are always added. This may result in 265 scalability issues. 267 3.3. Description of consensus algorithms 269 The two more popular consensus algorithms are: Proof of Work and 270 Proof of Stake. 272 3.3.1. Proof of Work (PoW) 274 In Proof of Work nodes have to solve a complex mathematical problem 275 to add a block, requiring some computational effort. This is 276 commonly known as mining. For example in Bitcoin the problem is to 277 find a hash starting with a fixed amount of zeroes, the only known 278 way to solve this problem is by brute force. The valid chain is the 279 one with most accumulated computing power, this chain is also the 280 more expensive in terms of computing power to modify. This is 281 because modifying a block going N blocks back from the tip of the 282 chain would require redoing the computations for all these N blocks. 283 As a result, an attacker should have more computational power than 284 the power required to create the N blocks to be able to modify the 285 chain. Overall, it is commonly assumed that if more than half of the 286 nodes are honest, the blockchain is considered secure. 288 PoW offers relevant features, adding new blocks requires an external 289 resource (CPU power) that has an economical cost. However this also 290 results in some relevant drawbacks: 292 Risk of takeover: The security of PoW is entirely based on 293 computation power. This means that if an entity has access to 294 more than half of the total blockchain's computing power it can 295 control the chain. As a result and in order to keep blockchain 296 secure, the incentive of taking control of the chain must be lower 297 than the cost of acquiring and operating the hardware that 298 provides the equivalent to half of the participants computing 299 power. This is hard to guarantee since the economy of the 300 blockchain and the economy of the required hardware are 301 independent. As an example an attacker can acquire the required 302 hardware and operate it, take control of the blockchain to obtain 303 an economical benefit and finally sell the hardware to reduce the 304 final cost of the attack. 306 Hardware dependency: Bitcoin automatically increases -over time- the 307 complexity of the mathematical problem that needs to be solved in 308 order to add a block. This is done to account for Moore's law. 309 As a result the community has designed mining specific hardware 310 (ASICs) that provides a competitive advantage. In this context 311 blockchain becomes less democratic, since the cost of 312 participating in it increases. On the other hand, several ASIC- 313 resistant algorithms are in use in various cryptocurrencies. This 314 is usually achieved with memory-intensive calculations or 315 frequently changing the mining algorithm. Although they appear to 316 be a promising alternative, vendors react by developing a silicon 317 implementation of the algorithm. In this situation, the 318 developers usually change the algorithm by means of a hard fork 319 [monero]. Ultimately, this becomes an arms-race. 321 Energy inefficiency: PoW requires large amounts of energy to perform 322 the computations (e.g., [miningfarm]). 324 3.3.2. Proof of Stake (PoS) 326 The main idea behind Proof of Stake is that participants with more 327 assets (or stake) in the blockchain are more likely to add blocks. 328 With this, the control of the chain is given to entities who own more 329 stake. For each new block, a signer is pseudo-randomly selected from 330 the list of participants typically weighted according to their stake. 331 A fundamental assumption behind PoS is that such entities have more 332 incentives for honest behaviour since they have more assets in the 333 chain. 335 Proof of Stake is seen as an alternative to PoW. At the time of this 336 writing, major players in the blockchain environment (such as 337 [Ethereum]) are preparing a shift towards PoS. Moreover, several 338 blockchains based on PoS already exist (eg. [Peercoin]). The main 339 reason behind this paradigm shift is that PoS addresses some of PoW's 340 main drawbacks: 342 o It does not require special hardware nor computationally or 343 energy-expensive calculations. 345 o An attacker must get hold of a significant part of the assets in 346 order to gain control of the blockchain. As opposed to PoS the 347 investment required to gain control of the chain lies within the 348 chain, and does not involve using external resources. 350 On the other side, Proof of Stake introduces new sources of attacks: 352 o In Proof of Stake the signer is selected randomly among the 353 stakers. In this context attackers can manipulate the source of 354 randomness to sign more blocks and ultimately gain control over 355 the chain. 357 o As opposed to PoW, creating forks is very inexpensive, since no 358 computational power is required. The PoS must provide means to 359 select the valid chain, which is typically the longer one. 361 o Collusions of high-stakers can create alternate chains which can 362 appear to be valid. 364 4. Blockchain for IP addresses 366 4.1. Problem statement 368 The objective of this section is to analyze if an infrastructure 369 using blockchain can provide a similar degree of security to 370 traditional PKI-based architectures. Specifically we aim to secure: 372 o Binding of IP address blocks to the holder (private key holder). 374 o The allocations and delegations of IP address blocks among their 375 holders. 377 o Binding of IP address blocks to their topological locators (eg. 378 AS numbers allocations). 380 This information is public and shared among a set of distrusting 381 entities over the Internet. The architecture must be able to: 383 o Allow anyone to verify the legitimate holder of a block of 384 addresses 386 o Let participating entities allocate address blocks without 387 requiring a trusted third party. 389 o Restrict the allocation of a block of addresses to only its 390 legitimate holder. 392 o Prevent data modification without the consent of its holder. 394 4.2. Analysis 396 The main rationale behind using blockchain to secure IP address 397 allocations is that IPs can be understood as coins, both concepts 398 share some fundamental characteristics: 400 o They are unambiguously allocated to entities. 402 o Can be transferred between them. 404 o Cannot be assigned to two entities at the same time. 406 o Can be divided up to a certain limit. 408 Such similar properties make it possible to envisage a blockchain 409 that allows its participants delegate IP address blocks, similarly to 410 how Bitcoin transfers coins. For example, IANA could write a 411 transaction allocating addresses to the RIRs, which in turn could 412 allocate them to the LIRs, etc. Complex management logic can be 413 defined as needed. (For example, rejecting a transaction that 414 allocates of a block of addresses originated by an entity that does 415 not hold that block.) In addition, transactions accept multiple 416 inputs and outputs, i.e. an arbitrary amount of public keys either 417 as senders or receivers. This means that it is possible to break and 418 merge blocks of addresses as required. Section 5 provides more 419 detailed information about this architecture. 421 4.3. A consensus algorithm for IP addresses 423 As stated before, the consensus algorithm is a central part of a 424 blockchain. The first consensus algorithm designed for blockchain 425 was PoW, and it is a common choice for new blockchain 426 implementations. However it presents several drawbacks 427 (Section 3.3.1) for the IP address scenario. 429 Using computing power as a means to secure blockchains has been 430 proved to work in financial environments. However, the capability to 431 add new blocks and the security of the chain itself depends on the 432 computing power of the participants, which is not always aligned with 433 their interest in the well-being of the blockchain. Depending on the 434 objectives of the attacker, certain attacks can become profitable. 435 Namely, buying a large quantity of hardware to be able to rewrite the 436 blockchain with false data (e.g., incorrect delegations of IP 437 addresses). This is because the incentives of the participants of 438 the IP addresses blockchain are not linked with their computing 439 power. 441 In contrast, with Proof of Stake the capability to alter the 442 blockchain remains within it. This aspect is of particular 443 importance in the context of securing IP addresses: it would mean 444 that entities holding large blocks of IP addresses are more likely to 445 add blocks. These parties have a reduced incentive in tampering the 446 blockchain because they would suffer the consequences: an insecure 447 Internet. Typically entities that hold large blocks of the IP 448 address space have their business within the Internet and as such, 449 have clear incentives in the correct operation and security of the 450 Internet. 452 Furthermore, in such blockchain the risk of takeover is reduced 453 compared to PoW. The reason is that accumulating a large amount of 454 IP addresses is typically more complex than accumulating computing 455 power. The risk of takeover is also mitigated compared to other PoS- 456 based blockchains. In this blockchain an attacker would buy tokens 457 from the other parties, who receive a monetary compensation to 458 participate in the attack. However, in a blockchain for IP addresses 459 this would mean buying IP addresses from other parties, who do not 460 have a clear incentive to sell their blocks of addresses to the 461 attacker. Because of this, PoS appears to be a firm candidate for a 462 consensus algorithm in a blockchain for securing IP addresses 463 allocations and delegations. 465 5. Overview of the architecture 467 This architecture mimics the hierarchy of IP address allocation 468 present in today's Internet, with IANA on top of it. All nodes trust 469 IANA's public key, which writes a genesis transaction assigning all 470 of the address space to itself (figure 3). 472 +--------------+-----------------+-----------+----------------+ 473 | IANA | Signature IANA | Allocate | Hash(IANA | 474 | Public Key 1 | Private Key 1 | 0/0 | Public Key 2) | 475 +--------------+-----------------+-----------+----------------+ 477 Figure 3.- Genesis transaction 479 It then begins allocating each block of addresses to the IP address 480 holders. Each transaction allocates part of the address space to the 481 legitimate holder, and the rest of space is given back to IANA using 482 a new keypair (figure 4). 484 +--------------+-----------------+-----------+----------------+ 485 | | | Rest of | Hash(IANA | 486 | IANA | Signature IANA | space | Public Key 3) | 487 | Public Key 2 | Private Key 2 +-----------+----------------+ 488 | | | Allocate | Hash(APNIC | 489 | | | 1/8 | Public Key 1) | 490 +--------------+-----------------+-----------+----------------+ 492 Figure 4.- Example allocation transaction 494 In turn, all the parties in the hierarchy allocate or delegate 495 address blocks following the current allocation hierarchy. When a 496 party wants to verify the allocation of a block of addresses, it 497 downloads the blockchain and verifies all the blocks and transactions 498 up to the genesis block, for which it has trust. Figure 5 presents 499 an example of allocation of one prefix to each of the RIRs. 501 +--------------+-----------------+-----------+----------------+ 502 | | | Rest of | Hash(IANA | 503 | | | space | Public Key 4) | 504 | | +-----------+----------------+ 505 | | | Allocate | Hash(RIPE | 506 | | | 5/8 | Public Key 1) | 507 | | +-----------+----------------+ 508 | | | Allocate | Hash(APNIC | 509 | IANA | Signature IANA | 14/8 | Public Key 2) | 510 | Public Key 3 | Private Key 3 +-----------+----------------+ 511 | | | Allocate | Hash(ARIN | 512 | | | 23/8 | Public Key 1) | 513 | | +-----------+----------------+ 514 | | | Allocate | Hash(AFRINIC | 515 | | | 102/8 | Public Key 1) | 516 | | +-----------+----------------+ 517 | | | Allocate | Hash(LACNIC | 518 | | | 200/8 | Public Key 1) | 519 +--------------+-----------------+-----------+----------------+ 521 Figure 5.- Example multi-output allocation transaction 523 Inside the blockchain the typical operations to manage blocks of IP 524 addresses can be defined, such as the delegation of prefixes (figure 525 6). This helps to enforce the rules of IP addresses management. For 526 instance, since this transaction is marked as a delegation, if the 527 new owner created an allocation transaction it would be rejected by 528 the other nodes, because the parent transaction does not have the 529 privileges to perform it. 531 +--------------+-----------------+-----------+----------------+ 532 | | | Rest of | Hash(APNIC | 533 | APNIC | Signature APNIC | space | Public Key 3) | 534 | Public Key 1 | Private Key 1 +-----------+----------------+ 535 | | | Delegate | Hash(ISP A | 536 | | | 1.2/16 | Public Key 1) | 537 +--------------+-----------------+-----------+----------------+ 539 Figure 6.- Example delegation transaction 541 Performing a key rollover is simple, because each transaction has its 542 associated public key, and only depends on the previous transaction. 543 In other words, rekeying means changing the public key only in the 544 holder's transaction. This can be done adding a new transaction with 545 the same data but transferring it to a new public key also controlled 546 by the initial holder (figure 7). This approach lets each entity 547 decide its rekeying policies independently. 549 +--------------+-----------------+-----------+----------------+ 550 | ISP A | Signature ISP A | Delegate | Hash(ISP A | 551 | Public Key 1 | Private Key 1 | 1.2/16 | Public Key 2) | 552 +--------------+-----------------+-----------+----------------+ 554 Figure 7.- Example key rollover of a prefix delegation 556 It is worth noting that this chain can define as many operations as 557 required, for instance storing the binding of AS numbers to the IP 558 prefixes they announce (figure 8). 560 +--------------+-----------------+-----------+----------------+ 561 | | Signature | Bind | | 562 | ISP A | ISP A | 1.2/16 | Hash(ISP A | 563 | Public Key 2 | Private Key 2 | AS no. | Public Key 3) | 564 | | | 12345 | | 565 +--------------+-----------------+-----------+----------------+ 567 Figure 8.- Example binding of AS number to prefix 569 Additional and more complex operations can be defined if the 570 management logic requires it. For instance, several signatures (from 571 different parties) can be required to consider a transaction valid, 572 restrict permissions for customer sub-delegations, etc. 574 5.1. Support for IPv6 and AS numbers 576 The allocation and delegation of IPv6 addresses and AS numbers is 577 equivalent to that of IPv4, maintaining the IANA -> RIR -> LIR 578 hierarchy. For example, for IPv6: 580 +--------------+------------------+-----------+----------------+ 581 | IANA v6 | Signature IANA | Allocate | Hash(IANA v6 | 582 | Public Key 1 | v6 Private Key 1 | 0::/0 | Public Key 2) | 583 +--------------+------------------+-----------+----------------+ 585 +--------------+------------------+-----------+----------------+ 586 | | | Rest of | Hash(IANA v6 | 587 | IANA v6 | Signature IANA | space | Public Key 3) | 588 | Public Key 2 | v6 Private Key 2 +-----------+----------------+ 589 | | | Allocate | Hash(IANA v6 | 590 | | | 2000::/3 | Public Key 4) | 591 +--------------+------------------+-----------+----------------+ 593 +--------------+------------------+------------+------------------+ 594 | | | Rest of | Hash(IANA v6 | 595 | IANA v6 | Signature IANA | space | Public Key 5) | 596 | Public Key 4 | v6 Private Key 2 +------------+------------------+ 597 | | | Allocate | Hash(AFRINIC v6 | 598 | | | 2c00::/12 | Public Key 1) | 599 +--------------+------------------+------------+------------------+ 601 +--------------+-------------------+-----------+-----------------+ 602 | | | Rest of | Hash(AFRINIC v6 | 603 | AFRINIC v6 | Signature AFRINIC | space | Public Key 2) | 604 | Public Key 1 | v6 Private Key 1 +-----------+-----------------+ 605 | | | Allocate | Hash(ISP A v6 | 606 | | | 2c0c::/15 | Public Key 1) | 607 +--------------+-------------------+-----------+-----------------+ 609 Figure 9.- IPv6 allocation transactions. From top to bottom: 610 genesis transaction, global unicast allocation, AFRINIC allocation 611 and LIR allocation. 613 The process is equivalent for AS numbers. Besides, in the context of 614 a multi-signature scheme, it is also possible to ask the holder of 615 the AS number to confirm the binding of its AS number to a particular 616 prefix. 618 5.2. Pros and cons 620 In this section we analyze the pros and cons of this architecture 621 compared to traditional PKI infraestructures: 623 Advantages: 625 o Decentralized: No central entity controls the blockchain, it is 626 shared among all participants. 628 o No CAs, CRLs or certificates needed: No digital certificates, 629 Certification Authorities or CRLs are needed. 631 o Simplified rekeying: A key rollover can easily be performed by 632 issuing a new transaction allocating the prefixes to a new keypair 633 controlled by the same holder. This process can be performed 634 without involving any third-party. 636 o Censorship-resistant: since the control of a transaction is 637 completely under the holder of the private key, the revocation of 638 IP addresses without the legitimate holder's permission involves 639 obtaining its private key. Even if the private key of the 640 previous owner was compromised, ownership of the current 641 transaction is still preserved, as opposed to the compromise of a 642 CA's private key (or a misbehaving CA). 644 o Limited prior trust: It is not required to trust other nodes. 645 However, in PoS it is necessary to periodically authenticate the 646 chain state out-of-band to prevent some attacks. 648 o Simplified management: since CAs are not required, their 649 management overhead is avoided. 651 o Auditable: allocations and delegations can be tracked back in the 652 blockchain to determine if they originate from the legitimate 653 holder. 655 o Limited legal liability: since users control their private keys, 656 Internet Registries cannot be held legally responsible of their 657 loss. In turn, this can foster the creation of a unified registry 658 instead of the current five. Ultimately, this would ease cross- 659 registry resource transfers. 661 o No single point of failure: again, due to the fact that each user 662 controls its private key, the compromise of a user's key does not 663 compromise the entire system. This starkly contrasts with the 664 compromise of a CA, which can potentially invalidate all 665 downstream certificates. 667 o Simplified state update: PKIs need specific subsystems to update 668 its state (e.g. issue/revoke certificates). On the other hand, 669 in a blockchain all these operations are embedded in it thanks to 670 its transactional nature. 672 Drawbacks: 674 o PoS does not rely on strong cryptographic guarantees: As opposed 675 to PKI-based systems that rely on strong and well-established 676 cryptographic mechanisms, PoS-based infraestructures ultimately 677 rely on the good behaviour of the high-stakers. 679 o Costly bootstrapping: When a node is activated it has to download 680 and verify the entire blockchain. 682 o Large storage required: The blockchain grows forever as more 683 blocks are added, blocks cannot be removed. 685 5.3. Security evaluation 687 5.3.1. Attacks against a PoS-based consensus algorithm 689 This section presents a list of the most relevant attacks against a 690 Proof of Stake algorithm and how to mitigate them. 692 5.3.1.1. Stake grinding 694 Stake grinding refers to the manipulation of the consensus algorithm 695 in order to progressively obtain more stake, with the goal of signing 696 blocks more frequently with the ultimate goal of taking control of 697 the blockchain. It proceeds as follows: when the attacker has to 698 sign a block, it computes all the possible blocks (varying the data 699 inside them) to find a combination that gives the highest possibility 700 of signing another block in the future. It then signs this block and 701 sends it to the network. This procedure is repeated for all the next 702 signing opportunities. Over time, the attacker will sign more and 703 more blocks until the consensus algorithm will always select the 704 attacker to sign all blocks, thereby having taken control of the 705 blockchain. 707 To prevent this attack, the source of randomness used to select the 708 signers has to be hard to alter or to predict. 710 5.3.1.2. Nothing at stake 712 Nothing at stake is one of the fundamental drawbacks of Proof of 713 Stake and requires careful design based on the incentives of the 714 participants. In common PoS designs, the signers of the new block 715 receive an economical incentive (e.g., Ethereum). However this does 716 not hold in the IP address scenario, since participants should not 717 receive any incentive. The incentive is, as stated before, achieving 718 a consistent view of the IP address space and having a secure 719 Internet. 721 5.3.1.3. Range attacks 723 A range attack is performed by creating a fork some blocks back from 724 the tip of the chain. It is conceptually similar to the attack named 725 as 'Risk of takeover' in Section 3.3.1. In this scenario, the 726 attacker has privately fabricated a chain which (according to the 727 consensus algorithm rules) will be selected over the original one. 728 Benefits of this attack include gaining more stake on the blockchain 729 (this attack could be part of a stake grinding attack) or rewriting 730 the transaction history to erase a payment made in the original 731 blockchain. 733 The simplest solution to this attack is adding a revert limit to the 734 blockchain, forbidding forks going back more than N blocks. This 735 provides a means to solidify the blockchain. However, nodes that 736 have been offline for more than N blocks will need an external source 737 that indicates the correct chain. It has been proposed to do this 738 out of band. This is why a PoS blockchain is not purely trustless 739 and requires a small amount of trust. 741 5.3.1.4. Monopolies 743 A monopoly refers to a single party controlling enough IP addresses 744 so it can sign a significant proportion of new blocks, thus being 745 able to decide which information is written in the chain (e.g., a 51 746 % attack in Bitcoin). However and in this use-case, this is of less 747 concern since parties do not have a clear incentive to alter normal 748 chain operation. In order to successfully launch this attack a party 749 should control more than 50% of the IP blocks, while this is 750 difficult to achieve and participants do not have a clear incentive 751 to sell/give away blocks of IPs, the attacker would also impact its 752 own infrastructure, making the Internet less secure. Section 7.4 753 contains more details regarding monopolies. 755 5.3.1.5. Lack of participation 757 Participants in a PoS algorithm will not always sign a block, since 758 they might be offline when they are selected or lack incentives. 759 Because of this, the final fraction of high-stakers that sign blocks 760 can be very different from the full set of high-stakers. The direct 761 consequence of this situation is that the portion of participants 762 that decide what goes into the blockchain can be a small set of 763 nodes. If this participation is low enough, it can leave the control 764 of the blockchain to a small amount of people/oligarchy, thus rising 765 security concerns. 767 5.3.2. Attacks against the P2P network 768 This section presents attacks directed towards the underlying P2P 769 network used to exchange information among the participants of the 770 blockchain. 772 5.3.2.1. DDOS attacks 774 Since blockchains are inherently based on P2P architectures, they 775 present a higher degree of resistance to DDOS attacks than 776 centralized server architectures, provided that the network has a 777 significant number of participants. In addition, it is always 778 possible to keep an offline copy of the blockchain. 780 5.3.2.2. Transaction flooding 782 A special type of DDOS attack consists in creating a large amount of 783 legit transactions that transfer a small amount of tokens (i.e. 784 delegate a lot of small IP prefixes). If the number of transactions 785 is large enough, the addition of new transactions can be 786 significantly delayed because not all of them fit into a single 787 block. The effectiveness of the attack also depends on the 788 throughput of the blockchain (transactions/second). Simple solutions 789 may be to limit the granularity upon which IP addresses can be split. 790 Of course, only the legitimate holder of a large amount of IP address 791 can perform this attack. 793 5.3.2.3. Routing attacks 795 The underlying P2P network in blockchains does not typically use any 796 security mechanism, e.g. node authentication or integrity of network 797 protocol messages. This enables potentially disruptive attacks. For 798 example, specially located rogue nodes could drop new transactions, 799 which would block updates on the blockchain and leave legit nodes 800 uncommunicated. The effectiveness of this kind of attacks depends on 801 how the P2P algorithm selects peers and the topology of the P2P 802 network. 804 However, the most potentially dangerous attack of this type are 805 network partitions, i.e. isolating a group of nodes from the rest of 806 the network so they cannot communicate each other (e.g., 807 [Apostolaki2017]). The consequence of this attack is that two 808 versions of the blockchain are created, one at each network 809 partition. When the partition disappears and the nodes reconnect one 810 of the two chains will be discarded, causing a service disruption. 811 It is worth noting that Bitcoin has suffered similar attacks 812 [realrouteattack]. 814 5.3.2.4. Transaction censorship 815 When a node adds a block it chooses arbitrarily which transactions 816 are added into it, i.e. no specific rules control how transactions 817 are added to a block. This enables a node to selectively add some 818 transactions and intentionally exclude others, with the consequence 819 that some transactions may be never added to the blockchain. In the 820 context of IP addresses, this may be performed by a competing ISP to 821 prevent another ISP from executing a certain modification. Possible 822 solutions revolve around: 824 o Giving more priority to older transactions (similarly to Bitcoin). 826 o Punishing nodes that exhibit this kind of behaviour, e.g. 827 removing part of their block of IP addresses or lowering their 828 chance of adding blocks. 830 6. Revocation 832 Due to the irreversible nature of transactions, once a block of IP 833 addresses has been allocated to an entity it is not possible to 834 modify or remove it, as opposed to CRLs (Certificate Revocation 835 Lists). However, due to operational issues (compromised or lost 836 keys, human mistake, holder misbehaviour, etc) it is critical to 837 provide a way to recover a block of addresses. Moreover, since IP 838 addresses are a finite public good they cannot be lost. Taking into 839 account that a blockchain can enforce any rules its participants 840 agree upon, this section presents some possible approaches to 841 implement revocation, such approaches should not be considered as 842 mutually exclusive. The revocation procedure must be discussed among 843 the community to achieve consensus between the relevant players 844 (IANA, RIRs, ISPs, institutions, etc). 846 All these mechanisms present different balances of power between the 847 current holder and the entity whose asset is being revoked. Behind 848 all these mechanisms there is a fundamental tradeoff between trusting 849 an upstream provider of the addresses and retaining full control of 850 the block of addresses. 852 Regardless of the revocation policy and as opposed to traditional PKI 853 systems, each IP prefix delegation only depends on the private key of 854 the holder of such IP block. As such, it does not need to trust a CA 855 or a chain of certificates. Only by means of this private key the IP 856 delegation can be altered. 858 6.1. Expiration time 860 A simple approach to allow revocation is adding a lease time (i.e, 861 time-to-live) to the blocks of addresses. After the lease ends, the 862 new holder of the address block automatically becomes the previous 863 one, or addresses are transferred to a default holder. As stated 864 before, this revocation procedure should be enforced by the rules of 865 the blockchain, this means that participants would not recognise 866 expired allocations as valid. 868 6.2. Multi-signature transactions 870 A multi-signature transaction is a transaction with more than one 871 associated public key. In other words, a transaction is considered 872 valid if it has, for instance, 2 out of 5 valid signatures. This 873 way, 3 keys can be lost but with the renaming 2 keys the block of 874 addresses can be recovered. This approach exemplifies the 875 aforementioned tradeoff in trust, since the holder of the block of 876 addresses must trust the owners of the keys participating in the 877 multi-signature transaction. For instance, if some of these keys are 878 owned by IANA or an Internet Registry, we can return part of the 879 control over the allocation to them. 881 6.3. Revocation transaction 883 A simpler approach than multi-signature transactions is creating a 884 'revocation' transaction. When a block of address is required to be 885 reassigned without the consent of the current holder, a revocation 886 transaction (specifying the new holder) is inserted in the 887 blockchain. This transaction should be issued either by a 888 consensuated authority or by a disputing entity. The revocation 889 transaction should be resolved by either accepting the revocation 890 transaction automatically when issued by the accepted authority or by 891 means of out-of-band mechanisms when issued by a disputing party. 893 6.4. Heartbeat transaction 895 Another approach involves issuing a heartbeat transaction every N 896 days, signalling to the network that the holder still owns the key 897 associated with that particular resource. If the holder fails to 898 issue this transaction, the blockchain considers that the resource is 899 automatically returned to the registry. 901 6.5. Out-of-band mechanisms 903 Disputes regarding transactions can be resolved by means of out-of- 904 band mechanisms, e.g, discussion, court, etc. In order to reflect 905 the decision of this out-of-band mechanism the blockchain must be 906 modified. Since this represents a deviation from the rules, it must 907 be done through a hard blockchain fork. Although cumbersome and 908 complex, this is feasible from a technical standpoint. 910 6.6. A simple revocation protocol 912 Here we present a simple revocation protocol to handle accidental key 913 loss: 915 1. On detecting the key loss, the holder notifies the registry, e.g. 916 via e-mail. 918 2. The registry issues a revocation transaction, similar to the one 919 in section Section 6.3. 921 3. The current holder has a fixed period of time to issue a 922 transaction re-claiming the resource. This transaction must be 923 signed by the private key associated with the claimed resource. 925 4. If the holder issues the transaction, it retains the resource. 927 5. Otherwise, after the fixed time interval, the blockchain 928 considers that the resource is returned to the registry, so it 929 can be re-allocated. 931 This protocol combines two of the aforementioned techniques, and 932 allows to balance power between resource holders and registries. 933 Registries can revoke lost or unclaimed resources, while address 934 holders can retain them if the registry misbehaves or its key is 935 compromised. However, it should be noted that this protocol does not 936 protect from stolen keys. 938 The time interval can be different depending on the nature of the 939 revocating entity. For example, IANA -> RIR allocations could wait a 940 couple of weeks, whereas RIR -> LIR allocations could go faster with 941 a 72 hours notification period. 943 7. Other Considerations 945 7.1. Storage management 947 The never ending size of the blockchain presents a potential 948 scalability issue. At the time of this writing, mature blockchains 949 like Bitcoin require more than 100 GB of storage. Simply deleting or 950 summarizing old transactions degrades the security of PoW-based 951 chains, since their security relies on the computing power required 952 to generate them. The longer they are, the harder they are to 953 attack. 955 However, PoS-based chains do not rely on computing power and hence, 956 space-saving strategies do not degrade the security. For instance a 957 simple solution could be to, once the PoS-based chain reaches a 958 certain storage size, summarize a subset of the older transactions. 959 In what follows we overview this strategy: 961 +-----+-----+-----+-----+-----------------+-----+-----+-----+ 962 | 0 | 1 | 2 | 3 | ..... |47832|47833|47834| 963 +-----+-----+-----+-----+-----------------+-----+-----+-----+ 965 9.1 Old blockchain 967 +-----+-----+-----+-----+-----+ 968 | r0 | r1 | r2 | r3 | r4 | 969 +-----+-----+-----+-----+-----+ 971 9.2 Write present state to special reset blocks 973 +-----+-----+-----+-----+-----+-----+-----+ 974 | r0 | r1 | r2 | r3 | r4 | 0 | 1 | ... 975 +-----+-----+-----+-----+-----+-----+-----+ 977 9.3 Continue working after the reset blocks 979 Figure 10.- A simple technique to reduce blockchain storage 981 This approach reduces bootstrapping cost, it is worth noting that 982 this strategy requires trust on the reset blocks, such blocks can be 983 obtained with an out-of-band mechanism (see Section 5.3.1.3 for 984 further information). 986 7.2. Proof of Networking? 987 In this section we speculate how one could design an equivalent of 988 Proof-of-Work (PoW) for networks. Conceptually, PoW is a proof of 989 computational resources, can we devise a proof of networking 990 resources? It could be thought that a PoW equivalent may exist in 991 the context of networks, i.e., an equivalent to spending computer 992 cycles in a network. Some resources unique to networks are 993 bandwidth, computation of checksums, number of BGP peers, etc. 994 Hence, we could envisage a blockchain secured by the resources 995 inherent to its participating computer networks. As long as half of 996 the resources were controlled by honest members, security is 997 guaranteed. For example, bandwidth could be a potential candidate; 998 however it does not satisfy two key features present in PoW: 1000 o Asymmetry: the proof has to be hard to generate but fast to 1001 verify. 1003 o Verifiability: it has to be possible to embed the proof in the 1004 block in order to account for the spending of resources. 1006 In this context, Proof-of-Networking is an open research issue . 1008 7.3. Configuration parameters 1010 Configuration parameters refer to a set of values: 1012 o Block creation rate 1014 o Maximum block size 1016 o Other parameters related to the consensus algorithm 1018 These parameters, beyond regulating the operation of the blockchain 1019 also have an influence on its performance. For example, a small 1020 block size increases propagation speed (thus consensus can be reached 1021 faster) but reduces the number of transactions per second that the 1022 blockchain can handle. As an example, in Bitcoin, the 10-minute 1023 block creation rate seeks to balance fast confirmation times and 1024 reduced probability of forks [Antonopoulos2015]. Experimental 1025 deployments and operational requirements should help tuning such 1026 parameters. 1028 7.4. PoS algorithm design particularities 1030 The particular use case of IP addresses presents some characteristics 1031 that the PoS algorithm should take into account: 1033 Monopoly prevention: As described in section Section 5.3.1.4, 1034 monopolies can pose a threat to a PoS blockchain. In order to 1035 prevent a small number of large-stakers from controlling the 1036 chain, we can design the PoS algorithm to have a smart mapping of 1037 IP prefixes to the weight of the random selection. A potential 1038 solution could be fine-tuning the weighting of IP addresses 1039 (slightly biasing the choice towards medium-sized holders), in 1040 order to reduce the power of high stakers. This can provide an 1041 upper-bound of the maximum number of addresses that a party can 1042 hold to avoid monopolies (ideally as high as possible). 1044 IPv6 support: Large parts of the IPv6 address space remain 1045 unallocated and still owned by IANA (at the time of writing this 1046 document, less than 0.5% of v6 address space has been allocated to 1047 the RIRs). The PoS algorithm should ignore this space (not count 1048 it) to avoid IANA signing nearly all v6 blocks and thus, 1049 preventing an IANA monopoly. 1051 IPv4/v6 stake isolation: Since there are more IPv6 addresses than 1052 IPv4, this creates an imbalance of power in a PoS blockchain: 1053 randomly selecting from both pools of addresses naturally causes 1054 v6 holders signing more blocks than v4 holders. Thus, some kind 1055 of isolation between v4 and v6 stake is required. For example, we 1056 could alternatively generate blocks with only v4 or v6 1057 transactions, signed by a v4 or v6 holder, respectively. 1059 7.5. Candidate PoS consensus algorithms 1061 There are several existing PoS algorithms that could satisfy the 1062 requirements of a blockchain for IP addresses. The following list 1063 presents three of them that have been claimed by the authors to be 1064 proven mathematically correct. A substantial difference among them 1065 is the supported portion of offline participants. The list does not 1066 pretend to be exhaustive. 1068 Algorand: [Algorand] leverages a multi-step protocol to provide a 1069 verifiable random selection of the block signer. The most 1070 relevant features of Algorand are: 1072 * A cryptographic sortition mechanism to randomly select the 1073 participants in each step of the protocol, based on Verifiable 1074 Random Functions [I-D.irtf-cfrg-vrf]. 1076 * The decoupling of block creation and block signing, to avoid 1077 stake grinding attacks. 1079 * A new Byzantine Agreement protocol (BA*) to achieve consensus. 1081 * Player replaceability: Algorand uses a different set of 1082 participants for each of its steps. Thus, malicious 1083 participants from one step cannot influence the following. 1085 * Upper bound of 1/3 of dishonest players. 1087 Ouroboros: [Ouroboros] presents a similar approach to Algorand: 1088 first, it selects a subset of users. Then, these users perform 1089 the random selection by means of a secure multiparty computation. 1090 As opposed to Algorand, however, this subset lasts for several 1091 blocks, called epochs. In addition, Ouroboros assumes that the 1092 majority of participants are online when they have to participate 1093 in the protocol, and that they remain offline only short periods 1094 of time. 1096 Snow White: The [SnowWhite] protocol improves on the previous two by 1097 supporting also large amounts of offline participants, as long as 1098 the majority of online members are honest. They call this 1099 property 'Robustly Reconfigurable Consensus'. Snow White also 1100 leverages a random function to decide if a participant has to sign 1101 a block, and defines epochs similarly to Ouroboros: after each 1102 epoch, participants for the new one are calculated. 1104 7.6. Privacy concerns 1106 In order to protect privacy, the blockchain should not contain 1107 Personally Identifiable Information (PII). This is due to the fact 1108 that data in the blockchain cannot be removed and that it is a public 1109 ledger, accessible by anyone. Instead, PII like contact emails or 1110 postal addresses should be stored in the Registry's database (e.g. 1111 RIPE Database). Ideally, the blockchain should contain the minimum 1112 amount of data for correct operation, that is: public keys, blocks of 1113 IP addresses, AS numbers and their bindings (figure 11). 1115 Public Private 1117 +---------------------+ +-----------------------+ 1118 | Blockchain | +-----------+ | Registry Database | 1119 | |<---|Update |<---| | 1120 | Pairs of (Prefix, | |prefix, key| | *Registry Policies | 1121 | Public key) | |pair | | *Contact data | 1122 | | +-----------+ | | 1123 +---------------------+ +-----------------------+ 1125 Figure 11.- Data flow between Registry and blockchain 1127 7.7. Governance 1129 Blockchain does not mean anarchy. In fact, any blockchain requires a 1130 governing entity that determines its rules and ensures that all of 1131 its participants agree on its operation. The need of governance is 1132 illustrated by the recent Bitcoin Cash fork [Bitcoincash]. Due to a 1133 disagreement among Bitcoin users, they created a Bitcoin hard fork 1134 called Bitcoin Cash. This split the Bitcoin blockchain in two, 1135 causing some confusion. Proper governance should avoid such 1136 situations. 1138 This particular use case is not an exception: all concerned parties 1139 (IANA, RIRs, ISPs, etc) should reach consensus regarding which rules 1140 are enforced in the blockchain. For example, dispute resolution or 1141 revocation procedures. 1143 8. Implementations 1145 There are several implementations to secure the allocation of IP 1146 prefixes. They present different scopes and levels of maturity. 1148 o IPchain uses a Proof of Stake algorithm and is specifically 1149 tailored for the allocation of IP addresses. Its performance has 1150 been evaluated [IPchain], and has been open-sourced 1151 [IPchain-repo]. 1153 o [BGPCoin] runs on top of the Ethereum blockchain and provides 1154 similar features to IPchain. It has not been possible to find 1155 open-source code. 1157 o Another project identically named BGPCoin is designed to allow 1158 ISPs to exchange peering agreements and route advertisements by 1159 means of a blockchain [BGPCoin-repo]. It uses a hybrid PoW/PoS 1160 algorithm and has its own cryptocurrency. 1162 9. Security Considerations 1164 This document aims to understand the security implications of using 1165 the blockchain technology to secure IP addresses allocation. 1167 10. IANA Considerations 1169 This memo includes no request to IANA. 1171 11. Acknowledgements 1173 The authors wish to thank Jordi Herrera-Joancomarti, Andreu 1174 Rodriguez-Donaire and Jordi Baylina for their helpful discussions 1175 about Bitcoin and blockchain technology, as well as Marco Chiesa for 1176 the heartbeat transaction idea. 1178 12. Informative References 1180 [Algorand] 1181 Gilad, Y., Hemo, R., Micali, S., Vlachos, G., and N. 1182 Zeldovich, "Algorand: Scaling byzantine agreements for 1183 cryptocurrencies. Proceedings of the 26th Symposium on 1184 Operating Systems Principles (pp. 51-68). ACM.", 2017. 1186 [Antonopoulos2015] 1187 Antonopoulos, A. M., "Mastering Bitcoin, available online: 1188 http://chimera.labs.oreilly.com/books/1234000001802/ 1189 index.html", 2015. 1191 [Apostolaki2017] 1192 Apostolaki, M., Zohar, A., and L. Vanbever, "Hijacking 1193 Bitcoin: Routing Attacks on Cryptocurrencies. 2017 IEEE 1194 Symposium on Security and Privacy (SP). ", 2017. 1196 [BGPCoin-repo] 1197 BGPCoin GitHub repository, , "https://github.com/bgpcoin", 1198 2018. 1200 [BGPCoin] Xing, Q., Wang, B., and X. Wang, "POSTER: BGPCoin: A 1201 Trustworthy Blockchain-based Resource Management Solution 1202 for BGP Security. ACM Conference on Computer and 1203 Communications Security (CCS) 2017", 2017. 1205 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 1206 System. https://bitcoin.org/bitcoin.pdf", 2008. 1208 [Bitcoincash] 1209 Bitcoin split in two, here's what that means, , "http:// 1210 money.cnn.com/2017/08/01/technology/business/bitcoin-cash- 1211 new-currency/index.html", 2017. 1213 [Blockstack] 1214 Ali, et al., M., "Blockstack : A Global Naming and Storage 1215 System Secured by Blockchains, USENIX Annual Technical 1216 Conference", 2016. 1218 [Byzantine] 1219 Lamport, L., Shostak, R., and M. Pease, "The Byzantine 1220 Generals Problem. ACM Transactions on Programming 1221 Languages and Systems", 1982. 1223 [Ethereum] 1224 The Ethereum project, , "https://www.ethereum.org/", 2016. 1226 [Hari2016] 1227 Hari, A. and T. Lakshman, "The Internet Blockchain: A 1228 Distributed, Tamper-Resistant Transaction Framework for 1229 the Internet. Fifteenth ACM Workshop on Hot Topics in 1230 Networks", 2016. 1232 [I-D.irtf-cfrg-vrf] 1233 Goldberg, S., Reyzin, L., Papadopoulos, D., and J. Vcelak, 1234 "Verifiable Random Functions (VRFs)", draft-irtf-cfrg- 1235 vrf-01 (work in progress), March 2018. 1237 [IPchain-repo] 1238 IPchain GitHub repository, , "https://github.com/ 1239 OpenOverlayRouter/blockchain-mapping-system", 2018. 1241 [IPchain] Paillisse, J., Ferriol, M., Garcia, E., Latif, H., Piris, 1242 C., Lopez, A., Kuerbis, B., Rodriguez-Natal, A., Ermagan, 1243 V., Maino, Fabio., and A. Cabellos, "IPchain: Securing IP 1244 Prefix Allocation and Delegation with Blockchain, arXiv 1245 preprint: https://arxiv.org/abs/1805.04439", 2018. 1247 [Namecoin] 1248 Namecoin, , "https://namecoin.org/", 2011. 1250 [Ouroboros] 1251 Kiayias, A., Russell, A., David, B., and R. Oliynykov, 1252 "Ouroboros: A provably secure proof-of-stake blockchain 1253 protocol. Annual International Cryptology Conference (pp. 1254 357-388). Springer, Cham.", 2017. 1256 [Peercoin] 1257 The Peercoin cryptocurrency, , "https://peercoin.net/", 1258 2016. 1260 [SnowWhite] 1261 Bentov, I., Pass, R., and E. Shi, "Snow White: Provably 1262 Secure Proofs of Stake. IACR Cryptology ePrint Archive, 1263 2016, 919.", 2016. 1265 [miningfarm] 1266 Inside a mining farm, , "http://www.bbc.com/future/story/ 1267 20160504-we-looked-inside-a-secret-chinese-bitcoin-mine", 1268 2016. 1270 [monero] Monero PoW algorithm update, , "https://www.ethnews.com/ 1271 monero-team-mulls-changing-pow-algorithm-to-preempt-asic- 1272 miners", 2018. 1274 [realrouteattack] 1275 Hacker Redirects Traffic From 19 Internet Providers to 1276 Steal Bitcoins, , "https://www.wired.com/2014/08/isp- 1277 bitcoin-theft/", 2014. 1279 Authors' Addresses 1281 Jordi Paillisse 1282 UPC-BarcelonaTech 1283 c/ Jordi Girona 1-3 1284 Barcelona, Catalonia 08034 1285 Spain 1287 Email: jordip@ac.upc.edu 1289 Alberto Rodriguez-Natal 1290 Cisco Systems 1291 170 Tasman Drive 1292 San Jose, CA 1293 USA 1295 Email: natal@cisco.com 1297 Vina Ermagan 1298 Cisco Systems 1299 170 Tasman Drive 1300 San Jose, CA 1301 USA 1303 Email: vermagan@cisco.com 1305 Fabio Maino 1306 Cisco Systems 1307 170 Tasman Drive 1308 San Jose, CA 1309 USA 1311 Email: fmaino@cisco.com 1312 Leo Vegoda 1313 Individual 1314 4712 Admiralty Way, #152 1315 Marina del Rey, CA 90292 1316 USA 1318 Email: leo@vegoda.org 1320 Albert Cabellos 1321 UPC-BarcelonaTech 1322 c/ Jordi Girona 1-3 1323 Barcelona, Catalonia 08034 1324 Spain 1326 Email: acabello@ac.upc.edu