idnits 2.17.1 draft-paillisse-sidrops-blockchain-01.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 (October 29, 2017) is 2365 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 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: May 2, 2018 V. Ermagan 6 F. Maino 7 Cisco Systems 8 A. Cabellos 9 UPC-BarcelonaTech 10 October 29, 2017 12 An analysis of the applicability of blockchain to secure IP addresses 13 allocation, delegation and bindings. 14 draft-paillisse-sidrops-blockchain-01.txt 16 Abstract 18 This document analyzes how blockchain technology can be used to 19 secure the allocation, delegation and binding to topological 20 information of the IP address space. The main outcomes of the 21 analysis are that blockchain is suitable in environments with 22 multiple distrusting parties and that Proof of Stake is a potential 23 candidate for a consensus algorithm. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 2, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 3 61 3. Blockchain in a nutshell . . . . . . . . . . . . . . . . . . 3 62 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1.1. Chain of signatures . . . . . . . . . . . . . . . . . 4 64 3.1.2. Consensus algorithm . . . . . . . . . . . . . . . . . 5 65 3.2. Features . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.3. Description of consensus algorithms . . . . . . . . . . . 6 67 3.3.1. Proof of Work (PoW) . . . . . . . . . . . . . . . . . 6 68 3.3.2. Proof of Stake (PoS) . . . . . . . . . . . . . . . . 7 69 4. Blockchain for IP addresses . . . . . . . . . . . . . . . . . 8 70 4.1. Problem statement . . . . . . . . . . . . . . . . . . . . 8 71 4.2. Analysis . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4.3. A consensus algorithm for IP addresses . . . . . . . . . 9 73 5. Overview of the architecture . . . . . . . . . . . . . . . . 10 74 5.1. Pros and cons . . . . . . . . . . . . . . . . . . . . . . 13 75 5.2. Security evaluation . . . . . . . . . . . . . . . . . . . 14 76 5.2.1. Attacks against a PoS-based consensus algorithm . . . 14 77 5.2.2. Attacks against the P2P network . . . . . . . . . . . 16 78 6. Other Considerations . . . . . . . . . . . . . . . . . . . . 17 79 6.1. Revocation . . . . . . . . . . . . . . . . . . . . . . . 17 80 6.1.1. Expiration time . . . . . . . . . . . . . . . . . . . 18 81 6.1.2. Multi-signature transactions . . . . . . . . . . . . 18 82 6.1.3. Revocation transaction . . . . . . . . . . . . . . . 18 83 6.1.4. Out-of-band mechanisms . . . . . . . . . . . . . . . 19 84 6.2. Storage management . . . . . . . . . . . . . . . . . . . 19 85 6.3. Proof of Networking? . . . . . . . . . . . . . . . . . . 20 86 6.4. Configuration parameters . . . . . . . . . . . . . . . . 21 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 90 10. Informative References . . . . . . . . . . . . . . . . . . . 22 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 95 Blockchain [Bitcoin] is attracting a lot of attention among the 96 security community since it provides means for exchanging information 97 among a set of distrusting entities without the use of digital 98 certificates and centralized control. Blockchain provides means for 99 the distrusting parties to reach consensus in a distributed way. 100 Formally, it is regarded as a new solution to the Byzantine Generals 101 problem, well-known in fault-tolerant distributed systems. 103 Although at the time of this writing the main application of 104 blockchain are financial systems, their use in the field of 105 networking is being explored (e.g., [Hari2016]). Some successful 106 systems exist such as [Blockstack] and [Namecoin], which aim at 107 building a secure DNS. 109 The main goal of this document is to represent a first step towards 110 the understanding of the properties of blockchains and their 111 applicability in the Internet infrastructure, specifically securing 112 the allocation, delegation and bindings of IP addresses. First, it 113 introduces blockchain, then it analyzes how blockchain could be used 114 to secure the delegation of IP addresses. Finally, it presents an 115 initial design for such an infrastructure. This document also 116 includes a preliminary security analysis of such system. It is 117 important to note that the goal of this document is not to provide a 118 complete architecture that secures IP address allocation, delegation 119 and bindings. 121 2. Definition of Terms 123 TBC 125 3. Blockchain in a nutshell 127 3.1. Overview 129 Conceptually, a blockchain is a distributed, secure and trustless 130 database. It can also be regarded as a state machine with rules that 131 clearly state which transitions can be performed. Participants in 132 the blockchain communicate through a P2P network. The smallest data 133 unit of a blockchain is a transaction. Users attach data to a 134 transaction along with its signature and their associated public key. 135 Usually, the attached data is an asset or a token, something that is 136 unique and should not be replicated (e.g., coins in Bitcoin). Then 137 they broadcast this transaction to the other participants. The rest 138 of the nodes in the network store temporarily this transaction. At 139 some fixed intervals in time, one of the nodes takes a set of these 140 transactions and groups them in a block. It then broadcasts this 141 block back to the network. When the other nodes receive this block 142 they verify it, remove the transactions contained in the block from 143 the temporary storage and add it after the previous block, thus 144 creating a chain of blocks. It should be noted that all nodes store 145 the entire blockchain locally. In addition, most blockchains give 146 some sort of reward to nodes that add new blocks, although this is 147 not strictly necessary. Figure 1 presents an overview of the most 148 common elements in a block. 150 +--------+---------------+----------------+---------------+ 151 | Block | Hash(Previous | Hash(All Block | Block Creator | 152 | Number | Block) | Transactions) | Signature | 153 +--------+---------------+----------------+---------------+ 154 | Transaction 1 | 155 +---------------------------------------------------------+ 156 | Transaction 2 | 157 +---------------------------------------------------------+ 158 + ... + 159 + ... + 160 +---------------------------------------------------------+ 161 | Transaction N | 162 +---------------------------------------------------------+ 164 Figure 1.- Common structure of a block 166 Two basic mechanisms are used to protect the chained data: a chain of 167 signatures and a consensus algorithm. 169 3.1.1. Chain of signatures 171 The chain of signatures operates at transaction level. Consider the 172 sender and receiver of a token, each with its public-private keypair. 173 To change the owner of a token, the sender signs the data and the 174 receiver's public key. It then puts together its public key, the 175 signature, the data and the hash of the receiver's public key 176 (Figure 2) to form a transaction. 178 +-------------+-------------------+--------+---------------+ 179 | Sender | Signature Sender | Data | Hash(Receiver | 180 | Public Key | Private Key | | Public Key) | 181 +-------------+-------------------+--------+---------------+ 183 Figure 2.- Common transaction structure in a blockchain 185 In conclusion, the rules of the blockchain enforce that: 187 o The owner of the receiver private key has total control over the 188 contents of the transaction. In Bitcoin this translates in a 189 central property: only this owner can spend a coin. 191 o When an owner sends a token to the new owner, it irreversibly 192 transfers the control of the contents to the new owner. 194 3.1.2. Consensus algorithm 196 The consensus algorithm is the central part of blockchain and it 197 controls the chaining of data blocks. The main role of the algorithm 198 is to provide a set of well-defined rules so that participants agree 199 on a consistent view of the database. For this it has the following 200 main functions. First, forks (multiple chains) can exist, this may 201 happen for instance due to varying network latency among 202 participants. In this case the participants must agree on which is 203 the valid chain. And second, another important function of the 204 consensus algorithm is to determine which participants are allowed to 205 add a new data blocks. Section 3.3 contains more information 206 regarding available consensus algorithms. 208 It is important to note that regardless of the consensus algorithm, 209 in blockchain data blocks are always added, never deleted nor 210 modified. This creates a tamper-proof, shared ledger among all 211 participants. Transactions can be tracked back by inspecting past 212 blocks, thus enabling the verification of claims by certain parties. 214 3.2. Features 216 The following list tries to briefly summarize the main 217 characteristics of the blockchain technology: 219 Decentralized: No central entity controls the blockchain, it is 220 shared among all participants. 222 No CAs: No digital certificates, Certification Authorities or CRLs 223 are needed. 225 Limited prior trust: It is not required to trust other nodes. It is 226 worth noting that some consensus algorithms rely on some limited 227 levels of trust. 229 Tamper-proof: Since data can be only added but never modified, 230 attempts to alter previous records are detected. 232 Non-repudiation: All nodes share a common, immutable view on the 233 status of the blockchain, and blockchain provides non-repudiation 234 mechanisms. 236 Censorship-resistant: Gaining control over a transaction involves 237 having access to the associated private key. 239 Append-only: Data is always added, but never modified nor deleted. 241 Privacy: Entities participating in the blockchain can achieve 242 privacy using anonymous keys, i.e. randomly-generated keys not 243 related to their identity. In addition, a new keypair should be 244 generated for each new transaction in order to prevent tracking 245 [Bitcoin], section 10. 247 Slow updates: New transactions have to be verified, added to a block 248 and received by all nodes. This results in a delay since the 249 transaction is created until it is finally available to all the 250 nodes. This delay will depend on the consensus algorithm and the 251 block creation rate. 253 Large storage: The size of the blockchain keeps growing forever, 254 because data blocks are always added. This may result in 255 scalability issues. 257 3.3. Description of consensus algorithms 259 The two more popular consensus algorithms are: Proof of Work and 260 Proof of Stake. 262 3.3.1. Proof of Work (PoW) 264 In Proof of Work nodes have to solve a complex mathematical problem 265 to add a block, thus requiring some computational effort, this is 266 commonly know as mining. For example in Bitcoin the problem is to 267 find a hash starting with a fixed amount of zeroes, the only known 268 way to solve this problem is by brute force. The valid chain is the 269 one with most accumulated computing power, this chain is also the 270 more expensive in terms of computing power to modify. This is 271 because modifying a block going N blocks back from the tip of the 272 chain would require redoing the computations for all these N blocks. 274 As a result, an attacker should have more computational power than 275 the power required to create the N blocks to be able to modify the 276 chain. Overall, it is commonly assumed that if more than half of the 277 nodes are honest the blockchain is considered as secure. 279 PoW offers relevant features, adding new blocks requires an external 280 resource (CPU power) that has an economical cost. However this also 281 results in some relevant drawbacks: 283 Risk of overtaking: The security of PoW is entirely based on 284 computation power. This means that if an entity has access to 285 more than half of the total blockchain's computing power it can 286 control the chain. As a result and in order to keep blockchain 287 secure, the incentive of taking control of the chain must be lower 288 than the cost of acquiring and operating the hardware that 289 provides the equivalent to half of the participants computing 290 power. This is hard to guarantee since the economy of the 291 blockchain and the economy of the required hardware are 292 independent. As an example an attacker can acquire the required 293 hardware and operate it, take control of the blockchain to obtain 294 an economical benefit and finally sell the hardware to reduce the 295 final cost of the attack. 297 Hardware dependency: Bitcoin automatically increases -over time- the 298 complexity of the mathematical problem that needs to be solved in 299 order to add a block. This is done to account for Moore's law. 300 As a result the community has designed mining specific hardware 301 (ASICs) that provides a competitive advantage. In this context 302 blockchain becomes less democratic, since the cost of 303 participating in it increases. 305 Energy inefficiency: PoW requires large amounts of energy to perform 306 the computations (e.g., [miningfarm]). 308 3.3.2. Proof of Stake (PoS) 310 The main idea behind Proof of Stake is that participants with more 311 assets (or stake) in the blockchain are more likely to add blocks. 312 With this, the control of the chain is given to entities who own more 313 stake. For each new block, a signer is selected randomly from the 314 list of participants typically weighted according to their stake. A 315 fundamental assumption behind PoS is that such entities have more 316 incentives for honest behaviour since they have more assets in the 317 chain. 319 Proof of Stake is seen as an alternative to PoW. At the time of this 320 writing major players in the blockchain environment such as 321 [Ethereum] are preparing a shift towards PoS, moreover several 322 blockchains based on PoS already exist (eg. [Peercoin]). The main 323 reason behind this paradigm shift is that PoS addresses some of PoW's 324 main drawbacks: 326 o It does not require special hardware nor computationally or 327 energy-expensive calculations. 329 o An attacker must get hold of a significant part of the assets in 330 order to gain control of the blockchain. As opposed to PoS the 331 investment required to gain control of the chain lies within the 332 chain, and does not involve using external resources. 334 On the other side, Proof of Stake introduces new sources of attacks: 336 o In Proof of Stake the signer is selected randomly among the 337 stakers. In this context attackers can manipulate the source of 338 randomness to sign more blocks and ultimately gain control over 339 the chain. 341 o As opposed to PoW, creating forks is very inexpensive, since no 342 computational power is required. The PoS must provide means to 343 select the valid chain, which is typically the longer one. 345 o Collusions of high-stakers can create alternate chains which can 346 appear to be valid. 348 4. Blockchain for IP addresses 350 4.1. Problem statement 352 The objective of this section is to analyze if an infrastructure 353 using blockchain can provide a similar degree of security to 354 traditional PKI-based architectures. Specifically we aim to secure: 356 o Binding of IP address blocks to the holder (private key holder). 358 o The allocations and delegations of IP address blocks among their 359 holders. 361 o Binding of IP address blocks to their topological locators (eg. 362 AS numbers allocations). 364 This information is public and shared among a set of distrusting 365 entities over the Internet. The architecture must be able to: 367 o Allow anyone to verify the legitimate holder of a block of 368 addresses 370 o Let participating entities allocate address blocks without 371 requiring a trusted third party. 373 o Restrict the allocation of a block of addresses to only its 374 legitimate holder. 376 o Prevent data modification without the consent of its holder. 378 4.2. Analysis 380 The main rationale behind using blockchain to secure IP address 381 allocations is that IPs can be understood as coins, both concepts 382 share some fundamental characteristics: 384 o They are unambiguously allocated to entities. 386 o Can be transferred between them. 388 o Cannot be assigned to two entities at the same time. 390 o Can be divided up to a certain limit. 392 Such similar properties make it possible to envisage a blockchain 393 that allows its participants delegate IP address blocks, similarly to 394 how Bitcoin transfers coins. For example, IANA could write a 395 transaction allocating addresses to the RIRs, which in turn could 396 allocate them to the LIRs, etc. Complex management logic can be 397 defined as needed for example, rejecting a transaction that allocates 398 of a block of addresses originated by an entity that does not hold 399 that block. In addition, transactions accept multiple inputs and 400 outputs, i.e. an arbitrary amount of public keys either as senders or 401 receivers. This means that it is possible to break and merge blocks 402 of addresses as required. Section 5 provides more detailed 403 information about this architecture. 405 4.3. A consensus algorithm for IP addresses 407 As stated before, the consensus algorithm is a central part of a 408 blockchain. The first consensus algorithm designed for blockchain 409 was PoW, and it is a common choice for new blockchain 410 implementations. However it presents several drawbacks 411 (Section 3.3.1) for the IP address scenario. 413 Using computing power as a means to secure blockchains has been 414 proved to work in financial environments. However, the capability to 415 add new blocks and the security of the chain itself depends on the 416 computing power of the participants, which is not always aligned with 417 their interest in the well-being of the blockchain. Depending on the 418 objectives of the attacker, certain attacks can become profitable. 419 Namely, buying a large quantity of hardware to be able to rewrite the 420 blockchain with false data (e.g., incorrect delegations of IP 421 addresses). This is because the incentives of the participants of 422 the IP addresses blockchain are not linked with their computing 423 power. 425 In contrast, with Proof of Stake the capability to alter the 426 blockchain remains within it. This aspect is of particular 427 importance in the context of securing IP addresses: it would mean 428 that AS domains holding large blocks of IP addresses are more likely 429 to add blocks. These parties have a reduced incentive in tampering 430 the blockchain because they would suffer the consequences: an 431 insecure Internet. Typically ASes that hold large blocks of IP 432 address space have their business within the Internet and as such, 433 have clear incentives in the correct operation and security of the 434 Internet. 436 Furthermore, in such blockchain the risk of takeover is reduced 437 compared to PoW, the reason is that accumulating a large amount of IP 438 addresses is typically more complex than accumulating computing 439 power. The risk of takeover is also mitigated compared to other PoS- 440 based blockchains. In this blockchain an attacker would buy tokens 441 from the other parties, who receive a monetary compensation to 442 participate in the attack. However, in a blockchain for IP addresses 443 this would mean buying IP addresses from other parties, who do not 444 have a clear incentive to sell their blocks of addresses to the 445 attacker. Because of this, PoS appears to be a firm candidate for a 446 consensus algorithm in a blockchain for securing IP addresses 447 allocations and delegations. 449 5. Overview of the architecture 451 This architecture mimics the hierarchy of IP address allocation 452 present in today's Internet, with IANA on top of it. All nodes trust 453 IANA's public key, which writes a genesis transaction assigning all 454 of the address space to itself (figure 3). 456 +--------------+-----------------+-----------+----------------+ 457 | IANA | Signature IANA | Allocate | Hash(IANA | 458 | Public Key 1 | Private Key 1 | 0/0 | Public Key 2) | 459 +--------------+-----------------+-----------+----------------+ 461 Figure 3.- Genesis transaction 463 It then begins allocating each block of addresses to the IP address 464 holders. Each transaction allocates part of the address space to the 465 legitimate holder, and the rest of space is given back to IANA using 466 a new keypair (figure 4). 468 +--------------+-----------------+-----------+----------------+ 469 | | | Rest of | Hash(IANA | 470 | IANA | Signature IANA | space | Public Key 3) | 471 | Public Key 2 | Private Key 2 +-----------+----------------+ 472 | | | Allocate | Hash(APNIC | 473 | | | 1/8 | Public Key 1) | 474 +--------------+-----------------+-----------+----------------+ 476 Figure 4.- Example allocation transaction 478 In turn, all the parties in the hierarchy allocate or delegate 479 address blocks following the current allocation hierarchy. When a 480 party wants to verify the allocation of a block of addresses, it 481 downloads the blockchain and verifies all the blocks and transactions 482 up to the genesis block, for which it has trust. Figure 5 presents 483 an example of allocation of one prefix to each of the RIRs. 485 +--------------+-----------------+-----------+----------------+ 486 | | | Rest of | Hash(IANA | 487 | | | space | Public Key 4) | 488 | | +-----------+----------------+ 489 | | | Allocate | Hash(RIPE | 490 | | | 5/8 | Public Key 1) | 491 | | +-----------+----------------+ 492 | | | Allocate | Hash(APNIC | 493 | IANA | Signature IANA | 14/8 | Public Key 2) | 494 | Public Key 3 | Private Key 3 +-----------+----------------+ 495 | | | Allocate | Hash(ARIN | 496 | | | 23/8 | Public Key 1) | 497 | | +-----------+----------------+ 498 | | | Allocate | Hash(AFRINIC | 499 | | | 102/8 | Public Key 1) | 500 | | +-----------+----------------+ 501 | | | Allocate | Hash(LACNIC | 502 | | | 200/8 | Public Key 1) | 503 +--------------+-----------------+-----------+----------------+ 505 Figure 5.- Example multi-output allocation transaction 507 Inside the blockchain the typical operations to manage blocks of IP 508 addresses can be defined, such as the delegation of prefixes (figure 509 6). This helps to enforce the rules of IP addresses management. For 510 instance, since this transaction is marked as a delegation, if the 511 new owner created an allocation transaction it would be rejected by 512 the other nodes, because the parent transaction does not have the 513 privileges to perform it. 515 +--------------+-----------------+-----------+----------------+ 516 | | | Rest of | Hash(APNIC | 517 | APNIC | Signature APNIC | space | Public Key 3) | 518 | Public Key 1 | Private Key 1 +-----------+----------------+ 519 | | | Delegate | Hash(ISP A | 520 | | | 1.2/16 | Public Key 1) | 521 +--------------+-----------------+-----------+----------------+ 523 Figure 6.- Example delegation transaction 525 Performing a key rollover is simple, because each transaction has its 526 associated public key, and only depends on the previous transaction. 527 In other words, rekeying means changing the public key only in the 528 holder's transaction. This can be done adding a new transaction with 529 the same data but transferring it to a new public key also controlled 530 by the initial holder (figure 7). This approach lets each entity 531 decide its rekeying policies independently. 533 +--------------+-----------------+-----------+----------------+ 534 | ISP A | Signature ISP A | Delegate | Hash(ISP A | 535 | Public Key 1 | Private Key 1 | 1.2/16 | Public Key 2) | 536 +--------------+-----------------+-----------+----------------+ 538 Figure 7.- Example key rollover of a prefix delegation 540 It is worth noting that this chain can define as many operations as 541 required, for instance storing the binding of AS numbers to the IP 542 prefixes they announce (figure 8). 544 +--------------+-----------------+-----------+----------------+ 545 | | Signature | Bind | | 546 | ISP A | ISP A | 1.2/16 | Hash(ISP A | 547 | Public Key 2 | Private Key 2 | AS no. | Public Key 3) | 548 | | | 12345 | | 549 +--------------+-----------------+-----------+----------------+ 551 Figure 8.- Example binding of AS number to prefix 553 Additional and more complex operations can be defined if the 554 management logic requires it. For instance, several signatures (from 555 different parties) can be required to consider a transaction valid, 556 etc. 558 5.1. Pros and cons 560 In this section we analyze the pros and cons of this architecture 561 compared to traditional PKI infraestructures: 563 Advantages: 565 o Decentralized: No central entity controls the blockchain, it is 566 shared among all participants. 568 o No CAs, CRLs or certificates needed: No digital certificates, 569 Certification Authorities or CRLs are needed. 571 o Simplified rekeying: A key rollover can easily be performed by 572 issuing a new transaction allocating the prefixes to a new keypair 573 controlled by the same holder. This process can be performed 574 without involving any third-party. 576 o Censorship-resistant: since the control of a transaction is 577 completely under the holder of the private key, the revocation of 578 IP addresses without the legitimate holder's permission involves 579 obtaining its private key. Even if the private key of the 580 previous owner was compromised, ownership of the current 581 transaction is still preserved, as opposed to the compromise of a 582 CA's private key (or a misbehaving CA). 584 o Limited prior trust: It is not required to trust other nodes. 585 However, in PoS it is necessary to periodically authenticate the 586 chain state out-of-band to prevent some attacks. 588 o Simplified management: since CAs are not required, their 589 management overhead is avoided. 591 o Auditable: allocations and delegations can be tracked back in the 592 blockchain to determine if they originate from the legitimate 593 holder. 595 Drawbacks: 597 o PoS does not rely on strong cryptographic guarantees: As opposed 598 to PKI-based systems that rely on strong and well-established 599 cryptographic mechanisms, PoS-based infraestructures ultimately 600 rely on the good behaviour of the high-stakers. 602 o Costly bootstrapping: When a node is activated it has to download 603 and verify the entire blockchain. 605 o Large storage required: The blockchain grows forever as more 606 blocks are added, blocks cannot be removed. 608 5.2. Security evaluation 610 5.2.1. Attacks against a PoS-based consensus algorithm 612 This section presents a list of the most relevant attacks against a 613 Proof of Stake algorithm and how to mitigate them. 615 5.2.1.1. Stake grinding 617 Stake grinding refers to the manipulation of the consensus algorithm 618 in order to progressively obtain more stake, with the goal of signing 619 blocks more frequently with the ultimate goal of taking control of 620 the blockchain. It proceeds as follows: when the attacker has to 621 sign a block, it computes all the possible blocks (varying the data 622 inside them) to find a combination that gives the highest possibility 623 of signing another block in the future. It then signs this block and 624 sends it to the network. This procedure is repeated for all the next 625 signing opportunities. Over time, the attacker will sign more and 626 more blocks until the consensus algorithm will always select the 627 attacker to sign all blocks, thereby having taken control of the 628 blockchain. 630 To prevent this attack, the source of randomness used to select the 631 signers has to be hard to alter or to predict. 633 5.2.1.2. Nothing at stake 635 Nothing at stake is one of the fundamental drawbacks of Proof of 636 Stake and requires careful design based on the incentives of the 637 participants. In common PoS designs, the signers of the new block 638 receive an economical incentive (e.g., Ethereum). However this does 639 not hold in the IP address scenario, since participants should not 640 receive any incentive. The incentive is, as stated before, achieving 641 a consistent view of the IP address space and having a secure 642 Internet. 644 5.2.1.3. Range attacks 646 A range attack is performed by creating a fork some blocks back from 647 the tip of the chain. It is conceptually similar to the attack named 648 as 'Risk of overtaking' in Section 3.3.1. In this scenario, the 649 attacker has privately fabricated a chain which (according to the 650 consensus algorithm rules) will be selected over the original one. 651 Benefits of this attack include gaining more stake on the blockchain 652 (this attack could be part of a stake grinding attack) or rewriting 653 the transaction history to erase a payment made in the original 654 blockchain. 656 The simplest solution to this attack is adding a revert limit to the 657 blockchain, forbidding forks going back more than N blocks. This 658 provides a means to solidify the blockchain. However, nodes that 659 have been offline for more than N blocks will need an external source 660 that indicates the correct chain. It has been proposed to do this 661 out of band. This is why a PoS blockchain is not purely trustless 662 and requires a small amount of trust. 664 5.2.1.4. Lack of participation 666 Participants in a PoS algorithm will not always sign a block, since 667 they might be offline when they are selected or lack incentives. 668 Because of this, the final fraction of high-stakers that sign blocks 669 can be very different from the full set of high-stakers. The direct 670 consequence of this situation is that the portion of participants 671 that decide what goes into the blockchain can be a small set of 672 nodes. If this participation is low enough, it can leave the control 673 of the blockchain to a small amount of people/oligarchy, thus rising 674 security concerns. 676 5.2.2. Attacks against the P2P network 678 This section presents attacks directed towards the underlying P2P 679 network used to exchange information among the participants of the 680 blockchain. 682 5.2.2.1. DDOS attacks 684 Since blockchains are inherently based on P2P architectures, they 685 present a higher degree of resistance to DDOS attacks than 686 centralized server architectures, provided that the network has a 687 significant number of participants. In addition, it is always 688 possible to keep an offline copy of the blockchain. 690 5.2.2.2. Transaction flooding 692 A special type of DDOS attack consists in creating a large amount of 693 legit transactions that transfer a small amount of tokens (i.e. 694 delegate a lot of small IP prefixes). If the number of transactions 695 is large enough, the addition of new transactions can be 696 significantly delayed because not all of them fit into a single 697 block. The effectiveness of the attack also depends on the 698 throughput of the blockchain (transactions/second). Simple solutions 699 may be to limit the granularity upon which IP addresses can be split. 700 Of course, only the legitimate holder of a large amount of IP address 701 can perform this attack. 703 5.2.2.3. Routing attacks 705 The underlying P2P network in blockchains does not typically use any 706 security mechanism, e.g. node authentication or integrity of network 707 protocol messages. This enables potentially disruptive attacks. For 708 example, specially located rogue nodes could drop new transactions, 709 which would block updates on the blockchain and leave legit nodes 710 uncommunicated. The effectiveness of this kind of attacks depends on 711 how the P2P algorithm selects peers and the topology of the P2P 712 network. 714 However, the most potentially dangerous attack of this type are 715 network partitions, i.e. isolating a group of nodes from the rest of 716 the network so they cannot communicate each other (e.g., 717 [Apostolaki2017]). The consequence of this attack is that two 718 versions of the blockchain are created, one at each network 719 partition. When the partition disappears and the nodes reconnect one 720 of the two chains will be discarded, causing a service disruption. 721 It is worth noting that Bitcoin has suffered similar attacks 722 [realrouteattack]. 724 5.2.2.4. Transaction censorship 726 When a node adds a block it chooses arbitrarily which transactions 727 are added into it, i.e. no specific rules control how transactions 728 are added to a block. This enables a node to selectively add some 729 transactions and intentionally exclude others, with the consequence 730 that some transactions may be never added to the blockchain. In the 731 context of IP addresses, this may be performed by a competing ISP to 732 prevent another ISP from executing a certain modification. Possible 733 solutions revolve around: 735 o Giving more priority to older transactions (similarly to Bitcoin). 737 o Punishing nodes that exhibit this kind of behaviour, e.g. removing 738 part of their block of IP addresses or lowering their chance of 739 adding blocks. 741 6. Other Considerations 743 6.1. Revocation 745 Due to the irreversible nature of transactions, once a block of IP 746 addresses has been allocated to an entity it is not possible to 747 modify or remove it, as opposed to CRLs (Certificate Revocation 748 Lists). However, due to operational issues (compromised or lost 749 keys, human mistake, holder misbehaviour, etc) it is critical to 750 provide a way to recover a block of addresses. Moreover, since IP 751 addresses are a finite public good they cannot be lost. Taking into 752 account that a blockchain can enforce any rules its participants 753 agree upon, this section presents some possible approaches to 754 implement revocation, such approaches should not be considered as 755 mutually exclusive. The revocation procedure must be discussed among 756 the community to achieve consensus between the relevant players 757 (IANA, RIRs, ISPs, institutions, etc). 759 All these mechanisms present different balances of power between the 760 current holder and the entity whose asset is being revoked. Behind 761 all these mechanisms there is a fundamental tradeoff between trusting 762 an upstream provider of the addresses and retaining full control of 763 the block of addresses. 765 Regardless of the revocation policy and as opposed to traditional PKI 766 systems, each IP prefix delegation only depends on the private key of 767 the holder of such IP block. As such, it does not need to trust a CA 768 or a chain of certificates. Only by means of this private key the IP 769 delegation can be altered. 771 6.1.1. Expiration time 773 A simple approach to allow revocation is adding a lease time (i.e, 774 time-to-live) to the blocks of addresses. After the lease ends, the 775 new holder of the address block automatically becomes the previous 776 one, or addresses are transferred to a default holder. As stated 777 before, this revocation procedure should be enforced by the rules of 778 the blockchain, this means that participants would not recognise 779 expired allocations as valid. 781 6.1.2. Multi-signature transactions 783 A multi-signature transaction is a transaction that admits more than 784 one authorized signer. In other words, a transaction is considered 785 valid if it has, for instance, 2 out of 5 valid signatures. This 786 way, 3 keys can be lost but with the renaming 2 keys the block of 787 addresses can be recovered. This approach exemplifies the 788 aforementioned tradeoff in trust, since the holder of the block of 789 addresses must trust the owners of the keys participating in the 790 multi-signature transaction. 792 6.1.3. Revocation transaction 794 A simpler approach than multi-signature transactions is creating a 795 'revocation' transaction. When a block of address is required to be 796 reassigned without the consent of the current holder, a revocation 797 transaction (specifying the new holder) is inserted in the 798 blockchain. This transaction should be issued either by a 799 consensuated authority or by a disputing entity. The revocation 800 transaction should be resolved by either accepting the revocation 801 transaction automatically when issued by the accepted authority or by 802 means of out-of-band mechanisms when issued by a disputing party. 804 6.1.4. Out-of-band mechanisms 806 Disputes regarding transactions can be resolved by means of out-of- 807 band mechanisms, e.g, discussion, court, etc. In order to reflect 808 the decision of this out-of-band mechanism the blockchain must be 809 modified. Since this represents a deviation from the rules, it must 810 be done through a hard blockchain fork. Although cumbersome and 811 complex, this is feasible from a technical standpoint. 813 6.2. Storage management 815 The never ending size of the blockchain presents a potential 816 scalability issue. At the time of this writing, mature blockchains 817 like Bitcoin require more than 100 GB of storage. Simply deleting or 818 summarizing old transactions degrades the security of PoW-based 819 chains, since their security relies on the computing power required 820 to generate them. The longer they are, the harder they are to 821 attack. 823 However, PoS-based chains do not rely on computing power and hence, 824 space-saving strategies do not degrade the security. For instance a 825 simple solution could be to, once the PoS-based chain reaches a 826 certain storage size, summarize a subset of the older transactions. 827 In what follows we overview this strategy: 829 +-----+-----+-----+-----+-----------------+-----+-----+-----+ 830 | 0 | 1 | 2 | 3 | ..... |47832|47833|47834| 831 +-----+-----+-----+-----+-----------------+-----+-----+-----+ 833 9.1 Old blockchain 835 +-----+-----+-----+-----+-----+ 836 | r0 | r1 | r2 | r3 | r4 | 837 +-----+-----+-----+-----+-----+ 839 9.2 Write present state to special reset blocks 841 +-----+-----+-----+-----+-----+-----+-----+ 842 | r0 | r1 | r2 | r3 | r4 | 0 | 1 | ... 843 +-----+-----+-----+-----+-----+-----+-----+ 845 9.3 Continue working after the reset blocks 847 Figure 9.- A simple technique to reduce blockchain storage 849 This approach reduces bootstrapping cost, it is worth noting that 850 this strategy requires trust on the reset blocks, such blocks can be 851 obtained with an out-of-band mechanism (see Section 5.2.1.3 for 852 further information). 854 6.3. Proof of Networking? 856 In this section we speculate how one could design an equivalent of 857 Proof-of-Work (PoW) for networks. Conceptually, PoW is a proof of 858 computational resources, can we devise a proof of networking 859 resources? It could be thought that a PoW equivalent may exist in 860 the context of networks, i.e., an equivalent to spending computer 861 cycles in a network. Some resources unique to networks are 862 bandwidth, computation of checksums, number of BGP peers, etc. 863 Hence, we could envisage a blockchain secured by the resources 864 inherent to its participating computer networks. As long as half of 865 the resources were controlled by honest members, security is 866 guaranteed. For example, bandwidth could be a potential candidate; 867 however it does not satisfy two key features present in PoW: 869 o Asymmetry: the proof has to be hard to generate but fast to 870 verify. 872 o Verifiability: it has to be possible to embed the proof in the 873 block in order to account for the spending of resources. 875 In this context, Proof-of-Networking is an open research issue . 877 6.4. Configuration parameters 879 Configuration parameters refer to a set of values: 881 o Block creation rate 883 o Maximum block size 885 o Other parameters related to the consensus algorithm 887 These parameters, beyond regulating the operation of the blockchain 888 also have an influence on its performance. For example, a small 889 block size increases propagation speed (thus consensus can be reached 890 faster) but reduces the number of transactions per second that the 891 blockchain can handle. As an example, in Bitcoin, the 10-minute 892 block creation rate seeks to balance fast confirmation times and 893 reduced probability of forks [Antonopoulos2015]. Experimental 894 deployments and operational requirements should help tuning such 895 parameters. 897 7. Security Considerations 899 This document aims to understand the security implications of using 900 the blockchain technology to secure IP addresses allocation. 902 8. IANA Considerations 904 This memo includes no request to IANA. 906 9. Acknowledgements 908 The authors wish to thank Jordi Herrera-Joancomarti, Andreu 909 Rodriguez-Donaire and Jordi Baylina for their helpful discussions 910 about Bitcoin and blockchain technology, as well as Leo Vegoda for 911 his insights regarding revocation mechanisms. 913 10. Informative References 915 [Antonopoulos2015] 916 Antonopoulos, A., "Mastering Bitcoin, available online: 917 http://chimera.labs.oreilly.com/books/1234000001802/ 918 index.html", 2015. 920 [Apostolaki2017] 921 Apostolaki, M., Zohar, A., and L. Vanbever, "Hijacking 922 Bitcoin: Routing Attacks on Cryptocurrencies. 2017 IEEE 923 Symposium on Security and Privacy (SP).", 2017. 925 [Bitcoin] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 926 System. https://bitcoin.org/bitcoin.pdf", 2008. 928 [Blockstack] 929 Ali, et al., M., "Blockstack : A Global Naming and Storage 930 System Secured by Blockchains, USENIX Annual Technical 931 Conference", 2016. 933 [Ethereum] 934 The Ethereum project, "https://www.ethereum.org/", 2016. 936 [Hari2016] 937 Hari, A. and T. Lakshman, "The Internet Blockchain: A 938 Distributed, Tamper-Resistant Transaction Framework for 939 the Internet. Fifteenth ACM Workshop on Hot Topics in 940 Networks", 2016. 942 [miningfarm] 943 Inside a mining farm, "http://www.bbc.com/future/ 944 story/20160504-we-looked-inside-a-secret-chinese-bitcoin- 945 mine", 2016. 947 [Namecoin] 948 Namecoin, "https://namecoin.org/", 2011. 950 [Peercoin] 951 The Peercoin cryptocurrency, "https://peercoin.net/", 952 2016. 954 [realrouteattack] 955 Hacker Redirects Traffic From 19 Internet Providers to 956 Steal Bitcoins, "https://www.wired.com/2014/08/isp- 957 bitcoin-theft/", 2014. 959 Authors' Addresses 961 Jordi Paillisse 962 UPC-BarcelonaTech 963 c/ Jordi Girona 1-3 964 Barcelona, Catalonia 08034 965 Spain 967 Email: jordip@ac.upc.edu 969 Alberto Rodriguez-Natal 970 Cisco Systems 971 170 Tasman Drive 972 San Jose, CA 973 USA 975 Email: natal@cisco.com 977 Vina Ermagan 978 Cisco Systems 979 170 Tasman Drive 980 San Jose, CA 981 USA 983 Email: vermagan@cisco.com 985 Fabio Maino 986 Cisco Systems 987 170 Tasman Drive 988 San Jose, CA 989 USA 991 Email: fmaino@cisco.com 993 Albert Cabellos 994 UPC-BarcelonaTech 995 c/ Jordi Girona 1-3 996 Barcelona, Catalonia 08034 997 Spain 999 Email: acabello@ac.upc.edu