Secure Blockchain Network Communication Using SCION

DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2018

Secure Blockchain Network Communication using SCION

ALEKSANDAR VORKAPIC

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Secure Blockchain Network Communication using SCION

ALEKSANDAR VORKAPIC´

Master in Computer Science Date: December 5, 2018 Supervisor: Panos Papadimitratos Examiner: Mads Dam Principal: Adrian Perrig, ETH Zürich Swedish title: Säker nätverkskommunikation för blockkedja med hjälp av SCION School of Electrical Engineering and Computer Science

Abstract

The paper by Apostolaki, Zohar, and Vanbever [3] describes two routing attacks on the Bitcoin network, partition attack and delay attack. By isolating parts of the network or delaying block propagation, a significant amount of mining power could be wasted, resulting in revenue loss and a wide range of exploits could be enabled, such as double spending. Hence, the Bitcoin’s solution to the double spending problem would be broken, making the technology unreliable and unavailable. The Border Gateway Protocol (BGP) is the standardized routing protocol in the current Internet, without any security guarantees. Nu- merous security extensions have been proposed for BGP, but there is still no widely deployed solution. Therefore, some argue that instead of securing BGP, an entirely new inter-domain architecture should be developed. The thesis investigates the possible mitigation of routing attacks in the blockchain technology, by using the new inter-domain architecture called SCION. Two solutions are proposed utilizing SCION and IP, namely an application level solution and a SIG proxy solution. The solutions have been evaluated in terms of security, availability and efficiency, with the conclusion that routing attacks can be mitigated using SCION. Hence, providing incentive to the blockchain users to use SCION, in order to benefit from a secure and highly available blockchain network communication, with potential revenue increase. Furthermore, the thesis provides incentive for further development of the SCION architecture, as well as applying SCION to additional fields. ii

Sammanfattning

Forskningsarbetet av Apostolaki, Zohar och Vanbever [3] beskriver två routingattacker på Bitcoinnätverket, partitioneringsattack och fördröj- ningsattack. Genom att isolera delar av nätverket eller fördröja block- utbredningen, skulle signiﬁkant mängd brytningskraft kunna slösas bort, vilket resulterar i omsättningsförlust och ett brett spektrum av utnyttjanden skulle kunna möjliggöras, som t.ex. dubbla utgifter. Som en följd, skulle Bitcoins lösning på problemet med dubbla utgifter sät- tas ur spel, vilket gör tekniken opålitlig och otillgänglig. Border Gateway-protokollet (BGP) är det standardiserade routing- protokollet i nuvarande Internet, utan några säkerhetsgarantier. Många säkerhetsutvidgningar för BGP har föreslagits, även om det fortfaran- de inte ﬁnns någon allmänt nyttjad lösning. Därför hävdar vissa att i stället för att säkra BGP, bör en helt ny interdomänarkitektur utveck- las. Detta examensarbete undersöker en eventuell lindring av routingattacker i blockkedjetekniken, med hjälp av den nya interdomänar- kitekturen som heter SCION. Två lösningar som nyttjar SCION och IP föreslås, en applikationsnivålösning och en SIG-proxylösning. Lös- ningarna har utvärderats med avseende på säkerhet, tillgänglighet och effektivitet. Slutsatsen blev att routingattacker kan lindras med SCION, vilket motiverar blockkedjeanvändarna att använda SCION, för att dra nytta av en säker och högt tillgänglig blockkedjenätverkskommu- nikation, med möjlighet till ökad omsättning. Examensarbetet bidrar dessutom med motivering för vidareutveckling av SCION-arkitekturen, samt till att tillämpa SCION på ytterligare områden. iii

Acknowledgements

I would like to express my sincere gratitude to my supervisor Panos Papadimitratos for the support of my research and invitation to the CySeP 2018. His feedback and guidance helped me with the research, and the writing of the thesis. My sincere and very thorough thanks also go to Prof. Dr. Adrian Perrig at ETH Zürich, together with Christos Pappas and Taeho Lee, for giving me the chance to carry out the study. Without their extensive knowledge, advice and insights, this thesis would not have been ﬁnished. Lastly, I would like to thank Juan A. García-Pardo and Jonghoon Kwon at ETH Zürich for helping me with the SCIONLab, and willing to discuss SCION and blockchain related questions. Contents

1 Introduction 2 1.1 Research Question ...... 3 1.2 Objective ...... 3 1.3 Scope and limitations ...... 4

2 Background 6 2.1 The Border Gateway Protocol (BGP) ...... 6 2.1.1 BGP hijacking attack ...... 7 2.1.2 Defenses ...... 9 2.2 The SCION Architecture ...... 13 2.2.1 The SCION-IP Gateway (SIG) ...... 17 2.3 Blockchain ...... 19 2.4 Bitcoin ...... 24 2.5 Ethereum ...... 25 2.5.1 Node discovery protocol ...... 25 2.5.2 Establishing encrypted connection ...... 27

3 Related Work 29

4 Solution Design 34 4.1 Problem ...... 34 4.1.1 Assumptions and limitations ...... 35 4.2 Application level solution ...... 35 4.3 SIG proxy solution ...... 36 4.4 Security model ...... 38

5 Method 39 5.1 Literature research ...... 39 5.2 Application level solution ...... 39 5.3 SIG proxy solution ...... 40

iv CONTENTS 1

5.4 SIG discovery protocol ...... 41 5.5 Disruption Detection Tool (DDT) ...... 41 5.6 Evaluation ...... 42 5.6.1 Efﬁciency requirements ...... 43

6 Implementation 44 6.1 Hardware ...... 44 6.2 Software ...... 44 6.2.1 Ethereum network conﬁguration ...... 46 6.3 Design ...... 47

7 Results 48 7.1 Security analysis ...... 49 7.1.1 Attack scenario ...... 49 7.2 Availability analysis ...... 52 7.3 Efﬁciency analysis ...... 53 7.3.1 IP and SCION comparison ...... 54

8 Discussion 58 8.1 Security analysis ...... 60 8.1.1 Disruption Detection Tool (DDT) ...... 61 8.1.2 SIG discovery protocol ...... 62 8.2 Blockchain protocols with encrypted communication . . 62 8.3 Availability analysis ...... 64 8.4 Efﬁciency analysis ...... 65 8.5 SCION deployment ...... 68 8.6 Ethical aspects and sustainability ...... 69

9 Conclusion 71

10 Future Work 73

Bibliography 75

A Typical scenario 81 A.1 Application level solution ...... 81 A.2 SIG proxy solution ...... 84 Chapter 1

Introduction

Blockchain technology can be traced back to 1991 when Haber and Stornetta [28] described the first work on a cryptographically secured chain of blocks. A year later, Bayer, Haber, and Stornetta [5] enabled several documents to be collected into a block. However, blockchain technology gained significance first in 2008, when Satoshi Nakamoto published the Bitcoin white paper [41]. The invention of the Bitcoin made it the first digital currency (cryptocurrency) to solve the double spending problem, spending the same asset twice, without the need of a trusted central authority. Furthermore, it has become inspiration for many additional cryptocurrencies and blockchain-based applications. At the time of writing the thesis, Bitcoin was the most successful cryptocurrency with more than 17 million bitcoins valued at approximately 115 billion USD [6]. Given the amount of money at stake, Bitcoin and other cryptocurrencies are obvious targets for attackers. However, attacking cryptocurrencies via the Internet infrastructure was not investigated until the paper by Apostolaki, Zohar, and Vanbever [3] was published. It was believed that blockchain technology is resilient against Bor- der Router Protocol (BGP) hijacking attacks, due to the decentralized Peer-to-Peer (P2P) network. However, the recent paper by Apostolaki, Zohar, and Vanbever [3] shows that, due to the insecure BGP routing protocol and quite centralized Bitcoin network, it is feasible to execute routing attacks on Bitcoin. Few Autonomous Systems (ASes) host most of the nodes in the Bitcoin network, which could be due to the high amount of mining pools located in Iceland and China. In mining pools, multiple miners gather together in order to increase their

2 CHAPTER 1. INTRODUCTION 3

chances of finding new blocks and getting the reward. Furthermore, the paper describes two routing attacks, partition attack and delay attack. By isolating parts of the network or delaying block propagation, a significant amount of mining power could be wasted, resulting in revenue loss and a wide range of exploits could be enabled, such as double spending. Hence, the Bitcoin’s solution to the double spending problem would be broken, making the technology unreliable and unavailable. Since routing attacks are feasible on any technology running on a centralized network in the current Internet, a routing protocol that guarantees secure and highly available network communication is vital. Thus, it is of interest to investigate mitigation of routing attacks on blockchain technology using SCION [47], a new inter-domain architecture being developed to solve all BGP vulnerabilities in an efficient way.

1.1 Research Question

Is it feasible to deploy SCION along with a blockchain technology in order to mitigate routing attacks, and provide secure and highly available blockchain network communication?

Can the proposed solution decrease the amount of wasted computing power by routing attacks, and increase miners’ revenue by utilizing SCION?

1.2 Objective

Mitigating BGP routing attacks targeting a blockchain technology is the main focus of the thesis. Routing attacks have been disrupting the Internet for decades, by enabling phishing, spamming and Distributed Denial-of-Service (DDoS) attacks. The BGP protocol is the standardized routing protocol in the current Internet, with no security guarantees [46]. Thus, it is feasible to execute routing attacks, also called BGP hijacking attacks. Any AS can inject forged information on how to reach one or more IP preﬁxes, resulting in ASes sending trafﬁc to wrong destination [3][47]. 4 CHAPTER 1. INTRODUCTION

In 2014, Dell SecureWorks published details of an attacker who re- peatedly performed BGP hijacking attacks on a large set of providers, such as Amazon, Digital Oceana and Alibaba. The goal was to intercept data between Bitcoin miners and Bitcoin mining pools, where the estimated worth of the theft was $83,000 [56]. A more recent BGP hijacking attack on Amazon DNS, resulted in theft of ether and ethereum- based tokens worth $152,000 [24]. Furthermore, according to BGPmon [34] and Oracle Dyn [15], BGP hijacking attacks occur frequently and affect wide range of applications and users. Numerous security extensions for the BGP have been proposed, such as S-BGP, soBGP, SPV and many more. Although, there is still no widely deployed solution, because of two main reasons. Firstly, many of these solutions require great modiﬁcations to the BGP routing protocol, making adoption challenging. Secondly, the beneﬁt of partial adoption is limited, leading to cautious initial adoption [62]. Further- more, some argue that instead of securing BGP, an entirely new inter- domain architecture should be developed [43]. Since there is no widely deployed solution, the Internet is still vulnerable and enables exploiting secure routing insecurities in blockchain technology. Thus, it is of interest to investigate mitigation using SCION [47], in order to secure the blockchain technology from BGP routing attacks. SCION is a new inter-domain network architecture, recently being implemented for various applications. Some argue that it is one of the most promising inter-domain architectures to replace the BGP protocol. The problem at hand is of interest, since the routing attacks on blockchain technology is a recent discovery by Apostolaki, Zohar, and Vanbever [3], and no prior research has addressed the problem nor proposed a solution. Thus, the thesis will investigate how to deploy SCION within a blockchain technology in order to provide secure and highly available blockchain network communication.

1.3 Scope and limitations

The thesis will focus on two biggest cryptocurrencies at the time of writing the thesis, namely Bitcoin and Ethereum. Furthemore, it will focus on the BGP hijacking attacks within the blockchain technology. Eclipse attacks, have been proposed against Bitcoin [30] and Ethereum CHAPTER 1. INTRODUCTION 5

[39]. However, they are beyond the scope of the thesis, because such attacks are feasible due to application level vulnerabilities in respective protocol, and not a network vulnerability. Furthermore, Network Address Translation (NAT) traversal problem in the P2P networks is beyond the scope of the thesis. Lastly, the SCION architecture is still under development and will require temporary solutions from the author. The temporary solutions are proposed based on the information available at the time of writing the thesis. Thus, BGP hijacking attacks will not be executed on the provided solutions due to time limitations and complexity of creating the testbed for execution of routing attacks in SCION, instead an analysis will be done. Chapter 2

Background

This chapter provides fundamental background information about the BGP, SCION and the blockchain technology, the proposed solutions incorporate.

2.1 The Border Gateway Protocol (BGP)

The "two-napkins protocol", formally known as Border Gateway Pro- tocol or BGP, was designed in January 1989 in Austin, Texas at the Internet Engineering Task Force (IETF) conference. It was during a lunch break, when Kirk Lougheed and Len Bosack of Cisco and Yakov Rekhter of IBM invented the new routing protocol that revolutionized the Internet [35]. In 1994, the BGP version 4 [49] was released, and has been used since then as the main inter-domain routing protocol of the Internet, with numerous updates over the years. The primary function of BGP is to exchange network routing information between independently operated networks or Autonomous Systems (ASes), such as Internet Service Providers (ISPs) [47]. The network routing information consists of IP prefixes (Internet addresses), that are obtained from BGP neighbors. This information is used to determine paths through the Internet, and populate routers’ routing tables. Furthermore, it is sufficient for constructing a graph of AS connectivity, from which routing loops may be pruned and at the AS level, some policy decisions may be enforced [49]. The Internet has evolved into a global network that is being heavily commercialized and privatized. It became apparent that vanilla shortest path routing would be insufficient to handle the infinite operational, economic, and political factors involved in the routing. Thus,

6 CHAPTER 2. BACKGROUND 7

the owners of the routers, e.g. ISPs, began to modify routing configuration to support their routing policies by selecting which routes will be propagated to the neighbors [13]. BGP was originally a simple path vector protocol, which was incre- mentally modified over time with numerous mechanisms to support routing policies. This has enabled ASes to customize their routing policies, in order to realize their economic, performance, security, and traffic engineering goals. Hence, the details of these routing policies are often kept secret [13] The outcome is a protocol where most of the complexity is in the decision process and the policies used to influence decisions, while the rest of the protocol has remained fairly simple. However, this is mostly important for what will be announced to the neighbors, while the In- ternet routers forward traffic according to the longest-match entry in the routing tables. Furthermore, the BGP lacks integrity and authentication of BGP messages, thus it enables BGP hijacking attacks [3].

2.1.1 BGP hijacking attack As mentioned previously, BGP is the standardized routing protocol in the current Internet, which due to no security guarantees makes hijacking attacks (routing attacks) feasible in BGP [46]. Any AS can announce forged information to its neighbors, either maliciously or by misconﬁgurations, resulting in other ASes sending trafﬁc to wrong destination [3][47]. This vulnerability resulted in numerous such attacks, where one of the biggest routing attacks happened in February 2008. Pakistan attempted to block Youtube access within their country, instead they took down the entire Youtube [16]. Extensive research has been made about how BGP hijacking attacks can be detected and mitigated, see Section 2.1.2. However, such attacks are still being executed frequently according to BGPmon [34] and Ora- cle Dyn [15], whereas some recent attacks have been executed against cryptocurrencies, Bitcoin [56][3] and Ethereum [24]. 8 CHAPTER 2. BACKGROUND

BGP message: "1.1.1.1/16: AS4 AS2" "1.1.1.1/24: AS4 AS3" AS1 (ISP of victim)

Miner

AS4 (Large ISP)

BGP message: BGP message: "1.1.1.1/24: AS3" "1.1.1.1/16: AS2"

AS2 AS3 (Legitimate owner (Hijacker's ISP) of 1.1.1.1/16)

Hijacking mining Legitimate mining pool server pool server 1.1.1.2

Victim's route to 1.1.1.2 before hijack Victim's route to 1.1.1.2 after hijack

Figure 2.1: A BGP hijacking attack, where malicious AS3 wants to intercept the traffic between AS1 (miner) and AS2 (mining pool server) by announcing a more specific IP prefix.

Figure 2.1 demonstrates how a BGP hijacking attack on Bitcoin in 2014 could have been executed, where the goal was to intercept traffic between Bitcoin miners and Bitcoin mining pools [56]. The malicious AS3 which is the adversary, can intercept the traffic for the legitimate prefix p (1.1.1.1/16) in two ways. Either by sending a BGP UPDATE message containing p, or with a more specific (longer) prefix of p. By announcing p, the AS3’s route will be in competition with the legitimate route. Since the BGP routers prefer shorter paths, the AS3 will on average attract 50% of the traffic. Although, if the attacker announces a more specific prefix of p, such as 1.1.1.1/24, it will attract all traffic, because Internet routers forward traffic according to the longest-match entry. Thus, traffic addressed to the destination within 1.1.1.1/24 IP block, e.g. 1.1.1.2 (mining pool server), will be routed to AS3 as shown with the red dotted line. However, internal traffic within an AS cannot be redirected with hijacking, as it is not using BGP, instead it uses intra-domain routing protocols such as OSPF [3][4]. The attack in Figure 2.1 will not attract all traffic destined to p. CHAPTER 2. BACKGROUND 9

Therefore, if the adversary wants to attract all traffic destined to p, two slightly longer prefixes have to be advertised, 1.1.1.1/17 and 1.1.128.1/17. These announcements will reach routers in the entire Internet, and make them forward any traffic destined to the legitimate p prefix according to the prefixes owned by the adversary. Furthermore, announcing a more specific prefix has its limit, because BGP operators often filter prefixes longer than /24. Although, majority of Bitcoin nodes are hosted in shorter prefixes, and thus susceptible to BGP hijacking attacks [3]. By performing a BGP hijacking attack, a black hole at the attacker’s location will be created. However, the attacker can turn the hijack into an interception attack or a phishing attack. In the former case, attacker must leave at least one path intact to the destination, while in the latter, the machine acts like the legitimate server, in order to steal credentials. [3] [24]. Furthermore, such attacks can be extended to send unexpected or undesirable BGP traffic to a victim, in order to perform a BGP Denial-of-Service (DoS) attack [23].

2.1.2 Defenses Various cryptographic protocol modiﬁcations and anomaly-detection techniques have been proposed over time. The 5 major BGP security extensions are described below, while there exist plenty more, such as Pretty Good BGP (PGBGP), Pretty Secure BGP (psBGP), and more. However, the described solutions provide either high overhead or require large number of ASes to deploy the solution, resulting in not enough incentive. Hence, none of the proposed solutions is widely deployed. Instead of securing BGP, another option would be to construct an entirely different inter-domain routing protocol. Furthermore, according to Nordström and Dovrolis [43], replacing BGP would be an expensive and difﬁcult task, given the wide deployment of BGP. Ad- ditionally, it is unclear how to design a better inter-domain routing system that can do everything BGP does well and at the same time mitigate BGP vulnerabilities. However, Perrig et al. [47], proposed a new inter-domain architecture, that at the time of writing this thesis is being developed at ETH Zürich. 10 CHAPTER 2. BACKGROUND

Secure BGP (S-BGP) Secure BGP is the first comprehensive security extension to BGP with the objective to protect BGP from malicious or erroneous UPDATE messages. It provides authorization of prefix ownership, and authenticates routes by using public-key cryptography [43]. Two key features of S-BGP are Address Attestation (AA) and Route Attestation (RA). An AA is generated by the owner of a prefix, and is used by S-BGP routers to verify that the origin AS is authorized to advertise that address block. The RAs are added by S-BGP routers to the UPDATE messages, in order to authorize a neighboring AS to propagate the route contained in the UPDATE message [43]. If the network in Figure 2.1 was using S-BGP, the AS4 would detect the adversary (AS3), because it is unauthorized to advertise that address block. Furthermore, AS4 would not authorize AS1 to propagate the route contained in the BGP UPDATE message by the adversary. Thus, the IP prefix by the adversary would not be widespread, and the BGP hijacking attack would be mitigated. However, there are significant barriers that hamper S-BGP adoption. Information exchanged in S-BGP is validated using the certificates, and the control messages are signed by the senders. Hence, due to the amount of data and number of possible signers, the validation can be costly [12]. Furthermore, the simulations have shown that path convergence times would be twice as long with S-BGP, and the storage requirements for RAs are substantial [12]. Thus, the results have raised concerns about the feasibility of S-BGP in the Internet, and given incentive to research alternative solutions [12].

Secure origin BGP (soBGP) Secure origin BGP is a lightweight alternative to S-BGP, that authenticates two aspects of routing information [43]. First, soBGP validates that an AS is authorized to originate a given prefix. Second, it tries to verify that an AS advertising a prefix has at least one valid path to that destination, in terms of policy and topology [43]. Instead of utilizing a hierarchical Public Key Infrastructure (PKI) as S-BGP, soBGP uses a Web-of-Trust model to validate certificates [43]. In order to avoid computational overhead of validating signatures, soBGP authenticates long-term structural routing elements, such as organization relationships, address ownership and topology, prior to CHAPTER 2. BACKGROUND 11

participating in BGP. The authenticated data is signed, validated and stored in the routers prior to the establishment of the BGP session. Hence, the validation does not introduce significant run-time costs [12]. This approach would mitigate the BGP hijacking attack in Figure 2.1, in the same way as S-BGP but with less overhead and greater ease of deployment. However, the number of deployment options could introduce interoperability difficulties. Furthermore, the certificates used in soBGP are non-standard compared to the Internet Engineering Task Force (IETF) PKIX certificates used in S-BGP [12].

Inter-domain Route Validation (IRV) Inter-domain Route Validation service is a receiver-driven protocol and is the least centralized of the comprehensive solutions for securing BGP [12]. Unlike S-BGP, IRV operates independently of the routing protocol. Every AS in IRV, deploys one or more IRV servers. Upon receiving a BGP UPDATE message, the local IRV server will check whether the received information is valid [12]. When a BGP router receives an UPDATE message, the corresponding IRV server contacts the IRV server of each AS in the path to verify the origin, and the routing path of the received UPDATE message [43]. IRV would require each AS in Figure 2.1 to have at least one IRV server, in order to mitigate the BGP hijacking attack. The key idea of IRV is to decrease the computational and storage costs, by validating each data item through a direct query to the AS from where it came [12]. Furthermore, the IRV approach might have better success than registries, due to ASes retaining control over the data and being able to keep it fresh, accurate and available. However, it is relying on the AS making accurate decisions, and the IRV server not being misconﬁgured [12].

Secure Path Vector (SPV) Secure Path Vector is an efficient cryptographic mechanism that utilizes symmetric cryptographic primitives, in order to provide path authentication [31][12]. In SPV, the originator of a prefix establishes a single root value which is used to seed the generation of one-time signature structures for each hop in the path. This approach is known as offline signatures, 12 CHAPTER 2. BACKGROUND

where one-time signatures allow the signer to perform heavyweight cryptographic operations prior to use, making the signing operation faster [12]. Hence, the routers do not need to perform computationally expensive public-key cryptographic operations, and to store asymmetric private keys [31]. According to the Hu, Perrig, and Sirbu [31], this approach improves security greatly, because the prefix private key could be stored on an offline workstation. SPV is a lightweight solution, because hashing is used as the primary cryptographic operation. However, due to the efficiency, SPV is a complex protocol involving the manipulation and communication of a significant amount of state information. Furthermore, according to Hu, Perrig, and Sirbu [31], reduced exposure in time to forgery vulnerabilities is sufficient to mitigate attacks. However, a paper by Ragha- van, Panjwani, and Mityagin [48] shows that over 60% of ASes are capable of forging routes in SPV with high probability, and argue that SPV is vulnerable against collusion and eavesdropping attacks. Hence, the constant time signatures do not provide the required security to protect against path modification.

BGP security (BGPsec) BGP security is a mechanism for providing path security for BGP route advertisements, that is being standardized by IETF [52]. It relies on the Resource Public Key Infrastructure (RPKI) certiﬁcates, for attestation of the AS number and IP address. When a valid BGPsec UPDATE message arrives, BGPsec has cryptographic guarantee that every AS on the path has explicitly authorized the advertisement of the route to the next AS [52]. Furthermore, the BGPsec provides BGP routes with an authorized origin AS, path validation and resilience against path-shortening attacks [25]. By using BGPsec in Figure 2.1, the ASes receiving BGP UPDATE message from the adversary (AS3), have to authorize it before propa- gating it to the neighbor ASes. The AS4 which is not malicious, will detect that AS3 is not origin AS for the announced IP preﬁx. Hence, the AS4 will not propagate the BGP UPDATE message to AS1, and it will mitigate the BGP hijacking attack. The BGPsec is an online cryptographic protocol, where routers must cryptographically sign and verify every BGP message they send. This provides high computational overhead, and could require routers to CHAPTER 2. BACKGROUND 13

be upgraded with crypto hardware accelerators. Hence, it could slow down the deployment of BGPsec [25]. Furthermore, each AS has to decide whether or not to deploy BGPsec, based on its own business objective. This is a problem for BGPsec, because an AS cannot validate the correctness of a path unless all ASes on the path have applied their signatures to the BGP UPDATE message. Thus, the security incentive for anyone to be ﬁrst to deploy BGPsec is insufﬁcient [25].

2.2 The SCION Architecture

Scalability, Control, and Isolation On Next-generation networks (SCION), is an inter-domain network architecture designed to address issues in the current Internet by providing highly available point-to-point communication [47]. Its goals are to offer security, availability, provide incentives for deployment and consider economic, political and legal issues at the design level, which are summarized below.

Availability in presence of adversaries Since there are various attacks on daily basis in the current Internet, a point-to-point communication that remains highly available even in the presence of adversaries is crucial [47]. Therefore, SCION prevents attacks, such as hijacking attack described in Section 2.1.1, by offering multiple paths between two end-hosts and using a secure routing protocol. Furthermore, as long as an attacker-free path exists, that path will be discovered and used with guaranteed bandwidth.

Transparency and control SCION provides greater transparency and control of the forwarding paths taken by the network packets and the trust roots, comparing to the current Internet and BGP [47]. By separating control plane, which determines networking paths and data plane, which forwards packets according to the determined paths. The forwarding in SCION cannot be inﬂuenced by control plane operations, such as routing changes, because the forwarding paths are speciﬁed by the sender. While in the current Internet, the forwarding 14 CHAPTER 2. BACKGROUND

paths cannot be chosen and are inﬂuenced by the control plane operations. The separation enhances the availability, by enabling multipath communication, where the sender selects paths to carry packets towards the destination. Furthermore, the path of the packet is carried in its header, which enables the destination to reverse the path to re- turn its response to the sender. Thus, mitigating reﬂection attacks and providing a powerful mechanism against DoS and DDoS attacks. The above-mentioned properties, allow endpoints to know and verify the forwarding path taken by the network packets. Furthermore, it is useful for transmitting sensitive data, as it can ensure that packets traverse certain ISPs and avoid others. Thus, it allows ASes to control the incoming path segments through which they are reachable, and given path segments, senders can create end-to-end paths.

Efficiency, scalability, and extensibility Aside from the lack of availability and transparency, current Internet suffers from a number of stability issues. For example, BGP encounters stability issues in cases of network fluctuations, where routing protocol convergence can require minutes. Moreover, forwarding tables have reached their scalability limits, due to announcements of more specific IP prefixes and multi-homing, connecting a host or network to multiple networks [47]. Extending the memory size of routing tables is challenging, as the underlying hardware is expensive and power-hungry. It consumes on the order of a third of a total power consumption of a router. Hence, SCION’s end-to-end communication without content caching consumes 15-50% less power than other network architectures, such as Sprint and AT&T [47]. Instead of storing forwarding state in routers, SCION encodes states into packet headers and encrypts each state. By using block ciphers, such as AES, encryption can be computed faster than performing memory lookups and result in more efficient and simpler router architecture. Furthermore, the whole core architecture and source code of SCION is designed to be easily extensible with additional functionality. CHAPTER 2. BACKGROUND 15

Support for global but heterogeneous trust Given the diverse legal jurisdictions and interests in the current Inter- net, scaling the authentication of entities to a global environment is challenging [47]. The most commonly used PKI models do not scale to a global environment, because of mutually distrusting entities cannot agree on a single trust root. Furthermore, security of trust roots is only as strong as its weakest link. Thus, SCION is scaling the authentication of entities, such as ASes for routing to a global environment [47].

Deployability Aside from above mentioned properties, SCION offers robustness to configuration errors, fast recovery from failures, high forwarding efficiency, multipath forwarding, and more [47]. Thus, it offers sufficient incentives to upgrade the current Internet to SCION.

TRC Core link Prov.-Cust. link ISD core AS Peering link

TRC F ISD ISD TRC core ISD core C1 C3 TRC

C2 ISD ISD ISD core A ISD I B

K L G H E C J

Figure 2.2: ASes are grouped into four ISDs. The core ASes are connected via core links, while non-core ASes are connected via provider- to-customer or peering links. For example, the AS I and K participate in two ISDs. Furthermore, the ﬁgure was inspired by the Figure 2.1 in the SCION book [47]. 16 CHAPTER 2. BACKGROUND

In order to achieve above mentioned properties, SCION introduced the concept of an ISolation Domain (ISD), see Figure 2.2. An ISD consists of numerous ASes, where multiple ASes form the ISD core, which controls the whole ISD through a policy called Trust Root Configu- ration (TRC). The TRC has been negotiated by the ISD core, and de- fines the roots of trust that are used for validation of bindings between names and public keys or addresses. Each SCION AS consists of beacon servers, path servers, certificate servers and name server which are explained below. Further- more, border routers provide connectivity between ASes, while internal routers forward packets inside the ASes. • Beacon server - discovers path information with PCBs. • Path server - advertises path information through PCBs. • Certificate server - assists with path validation by keeping cached copies of TRCs, cached copies of AS certificates, and keys and certificates for secure inter-AS communication. • Name server - provides name resolution from user understand- able names to SCION addresses, like DNS in current Internet. Routing in SCION is divided into two levels, intra-ISD and inter-ISD routing. Both levels utilize Path-segment Construction Beacons (PCBs) to explore routing paths. The PCBs are initiated by the core ASes, and sent to the downstream ASes, in order to gather all metadata required to build forwarding paths. Upon receiving a PCB, the ingress border router detects that the destination is a SCION service address (SCION address with specified service type), and sends the PCB to one of its beacon servers. The beacon server verifies the structure and the signature of the PCB, as well as checking if TRC(s) and certificate(s) appended to the PCB are relevant. If not, they can be requested from the upstream beacon server, and then forwarded to a local certificate server. However, if a PCB verification is successful, the beacon server registers the PCB at the path server. Next, the beacon server propagates the registered PCB to its downstream and peering ASes. For every registered PCB and for every interface that connects to a downstream AS, the current AS creates a new PCB, by appending a new AS entry. The AS entry contains hop fields that authenticate the permis- sion to send traffic between ingress and egress interfaces, and authenticate forwarding between the peer interfaces and the egress interface. CHAPTER 2. BACKGROUND 17

Lastly, the set of created PCBs are sent to the border router corresponding to the egress interface, and then forwarded to the downstream ASes [47]. Since the hop fields are necessary for the border routers, in order to forward packets according to the specified path, they are authenticated. The hop fields contain encoded ingress and egress interfaces of the ASes on the forwarding path, the expiration time and Mes- sage Authentication Code (MAC). The verification of a hop field on a SCION border router, requires only one AES-MAC computation, and that can be computed faster than performing memory lookups on modern hardware [47]. Furthermore, the leaf ASes registers only paths with the local path server and the core path server, since PCBs are never propagated upstream. An ISD core AS announces a PCB and propagates it as a policy- constrained multipath flood for either intra-ISD or inter-ISD paths. Inter-ISD path exploration or also called beaconing, is similar to BGP’s route advertising process. Although, in SCION the process is periodic and discovers multiple paths between any pair of core ASes, which provides SCION with additional properties comparing to BGP. Fur- thermore, a path segments from a non-core AS to the ISD core is called an up-path, while a path from the ISD core to a non-core AS is a down- path. Lastly, a path segment between ISD core ASes is called a core- path. The SCION project started in Summer 2009 at Carnegie Mellon University, and has experienced various changes over time. At the moment of writing the thesis, SCION is an open source project which is deployed worldwide, and is being used by various companies as a backup solution to the legacy Internet. The SCION architecture is written mainly in Go, and uses QUIC/UDP layer-4 protocols instead of TCP/UDP, which are heavily used in the legacy Internet [47]. Lastly, it offers an experimental environment called SCIONLab, which can be used to try out the benefits of using SCION.

2.2.1 The SCION-IP Gateway (SIG) In order to inter-operate with the IP world, SCION provides a service called SCION-IP gateway (SIG). The service routes and encapsulates inter-AS trafﬁc, and enables IP end-hosts to beneﬁt from SCION, by transparently obtaining SCION properties. By offering IP end-hosts 18 CHAPTER 2. BACKGROUND

to use SCION transparently, it enables end-hosts to experience the SCION benefits and slowly move over to SCION as the main inter- domain architecture replacing current Internet. However, the SIG service has to be deployed by every SCION AS that wants to enable IP connectivity [47]. All layer-4 protocol traffic between SCION ASes, is supported and handled by the SIG service. As described in Figure 2.3, the sending side encapsulates the traffic by converting IP packets into a byte stream, which is sent to the remote SIG service. The stream contains IP (layer-3) content and above contents of the encapsulated IP packets, which are decapsulated back to IP packets by the receiver. The traffic goes through the SIG service according to the IP routing rules, without making the hosts aware of SCION involvement. Thus, SIG service must be fast, in order to keep up with the traffic flow, and robust to deal with any packet loss in the encapsulated traffic.

Sender Receiver

SIG SIG SCION 100101... SCION IP IP IP IP

Figure 2.3: SIG service on the sender’s side encapsulates IP packets into SCION packets, and sends them as byte stream to the remote host. The remote host’s SIG service decapsulates the SCION packets back into IP packets, and forward them according to the routing rules.

Sending encapsulated trafﬁc over SIG, requires resolving the address and port of the remote AS. By sending a query to the remote SIG service address, the remote AS will respond with its own address, SCION control port and encapsulation port if the SIG is supported. The encapsulation port is required to distinguish from SCION control trafﬁc. However, if SIG is not supported, the border router of the remote AS will send a SCION Control Message Protocol (SCMP) Unknown Host error message as response. Furthermore, if no response is received to two consecutive queries, the sending SIG service will use the remote SIG address again, and start sending packets to the new address it receives in response. This allows failover in case the remote SIG instance CHAPTER 2. BACKGROUND 19

becomes unreachable. When the SIG service receives an IP packet, it needs to determine the SCION AS to which destination IP belongs. Since ASes can claim IP prefixes it does not own, either maliciously or by misconfigura- tion, the mapping from IP to SCION AS needs to be verifiable. This is achieved by each SCION AS exporting an IP Allocation Config (IAC) via its certificate server. The IAC contains a list of IP allocations the AS owns, together with the public key of the AS. Furthermore, each list of IP prefixes is signed by the corresponding RPKI authority, such as IANA, and contains SCION ISD-AS identifier and timestamp. Lastly, each IAC is signed with the private key of the AS, which is the private key that corresponds to the public key contained in the signed IP prefix list [47]. When a new SIG service is deployed on a SCION AS, it will announce its IAC to neighbor SCION ASes in order to quickly enable operation. Hence, when a SCION AS supporting SIG receives an IAC, it will verify the signature of the IAC and construct a local mapping of IP prefixes to SCION ASes. Although, if an IP packet arrives with a destination address that is not covered by the local map, it will be routed to the legacy Internet.

2.3 Blockchain

Blockchain technology can be traced back to 1991, when Haber and Stornetta [28] described the first work on a cryptographically secured chain of blocks. A year later, Bayer, Haber, and Stornetta [5] implemented Merkle trees into the design enabling several documents to be collected into a block. However, blockchain technology gained significance first in 2008, when Satoshi Nakamoto published the Bitcoin white paper [41]. The invention of the Bitcoin made it the first digital currency (cryptocurrency) to solve the double spending problem, spending the same asset twice, without the need of a trusted central authority. Furthermore, the blockchain technology has enabled mutually mistrusting entities to transfer ownership for digital resources, without relying on a central trusted third-party. In order to enable these properties, the blockchain technology is built upon a distributed ledger (immutable log), that records all transactions between parties in the system into blocks. 20 CHAPTER 2. BACKGROUND

Blocks and mining Each block may be divided into a block header and a payload, see Figure 2.4. The block header contains the metadata of the block, such as hash pointer to the previous block, the Merkle root derived from the payload (transaction data) and a timestamp [22]. In order to create new blocks and validate every transaction, a mining is required. The task of a miner is to connect to the blockchain network, listen for all transactions that are being broadcasted, listen for new blocks that other miners have found and maintain a view of the current blockchain. Additionally, the miner wants to validate all the blocks and all the transactions that are in the chain. The miner is now capable of calculating new blocks, and contributing to the blockchain network. The validation is vital for blockchain technologies such as Bitcoin, therefore the incentive to encourage the miners is the reward. Supposing that a miner finally finds a block, she has to announce it and hope that it will be accepted and validated by all of the other miners. Furthermore, it is necessary that the new mining is being performed on top of this block, and that other miners do not accept some competitor’s block instead. Hence, if all of the above is realized, the miner will get its reward. Although, in order to calculate a new block, heavy computation is required. The miner has to compute the hash of the previous block, the pending transactions and a nonce, while the output must be strictly less than the difficulty [10], see the formula below.

Hash(Hash(Blockprev)|Transactions|Nonce) < Difﬁculty

In order to find the nonce, the miner must perform the method called brute-force, where the miner attempts to find the right combination of the header, transactions and the nonce. Eventually, the miner will find a block with a valid hash that is strictly less than the difficulty. At this point the miner wants to announce the newly computed block as quickly as possible in order to get profit from it. The difficulty is a 256-bit hash output from the SHA-256 hash function, where at least the first 64 bits of the hash must be set to 0. This is a hug number, which is chosen again every two weeks in Bitcoin, based on how efficient the miners were over the previous two weeks. The new difficulty value is calculated by multiplying the previous difficulty with two weeks divided by the time it took to mine last 2016 CHAPTER 2. BACKGROUND 21

blocks, see the formula below. The value 2016 comes from the Bitcoin white paper [41], where the goal is to announce a new block every 10 minutes for a two weeks period [10].

New_difﬁculty = Prev_difﬁculty∗(2 Weeks)/(Time to mine last 2016 blocks)

Genesis block Block Block

Header (hash) Header Header

Transactions Transactions Transactions ......

Figure 2.4: Each newly mined block is chained to the previous blocks all the way to the the initial block, called genesis block.

Transactions A transaction is an instruction that changes the ownership of an asset, and modiﬁes the blockchain state. Furthermore, transactions can be signed using a digital signature, a digital code generated and authenticated by public key encryption. The signature is attached to the transaction, in order to verify its content and the sender’s identity. Each sender signs a hash of the previous transaction and the public key of the receiver, which are then appended to the block. A receiver can verify the signature of the transaction in order to verify the chain of ownership [41]. This ensures that assets can only be spent if they belong to the sender, and claimed if the receiver can sign the transaction in order to prove ownership. Newly calculated blocks and transaction are shared through a P2P network, making it difﬁcult to manipulate the chain. A P2P network is a collection of loosely coupled interacting autonomous nodes. It is decentralized and nodes may join and leave the network freely. If all participating nodes have the same privileges it is called a pure P2P network [44]. Resources are typically shared between the nodes, and in order to join the network only a node has to be known. This node is called a seed node [9]. 22 CHAPTER 2. BACKGROUND

Centralized (A) Decentralized (B) Distributed (C)

Figure 2.5: Centralized (A), decentralized (B) and distributed (C) network models. Circles illustrates peers (nodes) and edges are links (connections) between peers.

Blockchain types Blockchain technology can be either permissioned (private) or permissionless (public). Hyperledger [1] is an example of a permissioned blockchain, which is closed and centralized, see Figure 2.5. A central entity decides and attributes the rights to individual peers to participate in the blockchain. Thus, only a limited set of peers are authorized to participate, and each participant has a unique identity. It enables the use of policies to constrain network participation and access to transaction details. This provides organizations with the ability to easily comply with data protection regulations. Furthermore, private blockchain is more effective at controlling the consistency of the data that gets appended to the blockchain. With the ability to use policies and restrictions on transaction details, more details can be stored in the blockchain. This allows participants to specify transaction information, and deciding who is able to view the information [59][26]. CHAPTER 2. BACKGROUND 23

Permissionless blockchain, such as Bitcoin and Ethereum, are open and decentralized, see Figure 2.5. Any peer can join and leave the network at any time, since there is no central entity which manages the membership or which could ban illegitimate peers. Furthermore, the content in public blockchains is readable by any peer. Hence, the level of transaction details may be limited to protect conﬁdentiality and anonymity. With the use of cryptography primitives, it is techni- cally feasible to design a permissionless blockchain which hides privacy relevant information (e.g. Zerocash) [59].

Consensus mechanism In order to verify and commit transactions to the ledger, a consensus mechanism (agreement) is needed. At the moment of writing the thesis, there are various consensus mechanisms, such as Proof of Work (PoW) and Proof of Stake (PoS). Proof of Work is the mainly utilized consensus mechanism and is useful on public blockchains with anonymous participants. It is used in e.g. Bitcoin and Ethereum. However, it consumes considerable computing power and electricity, making it expensive way to reach consensus. The reason for the expensive commitment, is because of the difficulty to compute a new block. A transaction is assumed unconfirmed, until at least 6 new blocks have been appended to the chain after the transaction. Hence, it is necessary to compute new blocks and append them to the blockchain in order to confirm the transaction. However, this expense is unnecessary on a private business network where all participants are known [26]. Proof of stake on the other hand is a consensus mechanism used to validate transactions. Validators must own a certain percentage of the network’s total value. PoS might provide increased protection against malicious attacks on the network, by reducing incentives for attackers and by making it expensive to execute attacks. However, this mechanism reduces the computing power and electricity consumption, by selecting next miner from the network [26]. Numerous other consensus mechanisms exist and are being extensively researched in order to decrease necessary computing power, electricity consumption and increase the protection against malicious attacks [26]. At the writing of the thesis, blockchain technology is mainly used 24 CHAPTER 2. BACKGROUND

for cryptocurrencies. However, there are great expectations that the technology can be used in other ﬁelds. For example, Ethereum is using blockchain technology to execute arbitrary code within smart contracts. Furthermore, it can be used for communication between In- ternet of Things (IoT) devices, blockchain based PKIs, and numerous other solutions can be secured and improved with this technology.

2.4 Bitcoin

Bitcoin is the first digital currency (cryptocurreny) to solve the double spending problem without the need of a trusted central authority. It has become inspiration for many additional cryptocurrencies and blockchain-based applications [41]. At the time of writing the thesis, Bitcoin is the most successful cryptocurrency with more than 17 million bitcoins valued at approximately 115 billion USD [6]. It is a permissionless blockchain, that utilizes bitcoins (cryptocurrencies) as its assets in order to perform anonymous transactions. Fur- thermore, it utilizes PoW consensus mechanism and it is written in C++ [41][7]. Bitcoin is a P2P network where each node maintains a list of IP addresses of potential peers. The list is bootstrapped via a DNS server, and additional addresses are exchanged between peers. By default, each Bitcoin node initiates 8 TCP connections to peers in various /16 prefixes. All incoming connections are accepted on port 8333 by default, and the amount of incoming connections are limited to 117. Fur- thermore, the communication is in plaintext, without any integrity checks [3]. The nodes are continuously listening to block and transaction announcements, which are sent via INV messages. If a block is received, the INV message will contain the hash of the announced block which is used by the receiver to determine if it already holds it. In case it does not hold the newly announced block, the receiver sends a GET- DATA message to a single neighbor (peer). The peer then responds by sending the requested information in a BLOCK message. The difficulty of block creation in the network is set to 10 minutes on average, which is sufficient time for blocks to propagate through the network. If a requested block does not get delivered within 20 minutes, the requester will disconnect from that peer, and request the CHAPTER 2. BACKGROUND 25

same block from another peer [3]. Nodes propagate transactions through the network in a similar way, with INV, GETDATA and TX messages. These messages announce, request and share transactions that have not yet been appended to the blockchain.

2.5 Ethereum

Ethereum is a cryptocurrency powered by blockchain technology, that can either be permissionless or permissioned. Thus, the transactions can be either anonymous or private. Furthermore, Ethereum utilizes ether as its asset and it was the ﬁrst cryptocurrency that introduced smart contracts. A smart contract is a high-level programming ab- straction that is compiled down to Ethereum Virtual Machine (EVM) bytecode and deployed to the Ethereum blockchain for execution. The programming language is Turing-complete and can be written in So- lidity, Serpent or LLL [22]. The consensus mechanism in Ethereum is the same as in Bitcoin, namely PoW. Although, Ethereum creator Vitalik Buterin and his development team are actively working towards switching to the PoS consensus mechanism, that will be released in the near future [22]. Ethereum client has been implemented in various programming languages, such as Go, C++, Python and Java [17]. Geth is a command line interface implemented in Go for running full Ethereum nodes. It supports all operations an Ethereum account is capable of, such as mining ether, exploring the block history of the Ethereum network and more. Furthermore, Geth is an open source project, that is available through Github [19]

2.5.1 Node discovery protocol Peer-to-peer communication between Ethereum clients utilize ÐΞVp2p Wire Protocol, and standards such as Recursive Length Preﬁx (RLP) to serialize objects. The ÐΞVp2p nodes communicate by sending messages using RLPx protocol, that utilizes Kademlia-like UDP routing which has been repurposed as a P2P neighbor discovery protocol [38]. The major difference from Kademlia [40] is that packets are signed, node IDs are 512-bit public keys, Distributed Hash Table (DHT) features are not implemented and xor distance metric is based on 26 CHAPTER 2. BACKGROUND

SHA3(nodeID) [38]. RLPx is an encrypted and authenticated transport protocol, that provides higher privacy and integrity than plaintext im- plementations, such as in Bitcoin. Furthermore, each node monitors the Quality of Service (QoS). It calculates statistics and drops or bans nodes that have low uptime and slow respond to ping messages. All cryptographic operations in Ethereum are based on Elliptic Curve Cryptography (ECC), specifically secp256k1. Each node in the ÐΞVp2p protocol has a cryptographic identity (nodeID), which is a key on the secp256k1 curve [18]. The distance between two nodes is the bitwise exclusive or (xor) on the hashes of the public keys (nodeIDs), taken as the number [18]. Furthermore, packets are dynamically framed, pre- fixed with an RLP encoded header, encrypted and authenticated. From a messaging point of view, the protocol supports four UDP- based Remote Procedure Calls (RPCs) on port 30303 by default. Ping probes a node to see if it is online, and the receiver should reply with a Pong packet. Findnode packets are sent to locate nearest nodes to a given target ID, where the receiver should reply with a Neighbors packet. The Neighbors packet contains the k closest nodes to the requested target ID, that it knows about [20]. Inside the Ethereum packets, there are messages on which integrity and authenticity is checked. The integrity is verified by comparing the first 32 bytes of the message, with the SHA3-256 hash of the rest of the message. If the hashes are not equal, the message is corrupt and the packet is dropped. The authenticity is verified by checking the signature. Each message is signed using the Elliptic Curve Digital Signature Algorithm (ECDSA), specifically secp256k1. Given the signature, the message that was signed and the knowledge of the curve, it is possible to recover the public key (nodeID) corresponding to the private key used to sign the message [20]. If the recovering of the key fails, the packet is being dropped. Furthermore, it is necessary to verify the signed message, otherwise the message cannot be authenticated. When a new Ethereum client connects to the Ethereum main network for the first time, it will connect to the predefined bootnodes. Bootnodes or bootstrap nodes, are assumed to always be available, and they maintain a list of all nodes that have connected to them in a period of predefined time. When the newly connected Ethereum client has obtained its neighbors from the bootnodes, it initiates the connection to the neighbors in order to establish encrypted connection over TCP [18]. CHAPTER 2. BACKGROUND 27

2.5.2 Establishing encrypted connection At this point, the newly connected Ethereum client has obtained all necessary information about its neighbors, such as TCP listening ports (30303 by default), from the node discovery protocol. In the next step, it is assumed that the underlying transport layer has an already established connection between the neighbors, and the client can establish a peer session between them [18]. The session is established in two phases, first a peer authentication with an encrypted handshake and then the base protocol handshake, see Figure 2.6. The purpose of the first phase is to exchange ephemeral keys and establish a secure communication channel between peers, by setting up an encrypted and authenticated message stream. The key exchange is an Elliptic Curve Integrated Encryption Scheme (ECIES) encrypted message, which includes ephemeral keys for Perfect For- ward Secrecy (PFS). In the second phase, it negotiates supported protocols, such as Ethereum sync (Eth), Whisper (Bzz) and Swarm (Shh), checks versions, network IDs and some other parameters specified in the DΞVp2p wire protocol specification [38]. All packets following the encryption handshake, including base protocol handshake, are framed, encrypted and authenticated using the setup negotiated during the encryption handshake. If the handshake process succeeds, the array of protocols supported by both peers will be exchanged over the connection. Once the connection is established, packets are encapsulated as frames which are encrypted using AES-256 in CTR mode. Furthermore, the encryption handshake is responsible to negotiate initial values for the message authentication and cipher, which are never the same. The connection is secured by encryption and authentication, where encryption and authentication are done frame by frame separately for headers and payload. A Hash-based Message Authentication Code (HMAC) is utilized for incoming (ingress) and outgoing (egress) traffic. Egress MAC is updated with the plaintext of the outgoing frame’s payload, and the checksum is sent appended to the frame in plaintext. Ingress MAC is updated with the plaintext of the decrypted frame’s payload, and the checksum is verified against the MAC received appended to the frame. If there is a mismatch, the data stream has been tampered with, and the connection must be terminated. If they match, it proves the authenticity of the frame. Furthermore, all messages have 28 CHAPTER 2. BACKGROUND

deadlines, meaning that if a message does not arrive within a speciﬁed time, either side may disconnect [38][21].

Initiator Receiver

Authentication message

Authentication respond message

Establish secure session

Base protocol handshake

Figure 2.6: Establishment of a secure connection between two Ethereum nodes. Chapter 3

Related Work

This chapter shows the current state of the ﬁeld as well as importance of this thesis work. Research has shown consequences of BGP hijacking attacks on various applications, as well as numerous proposals to mitigate such attacks. Lastly, existing Multipath TCP solutions and on-going research are presented.

Extensive research has been made about BGP hijacking attacks [3][4]. As explained in Section 2.1.2, numerous security extensions for BGP have been proposed, although without wide deployment yet [62][25][50]. However, the paper by Apostolaki, Zohar, and Vanbever [3], is the first to show the consequences of routing attacks on cryptocurrencies, specifically on Bitcoin. Routing attacks on AS level have been studied previously, and applied on various technologies [3]. An example is routing attacks on Tor, for attacking the privacy [3][54]. It is known that Tor is vulnerable to attacks which can observe traffic at both ends of the communication path, however the paper by Sun et al. [53] presents a suite of new attacks, called Raptor. Raptor attacks can be launched by ASes to compromise user anonymity by:

• Exploiting the asymmetric nature of Internet routing, in order to increase the chance of observing at least on direction of user trafﬁc at both ends of the communication.

• Exploiting BGP path changes over time, in order to observe additional Tor trafﬁc on the new ASes.

• Strategically manipulate Internet routing via BGP hijacks, to dis-

29 30 CHAPTER 3. RELATED WORK

cover specific Tor guard nodes and interception for traffic analysis. This research illustrates the problems which are caused by centraliza- tion and routing attacks on a distributed system running on top of the Internet. Tor and Bitcoin differ vastly in their behavior. Tor is routing messages in an Onion-like fashion, where messages are encapsulated in layers of encryption, analogous to layers of an onion. These are then routed through onion routers that "peels" away a single layer, uncov- ering the message’s next destination. While, Bitcoin uses random connections to flood the entire network with messages. However, both of these routing strategies are vulnerable to routing attacks in a centralized network [3].

As mentioned above and in Section 2.1.2, extensive research has been done about how to secure data communication and routing in the In- ternet, as well as proposing numerous mitigation protocols. How- ever, none of proposals nor third-party services solves the problem adequately in practice [51]. Thus, a recent paper by Sermpezis et al. [51], proposes a detection and neutralization system called ARTEMIS (Automatic and Real-Time dEtection and MItigation System). ARTEMIS is operated by the AS itself, and detects hijacking events for its own prefixes by using a local configuration file with information about prefixes owned by the network. Furthermore, it receives the stream of BGP updates from the publicly available monitoring services, and from the local routers operating the network. By comparing the prefix and AS-PATH fields in the BGP updates with the information in the local configuration file, it can detect any hijacking event and generate alerts [51]. According to Sermpezis et al. [51], the ARTEMIS can neutralize prefix hijacking attacks within a minute. In the paper by Papadimitratos and Haas [45], the problem of secure and fault-tolerant communication has been addressed. The paper proposes two protocols, Secure Message Transmission (SMT) and Secure Single-Path (SSP). SMT can support real-time communication with nearly constant delay and jitter (deviation from true periodicity), while delivering 93% of the messages with no retransmission, even when 50% of the network nodes disrupt the transmission. SSP can be equally reliable as SMT, with less than one third of SMT’s network overhead. Their main difference is that SMT can utilize multiple paths simultaneously, like SCION [47], in contrast to the single-path opera- CHAPTER 3. RELATED WORK 31

tion of SSP. Lastly, both of these protocols can be applicable in wireless or wireline networks [45]. Secure Blockchain Trust Management (SBTM), is a general and flex- ible trust management framework proposed by Rocha and Papadim- itratos [50], to support secure inter-domain routing protocols. The framework is addressing difficulties in deployment of secure routing protocols and replacing current PKI or web of trust-based approaches with a blockchain protocol. Furthermore, it provides the establishment of security associations, the management of routing entities’ identities, credentials, keys and prefix ownerships, for any secure inter-domain routing system. Thus, this secures the discovery of communication paths among ASes from intentional attacks and misconfigurations, such as the announcement of unauthorized prefixes, the outright imperson- ation of ASes, or the modification of communication [50]. The National Cybersecurity Center of Excellence (NCCoE) at NIST, has recognized the need to ensure safe and secure Internet traffic exchange. Thus, the NCCoE has addressed the problem by launching part one of the project series: Secure Inter-Domain Routing: Route Hi- jacks [27]. The project will use commercially available technologies to develop a cybersecurity reference design, that can be implemented to increase security and functionality in Internet routing. This will be achieved by using RPKI, to address and resolve the erroneous network route announcements [27].

The security of blockchain protocols have been less explored from network-based attacks compared to other attack scenarios [3]. How- ever, Heilman, Kendler, and Zohar [30] have highlighted network- based risks in blockchain protocols, by demonstrating the ﬁrst eclipse attacks on Bitcoin’s P2P network. The eclipse attacks enable an adversary who controls a sufﬁcient number of IP addresses to monopolize all connections to and from a Bitcoin victim. Hence, the eclipse attacks have similar impacts as the partition and delay attacks explained in the paper by Apostolaki, Zohar, and Vanbever [3]. Furthermore, it enables the attacker to disrupt the victim’s connections and exploit attacks on Bitcoin’s mining and consensus system, such as double spending, self- ish mining and adversarial forks in the blockchain [3][30][39]. It was suggested that Ethereum’s peer-to-peer network is more resilient to eclipse attacks than that of Bitcoin, because of the number of outgoing connections and cryptographically authenticated messages 32 CHAPTER 3. RELATED WORK

[39]. Although, Wüst and Gervais [60] have exploited Ethereum’s block propagation algorithm for eclipse attacks, by sending forged blockchain and then exploiting a ﬂaw in the algorithm to prevent the victim from connecting to other peers. Furthermore, a recent study by Marcus, Heilman, and Goldberg [39], have shown that it requires only two host, with respective IP address to perform eclipse attacks in Ethereum’s peer-to-peer network. Numerous countermeasures were proposed in each paper as well as in the comprehensive survey on the Bitcoin protocol by Bonneau et al. [11], where some of the countermeasures are currently being implemented in each blockchain protocol [30][39]. Furthemore, since the routing attacks on Bitcoin’s peer-to-peer network is a recent discovery by Apostolaki, Zohar, and Vanbever [3], there is no prior research nor proposed solutions. However, the researchers at ETH Zürich, have recently found a feasible solution. A relay network that will protect the bitcoin system and potentially any application running on top of the blockchain technology from routing attacks [2]. The proposed solution is currently being realized in a Master’s thesis project, supervised by Apostolaki and Vanbever [2]. The goal is to design and implement a protocol, that enables scalable communication between a network de- vice which acts as a relay node, and an extended Bitcoin client [2].

Alternative solution for increasing network reliability and performance is Multipath TCP (MPTCP) [29], which has been implemented in Linux kernel, Apple iOS and macOS, Citrix load balancers, FreeBSD and Or- acle Solaris [8]. Since iPhone and iPad users are likely to move in and out of Wi- Fi range, switching between cellular and Wi-Fi network is required. Thus, Apple has implemented the ﬁrst large-scale MPTCP extension in 2013, to support Siri in iOS 7 [14]. Furthermore, Apple opened MPTCP extension in iOS 11 to support all applications [55]. MPTCP extension enables iPhone and iPad connecting to the same destination host with multiple connections over different network adapters, such as Wi-Fi and cellular. The primary TCP connection is over Wi-Fi, and the backup connection is over cellular data. Thus, providing reliable and efﬁcient connection between hosts within the existing network infrastructure [32] [33].

As presented, some related work is done in nearby areas to the the- CHAPTER 3. RELATED WORK 33

sis scope. Although, to the best of our knowledge no academic paper is yet presented with a solution to the recent discovery by Apostolaki, Zohar, and Vanbever [3], and especially not with the SCION infrastructure [47]. Consequently, a solution to BGP routing attacks, blockchain technology hijacking and reliable and efﬁcient paths through the Inter- net is lacking in academic spheres, and is hence aimed to be provided by the thesis. Chapter 4

Solution Design

This chapter will explain the problem in more detail, and also propose a solution.

4.1 Problem

As described in Section 2.1.2, multiple security extensions for BGP have been proposed, although none of them is widely deployed due to various reasons. Hence, the Internet is still vulnerable to routing attacks and can affect any largely centralized network. Thus, it is vital to ﬁnd a mitigation to such attacks. Furthermore, some argue that instead of securing BGP, an entirely new inter-domain architecture should be deployed [43]. Since SCION architecture is being developed at the time of writing the thesis, it was interesting to investigate if the routing attacks can be mitigated by using it. However, it was not clear if the current state of the SCION was stable enough to deploy a blockchain technology. Furthermore, all functions and libraries mentioned in the SCION book [47] were not entirely implemented because SCION is under development. For example, discovery protocol for SIG was not implemented, see Section 2.2.1. Thus, the discovery protocol was created for the SIG proxy solution without any security guarantees. The Implementation can be done in various ways, although two approaches are considered by the thesis:

1. Implement SCION at application level within a blockchain technology.

34 CHAPTER 4. SOLUTION DESIGN 35

2. Create a SIG proxy solution that wraps around a blockchain- based application and routes all trafﬁc through either IP or SCION.

Furthermore, a decision has to be made about how SCION will be deployed. It can be used as the only way of communication instead of the IP, simultaneously with the IP, or as a backup solution to IP when it gets disrupted. This, requires further decisions to be made, e.g. when to switch from the IP to SCION and how to detect disruptions or BGP hijacking attacks.

4.1.1 Assumptions and limitations In the thesis it is assumed that the chosen cryptography within a blockchain technology and SCION is secure. Therefore, vulnerabilities within the cryptography or similar aspects are out of scope for the thesis. Fur- thermore, it is assumed that the Internet is not disrupted during the initial connections made by the proposed solutions. At the time of writing the thesis, SCION was mainly written in Go. Therefore, in order to implement SCION at the application level, a blockchain technology which is written in Go has to be chosen. The Bitcoin on which the routing attacks were executed by Apostolaki, Zo- har, and Vanbever [3], is written in C++ and cannot be used. Thus, a second biggest cryptocurrency at the time of writing the thesis is used as the Proof-of-Concept (PoC), namely Ethereum (v.1.8.4). As explained in Section 2.5, messages in Ethereum are encrypted, making the routing attacks more difﬁcult. Furthermore, it is not clear if Ethereum is as centralized as Bitcoin due to the mining pools. How- ever, even if the content of the packets is encrypted, it is still feasible to delay, drop or reject packets. Hence, if the Ethereum is quite centralized, routing attacks can make damage by making the peers discon- necting from each other, due to not receiving packets within deadlines.

4.2 Application level solution

Since the SIG service, see Section 2.2.1, was not entirely implemented at the time of writing the thesis, a naive solution is to implement SCION into Ethereum (v.1.8.4) source code. Thus, creating a solution which utilizes SCION, and shows that SCION is stable and efﬁcient enough to deploy a blockchain technology, speciﬁcally Ethereum. 36 CHAPTER 4. SOLUTION DESIGN

The proposed solution consists of several parts, see Figure 4.1. The Ethereum bootnode supports only UDP packets, see Section 2.5.1, and is illustrated with the IP box. Each Ethereum client (Geth) supports both UDP and TCP packets, see Section 2.5.1 and 2.5.2, and is also illustrated with the IP box. By replacing all IP boxes with SCION boxes, the communication will go over SCION only. However, that would isolate and limit the user from the other peers that are not using SCION. Thus, a solution should look like the Figure 4.1, with both IP and SCION boxes. This would provide the user with the opportunity to choose between IP and SCION communication, as well as utilizing SCION as a backup solution to IP.

Ethereum Bootnode

SCION

UDP

Ethereum Client Ethereum Client

SCION SCION

UDP UDP

QUIC QUIC

IP IP

UDP UDP

TCP TCP

Figure 4.1: Two Ethereum clients (Geths) are communicating with each other and an Ethereum bootnode. The various ways of communication is shown, via only IP or SCION, via both IP and SCION in parallel or via IP and using SCION as backup.

4.3 SIG proxy solution

If the application level solution is feasible, a more generic solution should be proposed. The solution should support any kind of blockchain- CHAPTER 4. SOLUTION DESIGN 37

based application, such as Bitcoin, and be independent of the release version. The proposed solution consists of several parts, see Figure 4.2. The main part is the SIG proxy application which executes any kind of application, captures all trafﬁc sent from or to that application, and decides whether to send the packets via IP or SCION to the peers. Furthermore, the running application is receiving IP packets, without knowing if the packets were sent over IP or SCION. The SIG proxy application utilizes applications that measure the quality of the connection between peers, and upon disruptions, it switches over to the more stable protocol which is supported by both peers. In order to be able to detect if the remote peer supports SCION, the SIG discovery protocol has to be implemented for the PoC. Thus, this solution is more robust than the application level solution, while leaving the source code of the running application intact.

VM1 - User X VM2 - User X

User Y User Y

Application Application

IP IP

SIG Proxy SIG Proxy

SCION SCION IP IP SIG SIG

SCION

Figure 4.2: Two blockchain-based applications of the same kind are communicating with each other, without knowing if the IP packets are sent over the IP or SCION network. The various ways of communication are shown, via only IP or SCION, via both IP and SCION in parallel or via IP and SCION as backup. 38 CHAPTER 4. SOLUTION DESIGN

4.4 Security model

In this thesis it is assumed that the adversary can compromise an IP and a SCION AS, utilized by the proposed solutions. By compromising an AS it is assumed that the adversary has gained admin permis- sion, and is capable of executing any desired attack. This exploit enables various attacks, such as DDoS attacks, eavesdropping and dropping, rejecting or delaying packets. However, the security model will focus only on the routing attacks on IP and SCION protocols, because it is of most relevance for the thesis. The attacking scenario is divided into 3 attack types, namely compromising a SCION AS, compromising an IP AS and compromising both an IP AS and a SCION AS. In this scenario, the proposed solutions utilizing SCION should be robust against routing attacks and disruptions. Depending on the chosen solution and way of communication, such attacks should be detected in the legacy Internet and continued over SCION. Chapter 5

Method

This chapter explains the methods used in this thesis as well as describe more in-depth the design of the proposed solutions, and information regarding how the results will be evaluated.

5.1 Literature research

First step of the thesis was a thorough literature research about blockchain technology, BGP hijacking and SCION architecture. The goal was to gain enough understanding about these ﬁelds, in order to be able to implement a solution that mitigates routing attacks in a blockchain technology using SCION. Initially, Google scholar platform was used to identify important research papers and books related to the study. The search started from the paper Hijacking Bitcoin: Routing Attacks on Cryptocurrencies [3], and then broadened using iterative method where references from important research papers were used. This paper was also the most important reference, because it was the foundation for the thesis. The second most important reference was the book SCION: A Secure Internet Architecture [47], which gave more in-depth understanding of the SCION architecture. Additional references were either provided by the supervisors, or found on the Internet.

5.2 Application level solution

Since SCION and Ethereum are written in Go, the ﬁrst step was to replace existing network communication in Ethereum with SCION.

39 40 CHAPTER 5. METHOD

Thus, most changes have been made to the p2p directory, which contains the network related code, specifically p2p/discover/udp.go and p2p/rlpx.go files. Udp.go file is the main file for the node discovery protocol which utilizes the UDP protocol. The rlpx.go file is mainly used for establishing encrypted connection as well as peer communication utilizing the TCP protocol [19]. The SCION architecture was developed with similar function names to the standard Go net [37] library, thus making the modification straightforward. This method was chosen as the first approach, in order to investigate how difficult, it is to implement SCION into an application’s source code. The modification of the source code does not have limitations, since access to all data is available. Furthermore, the implementation is compiled and executed, requiring no exterior applications that can affected the performance and hardly additional computing power is needed. SCION does not support TCP, thus it had to be replaced with the QUIC [36] protocol. Furthermore, the flags to indicate that the client or bootnode supports SCION, was implemented. Lastly, node information had to be expanded to support SCION, in order to share the SCION relevant information between peers.

5.3 SIG proxy solution

In order to to be able to support any blockchain protocol, a more generic solution called SIG proxy solution was investigated. The solution relies on the SIG service, see Section 2.2.1, which enables additional applications to make use of SCION without modifying the source code. However, this approach has limitations, such as not being able to alter the content of the packets. Furthermore, this approach requires additional computing power, because of multiple applications running simultaneously, resulting in possible performance degradation. Although, it has beneﬁts, such as being modular and additional extensions are easily added. Thus, being more robust and generic than the application level solution. CHAPTER 5. METHOD 41

5.4 SIG discovery protocol

This protocol was not deployed by SCION at the time of writing this thesis, thus it was necessary to implement it before creating the SIG proxy solution. When the SIG proxy application is running, it listens for any new IP addresses, either incoming or outgoing. Hence, when a new IP is detected, it will automatically send its SIG details to that IP on port 10001 (default port for the PoC), and listen for reply. If the remote host does not listen on the port 10001, the reply will be an error and that will indicate that the remote host does not support SIG. Although, if the remote host replies, the message is verified with regular expression, in order to verify if the received SIG format is correct. If the format is correct, a mapping between SCION and IP prefixes is created and appended to the SIG config file. Consequently, the SIG service enables sending IP packets over SCION to the IP addresses obtained from the SIG discovery protocol. Since this protocol was not the main focus of the thesis, it was created without any security guarantees. The messages are exchanged in plaintext over the TCP protocol. Hence, the messages are not encrypted and the integrity of the messages is not checked, resulting in vulnerability where an adversary could temper with the messages. Furthermore, the messages are not authenticated, which enables an adversary to start a server listening on port 10001 in parallel with its, e.g. Ethereum client, and send forged SIG details. The only security parameter of the protocol is the above-mentioned regular expression format verification. However, the validity of the received string is not verified nor tested. Thus, an adversary could tamper with the messages, and announce IP prefixes in the SIG details which it does not own in order to attract traffic. However, a more secure approach is presented in Section 2.2.1, and will be implemented in the future releases of the SCION.

5.5 Disruption Detection Tool (DDT)

In order to detect disruptions between two peers, a tool has been created. The tool relies on the assumption that the initial connection between the peers is not disrupted, meaning the initial values of the 42 CHAPTER 5. METHOD

measurements are accurate. Furthermore, during subsequent measurements, the initial values are updated if the new values are better, namely faster or lower. There are various approaches to detect disruptions in a connection. Thus, Round-Trip Time (RTT), packet loss and number of hops to the destination, also called Time To Live (TTL), were measured for the IP utilizing ping and traceroute. While for the SCION, only RTT and packet loss were measured utilizing pingpong. These values are then compared, and updated if they are better than the previously stored values. By default, this tool prefers IP over SCION. However, if the tool detects any values that are higher than previously by a threshold, say 20%, it will automatically indicate that SCION should be used. The threshold can be adjusted individually by the user or company. By using this tool, malicious attacks such as eavesdropping, dropping packets, delaying packets, path changes (potential routing attacks), would be detected. Thus, the packets would be sent over SCION without the user knowing about the disruptions, and without any negative consequences on the revenue. Furthermore, the tool is aligned towards RTT, namely it prefers the protocol that provides lowest RTT without any packet loss. Since the tool is an open source project, it can be altered by anyone. Thus, it enables individual adjustments for specific use cases, and therefore makes it harder for the adversaries. Since each tool is configured individually, it is difficult for the adversary to know which settings the victim uses in order to execute specific attacks against the tool. Furthermore, DDT does not detect bandwidth disruptions which could be of interest in specific use cases. Hence, the security of the tool is limited to three measurements, which are of most relevance for the blockchain technologies.

5.6 Evaluation

The proposed solutions will be evaluated in three aspects: security, availability and efﬁciency. The security and availability will be evaluated by applying the security model from Section 4.4 on the solutions. The proposed solutions must defend against attacks and disruptions speciﬁed in Section 4.4, in CHAPTER 5. METHOD 43

order to provide secure and highly available network communication. Efﬁciency will be evaluated by measuring network overhead, RTT, packet loss and TTL to three locations in the world with both SCION and IP, see Section 5.6.1. Lastly, power consumption using SCION instead of legacy Inter- net, and miners’ revenue with the proposed solutions will be evaluated.

5.6.1 Efficiency requirements The main efficiency requirement for the proposed solutions are that packets reach their destination with SCION as fast as with IP or faster. Furthermore, these solutions have to fulfill Ethereum’s deadline requirements for each message, e.g. 500 ms response timeout in node discovery protocol. The switching between IP and SCION has to be fast. However, it depends heavily on the DDT, which has to be executed frequently, in order to detect disruptions. Otherwise, it would result in undetected disruptions which could affect the blockchain technology, and not benefit from the redundant connection utilizing IP and SCION. There is no requirement on the network overhead. However, using as little bandwidth as possible is recommended. Thus, the parallel solutions with both IP and SCION is not preferable, while using only SCION or SCION as backup is the optimal solution according to the efficiency. Chapter 6

Implementation

This chapter will explain the hardware, software and the Ethereum network conﬁguration used for the implementation of the solutions and their design.

6.1 Hardware

The network and all participating clients were run on a personal laptop, namely Apple MacBook Pro 15". The laptop was running macOS High Sierra, version 10.13.6 with an Intel Core i7 2.4GHz processor, 8GB DDR3 RAM and 256GB storage.

6.2 Software

At the time of writing the thesis, SCION ASes were hosted on servers located at various places around the world, while the user-owned ASes were hosted on Virtual Machines (VMs). Three VMs were mainly used, and each VM had a bridged interface enabled. Hence, each VM had its own IP address, and was not hidden behind a Network Address Translation (NAT). Furthermore, since my SCION ASes were hosted on my laptop, they were hosted in Switzerland, Zurich. How- ever, each AS was connected to its attachment point located in the respective country through a tunnel. For example, my South Korean AS was hosted in Switzerland, but it was connected to a SCION AS in South Korea which is its attachment point. This is done in order to simulate that my AS is located in South Korea, and not requiring a server in South Korea to host my

44 CHAPTER 6. IMPLEMENTATION 45

AS. Thus, when RTT was measured, like in the Figure 6.1, a packet was sent from my SCION AS in Switzerland through a tunnel to the attachment point (AS) in Switzerland, which is then forwarding the packet through the SCION network to South Korea. When the packet has arrived to my South Korean attachment point (AS) in South Ko- rea, it will send the packet through a tunnel to Switzerland where my South Korean AS is hosted. Thus, the packets had to traverse the distance between Switzerland and South Korea twice, resulting in higher RTT. The IP RTT was measured from Switzerland to the attachment point (AS) of my South Korean AS, as shown in Figure 6.1. The reason is that the attachment point was hosted on a server in South Korea, and it had an IPv4 address which could be used for the measurement.

2 SCION 1

1 South Switzerland IP 2 Korea

1 2 SCION

1 ping SCION packet from Switzerland to South Korea

2 pong SCION packet from South Korea to Switzerland

1 ping IP ICMP ECHO_REQUEST from Swizterland to South Korea

2 ping IP ICMP ECHO_REPLY from Swizterland to South Korea

Figure 6.1: Demonstrating the paths which IP and SCION packets had to take during the measurement of RTT. The blue arrows show the paths of SCION packets, where the number 1 is the ping packet, and number 2 is the pong packet. The black arrows show the paths of IP ping packets from Switzerland to the attachment point of my South Korean AS.

The Ethereum was used for testing the solutions, where the Geth software was used to conﬁgure a private network and run all participating nodes. The version of the Geth was 1.8.4, and the test environment was 46 CHAPTER 6. IMPLEMENTATION

set up manually on the VMs hosting SCION. The programming language Go, version 1.9 was used, because the SCION architecture is only compatible with it. Furthermore, Ethereum libraries and functions had to be compatible with this version, in order to enable SCION to be implemented at the application level.

6.2.1 Ethereum network configuration A private Ethereum network had to be initiated using a genesis block and a network ID. The genesis block was constructed and presented in Listing 6.1. 1 { 2 "config": { 3 "chainId": 0, 4 "homesteadBlock": 0, 5 "eip155Block": 0, 6 "eip158Block": 0 7 }, 8 "alloc" : {}, 9 "coinbase" : "0x000000000000000000", 10 "difficulty" : "0x20000", 11 "gasLimit" : "0x2fefd8", 12 "nonce" : "0x0000000000008011", 13 "mixhash" : "0x000000000000000000", 14 "parentHash" : "0x000000000000000000", 15 "timestamp" : "0x00" 16 } Listing 6.1: Genesis block used in the thesis The genesis block is a Json file that specifies the difficulty for mining new blocks, maximum gas limit for transactions, pre-defined accounts (wallets) in alloc and nonce. The nonce is a hash which combined with mixhash proves that a sufficient amount of computation has been carried out on this block [58]. Additional parameters are left as default, since they are not required for the private network of the thesis. No accounts were pre-defined in the genesis block, thus each new account had to be initiated with the genesis block. Furthermore, the network ID had to be used in order to make the private network specific, and difficult for unknown clients to connect to it. Therefore, a network ID 8014 was randomly chosen, and it had to be specified with the networkid flag for the Ethereum clients and bootnode. CHAPTER 6. IMPLEMENTATION 47

For each test, the Ethereum network was restarted from the genesis node, and new accounts were created in order to forget previously established connections. Each account was created with the command: geth account new -datadir=, where datadir is an individual location where to store the necessary data about the account, such as database with known peers, keys, and more. In order to make the newly created account work with the specified network, it had to be initiated with the command: geth -datadir= init . The created accounts were also used as miners in order to test the network and connectivity between peers. A bootnode was created in order to test the network, and enable Ethereum clients to find and connect to each other. The bootnode was created by first generating an enode key, which is used by each client to connect to the bootnode. The enode key was generated with the command bootnode -genkey=boot.key and later started with the command bootnode -nodekey=boot.key

6.3 Design

The solutions were implemented in Go, because as mentioned earlier SCION supports only Go at the moment of writing the thesis. The source code for the respective solution is available at https://github.com/Aleksandaarrr/ETH-SCION-ONLY, https://github.com/Aleksandaarrr/ETH-SCION-IP and https://github.com/Aleksandaarrr/SIG-Proxy. The first two links are for the application level solutions, where the former is for utilizing either SCION or IP, and the latter is for utilizing SCION and IP simultaneously. The solutions consist of Ethereum source code which has been modified to deploy SCION. The third link is for the SIG proxy solution, which consists of a single file (SIG- proxy.go). This file has to be adjusted individually for respective application, and then compiled and executed by the user. SIG proxy solution will execute the desired application, capture the packets and detect if the remote peer supports SIG by utilizing SIG discovery protocol. In Appendix A, a typical scenario of both application level solution and SIG proxy solution, including all necessary commands is shown. Chapter 7

Results

This chapter will evaluate how well the proposed solutions perform based on the evaluation criteria given in Section 5.6.

Originally, the Ethereum source code supported only IP protocol, which was solved by modifying the network parts of the source code to include SCION. Thus, making it possible to run an Ethereum client over either IP or SCION, over both protocols simultaneously and over SCION as backup, see Section 4.2. This shows that it is feasible to deploy SCION along with a blockchain technology. Although, the problem at hand was routing attacks on Bit- coin. Therefore, it was important to propose a more generic solution, namely SIG proxy solution, that can run any blockchain protocol. The SIG proxy solution solves the main problem, since it is not limited to a speciﬁc blockchain protocol and release version, instead it supports any application. Thus, it is feasible to run Bitcoin over SCION, and mitigate the routing attacks. Furthermore, this solution enables same ways of communication as the application level solution, see Section 4.3. Both solutions propose an overlay or replacement to IP with SCION, and thus mitigate the routing attacks. However, there exist additional attacks on SCION and on the various parts of the proposed solutions, which are analyzed in Section 7.2.

48 CHAPTER 7. RESULTS 49

7.1 Security analysis

In Section 4.4, a security model has been designed containing an attack scenario that the proposed solutions should be able to protect against. The attack scenario consists of 3 attack types, where IP and SCION ASes get compromised in order to perform routing attacks.

7.1.1 Attack scenario In this attack scenario, the adversary is attempting to perform routing attacks in SCION and IP by compromising an IP AS and a SCION AS.

Attack type: SCION AS gets compromised If a SCION AS gets compromised, the adversary learns all cryptographic keys and settings. She can also control how the AS behaves, such as redirection of traffic, replay and modification of packets. Fur- thermore, the data signed by the AS, is valid until the corresponding certificates for that AS expire or are revoked [47] Since the paths are selected by the senders in SCION, the routing attacks cannot be performed in the same way as in the legacy Internet, see Section 2.1.1. However, a similar attack in SCION is called path manipulation attack, specifically path hijacking through interposition. The goal of the adversary is to attract traffic towards himself, towards another target, or to manipulate the path creation process, see Figure 7.1. 50 CHAPTER 7. RESULTS

PCB

PCB PCB M X

PCB B

Figure 7.1: Path hijacking through interposition in SCION. The ﬁgure was inspired by the Figure 13.1 in the SCION book [47].

In order to be on the path, an adversary might try to alter the path creation process. In Figure 7.1, a provider AS A sends two PCBs to customers AS B and AS M. The malicious AS M can eavesdrop on the link between AS A and AS B. Hence, the malicious AS M could try to intercept the PCB meant for AS B, and inject its own hop fields into the PCB before advertising it to downstream ASes. This offers AS B an interesting up-path traversing AS M to the upstream ASes. Further- more, if the adversary controls the path between AS A and AS B, the downstream PCBs from AS A can be blocked. Hence, the malicious AS M becomes the only up-path to the upstream ASes for AS B. However, the attack is detected by downstream ASes, since the PCBs advertised by AS A towards AS B, include AS B as an egress AS identifier. The adversary’s PCBs are not signed with the expect key, thus the verification of PCBs will fail and routing attacks in SCION are mitigated. If the adversary might want to insert an AS by modifying an already existing path, she would need to modify the corresponding hop CHAPTER 7. RESULTS 51

fields. The hop fields are integrity protected and include the previous hop field in the MAC calculation. Hence, the malicious modification of hop fields is prevented. Multiple other attacking scenarios are considered by the SCION book [47], such as creation of spurious ASes, peering link misuse, manipulation of the path selection process, fake up-link announcement, wormhole attack, and fake peering link announcement. Although, all of these scenarios have either limited impact, or require efficiently breaking the cryptographic primitives used in SCION.

Attack type: IP AS gets compromised If an IP AS gets compromised, the adversary would be able to perform various attacks, specifically routing attacks, see Section 2.1.1. The adversary could advertise IP prefixes from address spaces that are un- used or that belong to other ASes, and effectively redirect traffic to hosts under the control of the adversary. This is what had been explained in the paper by Apostolaki, Zohar, and Vanbever [3], and the vulnerability that is the foundation for the thesis. However, the proposed solutions have various approaches that can mitigate such attacks. As explained above, the solutions utilizing SCION as their only way of communication are not affected by this attack. Al- though, the solutions utilizing both IP and SCION are affected by this attack, and they are depending on the DDT. During routing attacks, the connection between peers will be disrupted. The disruption can result in, higher RTT, packet loss or change in the number of hops (TTL). These parameters should result in higher values than during the initialization phase, if the legacy Internet was working according to the assumption, namely without disruptions. Thus, the DDT stores the initial measurements to a remote peer, and during run time the stored values are replaced with lower values. Hence, when a disruption occurs, the DDT will detect it and indicate that it should switch over to the more stable protocol. This, should be enough to detect malicious ASes early and continue the connection over SCION without affecting the user.

Attack type: SCION and IP ASes get compromised If both IP and SCION ASes get compromised, the greatest concern is the routing attacks vulnerability in the legacy Internet, because the 52 CHAPTER 7. RESULTS

SCION is resilient against such attacks. The proposed solutions, emphasize redundant connections with both protocols, in order to mitigate the vulnerability in the legacy Internet and provide a secure and highly available network communication.

7.2 Availability analysis

The availability is evaluated according to the availability SCION provides by itself and if IP and SCION can contribute to higher availability together. Furthermore, the DDT has a signiﬁcant role in switching between the protocols and contributing to higher availability due to the redundant connections.

IP packets are disrupted If the IP is experiencing disruptions, the greatest concern is that the adversary might be able to perform DDoS attacks, eavesdrop, drop, reject or delay packets. However, the DDT should be able to detect such attacks early and indicate to switch over to a more stable connection, e.g. SCION. This, should be enough to detect disruptions early and continue the connection without availability disruptions. Although, this is only applicable to solutions utilizing both IP and SCION protocols.

SCION packets are disrupted If the adversary manages to compromise a SCION AS, the adversary can perform DDoS attacks, eavesdrop, drop, delay or alter packets that it should forward. However, the SCION architecture provides protec- tions against such attacks. Since SCION has separated the control plane and the data plane, the forwarding path selection is made in the control plane. Thus, lim- iting the adversaries that are not on the path. Furthermore, disabling adversaries to attempt to disrupt the connectivity of the chosen path and force the host to select a new path. Hence, the separation has contributed to enhanced availability, with help of multipath communication, which allows any sender to select multiple paths to carry packets towards the destination. The SCION has ﬁve mechanisms against DoS attacks. Path announcement with a short lifetime, non-registered or hidden paths, mul- CHAPTER 7. RESULTS 53

tipath communication, source authentication using OPT (extension providing source authentication against attacks with spoofed source addresses) and SIBRA [47]. These mechanisms can guarantee highly available communication between two end-hosts. The DDT is measuring also the SCION connections. Thus, if the solution utilizing both IP and SCION is used, the disruptions in the SCION network will be detected by the DDT. The connection will be then switched over to IP, if it is more stable. Although, if SCION is the only way of communication, then the mechanisms provided by SCION are the only protection, which is still greater than that in current Internet.

SCION and IP packets are disrupted If both SCION and IP are experiencing disruptions, it is important that both protocols are utilized by the currently used solution, otherwise it cannot guarantee availability. However, the solution utilizing IP and SCION simultaneous is the best choice in such situation, because it will utilize the ﬁrst best protocol. The protocols will race against each other, and the protocol that delivers the ﬁrst valid packet will be used. Hence, the running application will continue without noticing the availability disruptions in the protocols. Furthermore, the proposed solutions emphasize the redundant connection utilizing both IP and SCION. This solution lowers the risk of disruptions between peers, and provides higher availability. However, there might be situations where both protocols are performing badly.

7.3 Efﬁciency analysis

In order to analyze efficiency of SCION and IP, the protocols have to be measured and compared, see Section 7.3.1. The efficiency of the proposed solutions is enough to run a blockchain technology, specifically Ethereum. It is proved by exchanging the messages between peers within Ethereum’s deadline requirements. Fur- thermore, it is feasible to establish connection with Ethereum peers over SCION that are not located far away. Locations far away such as South Korea resulted in too slow response, due to the SCION ASes hosted in Switzerland, see Section 6.2. All packets had to traverse the 54 CHAPTER 7. RESULTS

distance twice, resulting in an RTT of approximately 600 ms, which is above the Ethereum’s node discovery threshold (500 ms). Thus, resulting in disconnection between peers. However, the problem was solved in Section 7.3.1 by dividing SCION RTT by a factor of 2. Furthermore, a noticeable difference between IP and SCION, is the initialization of new connections with SCION. It is slightly slower, but negligible and do not affect the establishment of connections between peers. The resources used by the proposed solutions depend on the individual conﬁguration. If the IP and SCION are utilized simultaneously, the network overhead will be twice the initial size, due to sending all packets over both protocols. However, the other ways of communication do not provide noticeably higher overhead, since they utilize one protocol at a time. Furthermore, the power consumption is depending on the selected solution, and the chosen way of communication. The simultaneous usage of both protocols contributes to higher consumption, while the other ways of communication might have slightly higher consumption than initially.

7.3.1 IP and SCION comparison The measurements presented in Table 7.1 and 7.2, have been executed from various locations in Switzerland, Zürich, and on the testbed explained in Section 6.1. IP and SCION were measured during 18 runs, where each run consisted of 25 RTT and packet loss measurements including number of hops (TTL) required to reach the remote server. Thus, 18 ∗ 25 = 450 RTT and packet loss measurements and 18 TTL measurements were performed. Furthermore, the measurements were executed on a daily basis during a week period. The performance was measured to three servers supporting both IP and SCION, each having their own column in Table 7.1 and 7.2. The three servers were located in Germany (Magdeburg), USA (Wiscon- sin) and South Korea (Seoul), and for each server the tables show ﬁve different values, each on every row:

1. Avg RTT, the average Round-Trip Time to the server.

2. Std dev RTT, the standard deviation of the Round-Trip Time.

3. Avg hops, the average number of hops (TTL) to the server. CHAPTER 7. RESULTS 55

4. Std dev hops, the standard deviation of the hops (TTL) to the server.

5. Packet loss, percentage of packets not reaching the destination.

IP Germany USA South Korea Avg RTT (ms) 28.781 126.005 287.131 Std dev RTT (ms) 1.395 8.947 15.597 Avg hops 15.2 18 18.6 Std dev hops 1.4 0.0 0,9 Packet loss (%) 1.4 0.0 0.0

Table 7.1: IP performance measured to servers located in Germany, USA and South Korea.

SCION Germany USA South Korea Avg RTT (ms) 62.568 150.734 301.898 Std dev RTT (ms) 3.246 6.213 6.247 Avg hops 7.7 7.7 8.8 Std dev hops 0.5 0.9 0.7 Packet loss (%) 0.0 0.0 0.0

Table 7.2: SCION performance measured to servers located in Ger- many, USA and South Korea.

From Table 7.1 and 7.2, it is clear that the IP has lower average RTT and lower jitter (std dev RTT) to a server in Germany. Although, the packet loss for the IP was slightly higher, and the average TTL to the destination were lower with SCION. The average RTT over IP was lower to the USA and South Korea, while the jitter and average TTL were lower with SCION to both des- tinations. The packet loss was the same for both protocols, namely no packet loss. 56 CHAPTER 7. RESULTS

Figure 7.2: 18 runs of RTT and packet loss measurements to a server in Germany are shown. The measurements are executed for both IP and SCION, and are shown in different colors.

Figure 7.3: 18 runs of RTT and packet loss measurements to a server in USA are shown. The measurements are executed for both IP and SCION, and are shown in different colors. CHAPTER 7. RESULTS 57

Figure 7.4: 18 runs of RTT and packet loss measurements to a server in South Korea are shown. The measurements are executed for both IP and SCION, and are shown in different colors.

The Figure 7.2, 7.3 and 7.4, show the RTT and packet loss for each run, with respective protocol and to each country. From the ﬁgures, it is clear that in most cases IP is faster than SCION. However, there are speciﬁc cases when SCION is faster than IP. In the Figure 7.1, the SCION has resulted in lower packet loss than the IP in the 3rd run, and lower RTT in the 12th run. The SCION had mostly slower RTT than IP to the server in the USA, except for in the last run, see Figure 7.2. Furthermore, there were no packet loss for both protocols. In the Figure 7.3, the packet loss was equal for both protocols, while the SCION has resulted in lower RTT during 5 runs. Chapter 8

Discussion

This chapter will discuss the results of the thesis, how blockchain protocols with encrypted communication can be affected, ethical aspect and sustainability.

Making Ethereum utilize IP and SCION, either simultaneously or SCION as backup was a difficult problem in the application level solution. It was hard to make peers wait for each other in order to switch between IP and SCION, while all messages have deadlines. Thus, made the switching hard without introducing delays, which disconnected the peers. However, in the end it was accomplished, and two fully working solutions were proposed. The two proposed solutions are targeting different use cases. There are users that want to modify their source code in order to implement SCION, namely the application level solution. Thus, obtaining the same functionality with embedded SCION, which provides benefits, such as easy to distribute and execute. Although, the solution has limitations, since it needs to be implemented for a specific application and release version. Furthermore, it is difficult to switch between IP and SCION, because if the IP protocol is currently used, the SCION connection has to be kept alive for future use. If the connection is being initiated at the time when the switch is required, it might be too slow and the peers will disconnect. Thus, for the application level solution the optimal way is either utilizing both protocols simultaneously or SCION as backup. In the former approach is not affected by disruptions, because the first valid packet that arrives over IP or SCION will be handled and the com-

58 CHAPTER 8. DISCUSSION 59

munication will continue. While in the latter, the DDT is responsible for enabling a secure and highly available connection without disruptions. The DDT has to be implemented inside of an application or as a separate application. If it is embedded inside of an application, it has to be triggered by some functions or by time intervals, which is more likely to be triggered by functions responsible for sending messages. Thus, it could result in high overhead because the measurements could be executed too frequently, resulting in slowdown of the application. Although, it is easier to alter the content of the messages. The SIG proxy solution is a modular and more generic solution which could be used by any application, independently of the programming language and release version. Furthermore, it enables additional extensions to be created and added. The solution provides a small overhead, since it is running upon an application and controls the network flow of the running application. In order to start the SIG proxy solution, the binary of the desired application, listening port of that application and SCION details have to be provided. The solution cannot detect these parameters automatically, therefore the user has to provide them. Although, it is able to detect ports of incoming and outgoing packets of the running application. Since, the ports of the incoming and outgoing traffic might change, it is difficult to capture all traffic from and to the running application. However, the SIG proxy solution solves this problem by creating a temporary Linux Ubuntu user. The user is used to start the application, and create a specific iptables rule that captures all traffic from and to that user. Hence, all traffic sent or received by the running application will be captured, and can be used to detect new IP addresses. This makes the SIG proxy solution more complex, but also more robust. The solution allows the running application to easily switch between IP and SCION protocols, because it has access to the routing table of the system and can decide which way the packets will be sent. Furthermore, the DDT can be handled as the main task of the solution, and be triggered by newly detected IP addresses, or by specified intervals. Hence, not creating great overhead, but still detect disruptions. The two proposed solutions have both advantages and disadvantages, which the end user has to consider and upon them decide which solution fits its use case the best. 60 CHAPTER 8. DISCUSSION

8.1 Security analysis

The routing attacks in the legacy Internet are feasible due to lack of security guarantees in the BGP UPDATE messages. Hence, a malicious AS could advertise IP prefixes that belongs to another AS, in order to redirect traffic to hosts under the control of the attacker, see Section 2.1.1. Furthermore, in the legacy Internet, ASes are usually owned by ISPs or independently operated networks. Hence, the security of each AS can vary heavily, and is managed by respective owner. The thesis does not cover the security of the hardware nor software by the AS owners, instead the focus is on the BGP protocol which makes Internet still vulnerable. As explained in Section 2.1.2, various BGP security extensions have been proposed, but none of them has been widely deployed. Further- more, various third-party detection tools have been proposed in order to monitor and detect misbehavior in the BGP protocol. However, some argue that an entirely new protocols is required. Thus, it was an incentive to investigate if a completely new Internet architecture, such as SCION, can mitigate the BGP vulnerabilities and provide connections with higher security and availability. The proposed solutions using SCION, have authenticated and integrity protected control plane messages, hence provide resilience against routing attacks. Section 7.2, explains that if an adversary manages to compromise a SCION AS, it still has limited abilities. For example, the adversary is not able to execute path manipulation attacks, specifically path hijacking through interposition. Multiple other attacks are mentioned in Section 7.2, although all of them have either limited impact, or require efficiently breaking the cryptographic primitives used in SCION. The cryptographic primitives used in SCION have been wisely chosen in order to protect against malicious adversaries, such as security model described in Section 4.4. However, the cryptographic primitives are as secure as their implementation, thus it is important that the implementation is not tampered with. Since SCION is an open source project, the source code can be altered before deployment by any user. Hence, SCION describes in its book [47], a tool for verification and analysis of the SCION source code, in order to detect vulnerabilities. This will ensure code correctness in the SCION implementation, and guarantee that deployed ASes CHAPTER 8. DISCUSSION 61

in the SCION network are not tampered with. Furthermore, each new AS will be veriﬁed by the core ASes of the ISD. At the time of writing the thesis, SCION was operating as an overlay on top of the legacy Internet. Hence, the capabilities of an attacker hijacking IP tunnels have been analyzed, and showed that SCION provides better resilience against path hijacking than the legacy Internet [47]. The proposed solutions are not responsible for improving the security of respective running application, hence the provided code does not create new vulnerabilities nor mitigates the attacks at the application level.

8.1.1 Disruption Detection Tool (DDT) The DDT can be adjusted individually by the users, making it infeasible for the adversary to know at which settings the tool is operating and execute speciﬁc attacks against the tool. However, it has limitations such as not being the most accurate tool for detecting routing attacks. Measuring RTT and number of hops (TTL) is not enough to detect routing attacks, because the names of the traversing ASes are not saved. Thus, if the path contains same TTL but through different ASes, the tool will not detect it. Although, in that case the RTT should be slightly increased. Furthermore, remembering the names of traversing ASes and TTL can result in false negative results, because these parameters can be changed by the BGP policy or cache of the ASes. Thus, the tool has to be improved, or a different tool should be utilized, which is speciﬁcally made for such measurements. Various publicly available monitoring services, such as BGPmon [61], RIPE- RIS [42] and Route Views [57], exist and can be utilized for improving the DDT. Furthermore, the ARTEMIS solution described in Chapter 3, is utilizing publicly available monitoring services in order to compare the changes with the information obtained by the measurements. However, the DDT is able to detect any other disruptions which are direct results of a disruption or implication that a different disruption is on-going. Furthermore, the tool enables individual adjustments, in order to not allow the adversary to learn the limitations of the measuring tool. 62 CHAPTER 8. DISCUSSION

8.1.2 SIG discovery protocol The SIG discovery protocol does not provide any security guarantees, except for verifying if the received format is correct. This is an issue, and it needs to be solved, either as written in Section 2.2.1, or through a secure protocol such as TLS 1.3, where the messages are encrypted, authenticated and verified by the SIG service. The current vulnerabilities in the protocol can break the whole SIG proxy solution. If the received SIG information is not valid, meaning that if SIG details have correct format, but IP prefixes are not received by the originator, then SIG config will be forged and the IP packets will be sent to wrong destination. However, if the adversary tries to forge the SIG details, it will fail, because SIG services will establish the connection only if the valid SCION address, control port and encapsulation port are provided. Furthermore, both SIG services must have valid SIG details about each other, otherwise the connection will not be established. This security property mitigates the spoofing attack, where the adversary could spoof the SIG details of a victim and advertise it as its own. When the receiver tries to establish the connection to the victim, it will fail. The victim has not obtained SIG details about the remote host, and therefore the mapping from SCION to IP is not stored in the SIG config file in this case. Hence, the victim will decline new connections by unknown hosts.

8.2 Blockchain protocols with encrypted communication

The routing attacks proposed by Apostolaki, Zohar, and Vanbever [3], were on the Bitcoin network. As mentioned in Section 2.4, Bitcoin connections are in plaintext without any integrity checks. Thus, it is easy to filter out Bitcoin packets from the other traffic, and alter them. How- ever, most blockchain protocols developed after the Bitcoin, such as Ethereum, incorporate encrypted connections, see Section 2.5. Encrypted connections make the routing attacks more difficult, since the content of the packets is encrypted. In order to see the content, the adversary would need to break the cryptographic primitives used by the respective blockchain protocol. Furthermore, finding a pattern of CHAPTER 8. DISCUSSION 63

packets from a specific blockchain protocol is hard, since the content can vary, ports can be changed by the users and NATs, and more. Even if the packets are identified, the adversary does not know the content, and thus cannot perform the same attacks as proposed in the paper by Apostolaki, Zohar, and Vanbever [3]. However, this does not mean that the routing attacks are mitigated with the encryption. The BGP is still vulnerable, and if the blockchain protocol’s network is centralized, routing attack are feasible. Although, the attacks cannot be as accurate as in Bitcoin, because of the encrypted communication. Since it is hard for an adversary to filter out encrypted packets by a blockchain protocol, it is still feasible to disrupt the connection between peers. The adversary might drop, reject or delay all packets which are routed through itself. These attacks can have various consequences depending on the blockchain protocol, such as block propagation delay, disconnection, and more. For example, if the Ethereum packets in the node discovery protocol are not received within the deadline (500 ms), the connection to the neighbors will not be established. This, might isolate the victim and result in a similar attack as the eclipse attack [30][39]. Furthermore, if numerous nodes are affected, the Ethereum network would be affected. This could have devastating consequences, since the Ethereum network would be unavailable, and the miners and users could not connect to the network nor execute their tasks. As in Bitcoin, block propagation and transaction messages in Ethereum are limited with deadlines. Thus, it opens up for delay attacks proposed in the paper by Apostolaki, Zohar, and Vanbever [3]. Although, even if the adversary manages to distinguish packets belonging to blockchain protocols, it is hard to know the specific blockchain protocol. Hence, the adversary cannot know the exact amount of time it has to delay the packets without being detected. Although, with enough time invested in analyzing the end-hosts and various blockchain protocols, the deadlines can be determined and result in same consequences as the delay attack. Furthermore, if the adversary does not mind being detected, she can choose a random amount of time for the delay, and make great damage to the blockchain protocol and other traffic. The delay attack has higher impact than partition attack on a blockchain protocol, due to the reward race between miners. Each miner wants to announce its newly mined block first, in order to receive the reward. 64 CHAPTER 8. DISCUSSION

Thus, this attack affects the miners and mining pools, resulting in revenue loss and mining power being wasted if the PoW consensus mechanism is utilized. Furthermore, it affects regular users by delaying the conﬁrmation of transactions and slowing down the whole blockchain protocol.

8.3 Availability analysis

The proposed solutions have shown that they provide higher availability. Prior to the proposed solutions, the legacy Internet had only one way of communication and a path chosen by the ASes during the transmission. However, with the proposed solutions multiple ways of communication exist and can be chosen for speciﬁc use case. Al- though, utilizing a redundant connection with both IP and SCION is emphasized, because the SCION provides multipaths and higher availability than the legacy Internet. Thus, by utilizing both protocols the best of both worlds is accomplished. The disruption scenarios considered in Section 7.2, are feasible and likely to happen in the legacy Internet. Although, in SCION it is difﬁ- cult to compromise an AS, and it provides various mechanism against availability disruptions. Hence, it is less likely to be affected by such attacks and can always be used as a backup solution with high availability. Furthermore, SCION is not yet as widely deployed as the legacy Internet, hence also at lower risk of being disrupted by malicious adversaries. However, the proposed solutions using SCION as backup, are heavily depending on the DDT, which has to be effective in detecting disruptions and switch to the more stable protocol. Otherwise, it might result in utilizing the disrupted protocol, while the other protocol is not disrupted. Hence, an optimized and reliable DDT is vital for best performance and guaranteed availability. If the worst-case scenario, where both protocols are being disrupted would occur, the blockchain technology would not be the biggest problem, the world would be at risk. Thus, the thesis has proposed two solutions, with multiple ways of communication, that provide redundant connections in order to be resilience against disruptions and provide highly available network communication. CHAPTER 8. DISCUSSION 65

8.4 Efﬁciency analysis

The proposed solutions have shown that they are efficient and can satisfy deadlines required for each message by a blockchain protocol, such as Ethereum. However, there is a problem reaching peers over SCION that are far away. As mentioned in Section 6.2, each Ethereum node was hosted on a VM, that also hosted a SCION AS and was located in Switzerland, Zurich. This resulted in SCION RTT to be approximately twice as slow as it should be. The SCION ASes were connected to the attachment points in the respective country through a tunnel, while they were hosted in Switzerland. Thus, when a peer from Switzerland wants to communicate with a peer in South Korea, the traffic goes from Switzerland to South Korea and back to Switzer- land through the tunnel. The response goes the reverse way back, and hence the RTT is approximately twice as slow. The RTT measurements in Section 7.3.1 were thus divided by a factor of 2, which is not the optimal factor. The problem with dividing by 2, is that it is not guaranteed that the traffic is equally fast in both directions, namely from Switzerland to South Korea, as from South Korea to Switzerland. However, for more accurate results the ASes had to be hosted in respective country. Since the traffic is most likely equally fast in both directions and the measurements were not the main focus of the thesis, it was enough to divide SCION RTT by 2. Furthermore, it was acceptable to have the ASes hosted in Switzerland, because an extensive measurement and comparison was performed at ETH Zürich in a different Master’s thesis project. The location of the measurement servers, namely Germany, USA and South Korea, were chosen to measure traffic to the three continents that utilize blockchain technology mostly. Furthermore, the measurements demonstrate the efficiency to both near and far away peers. The long distances are usually difficult to manage in legacy Internet, because the packets can take two ways to South Korea from Switzerland, either over USA or over Asia. Thus, it can lead to various RTT and number of hops (TTL) results, as shown in Section 7.3.1. This gives SCION an advantage over IP, since the sender can always choose the same path to the destination. From the Table 7.1 and 7.2, we can see that the SCION has in most runs slower RTT comparing to the IP. The reason for that could be that 66 CHAPTER 8. DISCUSSION

during the week of measuring, the SCION experienced high load by other researchers or companies that are using SCION and SCIONLab. Furthermore, it could be due to not having native implementation as the IP has in both the programming languages as well as in the routers. For example, the routers on the path to the destination are not explicitly built for SCION, thus the maximal potential is not obtained. However, the average jitter was lower for SCION in 2 out of 3 cases, namely to USA and South Korea. This is an indication that the SCION is a stable network architecture, without high ﬂuctuation, like IP. It could also mean that during the measurements SCION was experiencing less load, but that is why the measurements were performed at various days and times in order to have more accurate values. The average number of hops (TTL) are lower with SCION due to less ASes in the SCION network, and due to the property of selecting the path by the sender. Although, the same path could have been selected for each measurement. However, the SCION measurements were aligned towards RTT, and thus the TTL varied. For the IP, the path was selected by the routers during the transmission, and could vary depending on from which location in Switzerland the measurements were performed, i.e. which ISP was used and which paths were cached. The packet loss in IP was higher than in SCION during one run, which could be due to the disruption on the IP packet’s path. How- ever, it did not affect SCION because it utilizes multipaths. Hence, using SCION or a combination of IP and SCION, results in higher availability and reliability, where the packets will arrive to their destination even in such case. From the above-mentioned results, we cannot argue that someone should switch to SCION completely. However, there are cases when SCION is preferred over IP, and in those cases, utilizing SCION as a backup solution is beneﬁcial. Furthermore, the results could be improved by being measured from more various places, not only from ETH and home, which are both located in Switzerland, Zurich. Also, the bandwidth could have been measured, but that would require end- hosts in the respective country, which this thesis did not obtain. The DDT is a complex tool that can be adjusted and optimized in various ways. However, in the thesis it is focusing on the RTT, number of hops (TTL) and packet loss. The RTT is measured in order to notice if there is a delay attack or slowdown in the legacy Internet. CHAPTER 8. DISCUSSION 67

Furthermore, the TTL is measured to detect if routing attacks are being executed. If the routing attacks are being executed, the TTL must be changed either by the number of hops or by the name of the ASes. However, this is hard to detect, due to ISP’s cache could have expired or the ISP’s policy was changed, thus the packets are being routed through a new path which is legitimate. Lastly, the packet loss is measured in order to detect disruptions in the connection, such as an adversary is dropping or rejecting packets. All of these measurements can help in detecting disruptions in the legacy Internet and indicate that SCION should be used. Although, the frequency of the measurements and the details obtained, play a vital role. If the measurements are not executed at the right moment, the disruptions might be undetected. Furthermore, it is important that the detection is efficient and does not slow down the running application, e.g. Ethereum. Thus, the tool can be adjusted in order to specify how many RTT, number of hops (TTL) and packet loss measurements it will perform to each peer. With this opportunity it is possible to increase or decrease the efficiency of the DDT, which is a trade-off between ac- curacy and efficiency that the user decides. The efficiency of the SIG discovery protocol is negligible, since it is executed simultaneously with the SIG proxy solution and does not provide any slowdown nor great network overhead. However, the efficiency of the protocol is important in order to utilize SCION as fast as possible, upon a successfully established connection to the peer. Al- though, the protocol does not require heavy computation, thus the execution of it is finished during the initial DDT measurements. By using simultaneously IP and SCION or SCION as backup, it would mitigate most of the disruptions. However, a redundant connection is always preferred. Although, the simultaneous way of communication provides high overhead and requires more resources, such as computing power and network overhead. Thus, it is not a preferred approach when viewing from the environmental perspective. There- fore, the optimal approach is to use SCION as the backup solution, but have an optimized, efficient, reliable and accurate DDT which will always be a step ahead of the disruptions. 68 CHAPTER 8. DISCUSSION

8.5 SCION deployment

As we could see in Section 2.1.2, numerous BGP security extensions have been proposed but not widely deployed. Various reasons exist, such as not enough incentive, complex implementation or provides high overhead. Furthermore, we have seen that the adoption of IPv6 is slow, and that is not as big step as replacing the current Internet with SCION. Therefore, it comes naturally to wonder how is SCION tackling these problems and will it replace the current Internet. In Section 2.2, SCION is described together with the properties that it provides. The fundamental idea of SCION is to replace the current Internet, by offering multiple better features, such as security, control, availability, and more. The various defenses in Section 2.1.2, does provide security to BGP and mitigate routing attacks. However, there exist numerous other vulnerabilities, such as DDoS attacks. Further- more, the users of the current Internet do not have the control of the packets they send, nor transparency. Therefore, SCION is trying to mitigate all vulnerabilities in the current Internet, by providing a new inter-domain architecture that will also offer multiple beneficial mechanisms for the users. Thus, I think SCION has great advantage comparing to the solutions mitigating specific vulnerabilities, because it solves numerous problems and not a single one. The various vulnerabilities that exist in BGP, specifically routing attacks, have been around for a long time without a proper solution or a replacement of BGP. This indicates that either it is hard to replace the widespread protocol, or some organizations does not want nor allow to perform that. In order avoid this problem, SCION is being used as a backup solution at various companies. The backup solution is used in case the legacy Internet becomes disrupted or unavailable, or the information is confidential and requires higher security. Thus, SCION will get widespread as a backup solution, and when the users become aware of the benefits that SCION provides, they will slowly replace the legacy Internet. Furthermore, this approach does not force users to try SCION, nor it gets in conflict with organizations that does not want to replace BGP for various reasons. CHAPTER 8. DISCUSSION 69

8.6 Ethical aspects and sustainability

The proposed solutions have the main goal to provide users with secure and highly available blockchain network communication. As stated in Section 1.1, the mitigation of routing attacks in the blockchain technology is of the highest priority for the proposed solutions. By using SCION, authentication and integrity is added to the routing protocol, resulting in mitigation of routing attacks. Users do not need to fear that the blockchain network will be partitioned, or their announcement of blocks and transactions will be delayed. However, there are still ways for adversaries to disrupt the blockchain technology, such as eclipse attacks or by exploiting vulnerabilities at the application level. Nevertheless, the proposed solutions increase the difficulty and complexity of carrying out such attacks, by mitigating network attacks that were considered infeasible until the paper by Apostolaki, Zohar, and Vanbever [3] was published. Blockchain technology is being extensively researched and applied to wide range of fields. The speculations for what it can be used for is broad. Some say that blockchain might be the most important invention for the digital era since the Internet. Which the cryptocurrencies have proved, by their usage and the enormous amount of money at stake. Thus, the blockchain technology has shown that it has a great potential, and will sustain in the future. Furthermore, the proposed solutions have proved that it is feasible to mitigate BGP vulnerabilities with SCION, and contributed to the blockchain technology by guaran- teeing a secure and highly available network communication. The proposed solutions are compatible with the existing blockchain nodes in the main network, require minimal hardware and can be scaled up to various blockchain protocols and applications. How- ever, for the optimal experience with security and high availability, the peers must use the same way of communication in the chosen solution. The high-power consumption by the blockchain technologies, is a big issue due to the consensus mechanisms, specifically PoW. Al- though, the consensus mechanism field is being heavily researched, resulting in multiple more sustainable consensus mechanisms, such as PoS, see Section 2.3 and 2.5. Since, the proposed solutions in the thesis does not change the consensus mechanisms or way how the blockchain technology works, it 70 CHAPTER 8. DISCUSSION

will not be decreased. However, the routing attacks and other network- based attacks that are contributing to even higher power consumption, will be mitigated. Hence, the new blocks that have wasted high amount of power during mining, will not be delayed or dropped any- more, and the miners will not experience revenue loss. Furthermore, by utilizing SCION, the power consumption of the current Internet could be decreased by 15-50% [47]. Thus, the proposed solutions will not prevent the high-power consumption of the blockchain technologies, but the power consumption by the current Internet will be decreased. Furthermore, the blockchain technology will remain secure, and the miners will have an incentive to mine new blocks and keep the blockchain technology existing. Chapter 9

Conclusion

The thesis has shown that SCION is stable and efficient enough to deploy a blockchain technology, while providing secure and highly available blockchain network communication. The proposed solutions, provide advantages and disadvantages. Modifying a blockchain protocol at the application level, is better for the performance. However, at the time of writing the thesis, SCION library was limited to Go programming language. Furthermore, modifying at the application level in order to run over either IP or SCION is feasible, but using SCION as backup is more complex. Thus, there are three ways of communication, either IP or SCION, both protocols simultaneously or SCION as backup. The first and the last way of communication do not provide network overhead, while the simultaneous approach sends all packets twice. Although, the second and the third approach are redundant, and therefore robust against disruptions in IP and SCION. In order to utilize SCION as backup to IP, a DDT which will efficiently detect disruptions and switch to a more stable protocol is required. This has to be established and maintained before the disruption happens. Thus, by using a solution that utilizes SCION, reliability and availability is guaranteed. The generic, SIG proxy solution, is the optimal approach, because the application’s source code is not modified, and it supports wide range of applications. It is independent of the programming language and release version. However, this solution relies on the DDT as well. If the detection tool is accurate and efficient, the solution provides reliability and availability. A benefit of this approach comparing to the simultaneous way of communication in the application level solution,

71 72 CHAPTER 9. CONCLUSION

is lower network overhead due to packets being sent over either IP or SCION. Although, it can be conﬁgured to send over both protocols at the same time. The proposed solutions have shown that it is feasible to mitigate routing attacks by utilizing SCION. Furthermore, high availability is guaranteed with the proposed solutions, because of utilizing SCION. By using IP and SCION simultaneously or SCION as backup, a redundant connection is created which guarantees that packets will arrive to the remote peer, through one of the available protocols. Since the routing attacks can be mitigated with SCION, the network partitioning, delaying and double spending attacks have been mitigated. This provides the users with secure and highly available network communication. Furthermore, SCION is in some situations faster than the IP, which is a great incentive for miners to potentially increase their revenue. Concurrently, by utilizing only SCION in the application level solution or SIG proxy solution, the power consumption could be decreased. However, the most important thing is that no revenue loss is guaranteed, and no power consumption is getting wasted by the routing attacks. Hence, the second research question is accomplished. Chapter 10

Future Work

Using SCION instead of the legacy Internet for the blockchain technology is feasible and beneﬁcial. However, the application level solution was implementation and tested on Ethereum only, which could be done on other blockchain protocols that are written in Go, such as Hyperledger [1]. Furthermore, a formal security analysis is needed of the proposed solutions, speciﬁcally of the SIG discovery protocol which has no security guarantees. Due to time limitation and complexity, the thesis did not attempt to perform any routing attacks on the proposed solutions. Thus, it would be of interest to test if routing attacks are feasible on the proposed solutions and how they are handled by the solutions. Further- more, it would be of interest to investigate what consequences they would have on other blockchain protocols, such as Ethereum. A comparison of already existing security extensions for BGP were not cover by the thesis. Thus, it is a great incentive to do a comparative study between already proposed BGP security extensions and SCION, in order to investigate advantages and disadvantages with respective solution. Additionally, a benchmark of the various proposals should be investigated and presented. It would be also interesting to investigate if SCION can mitigate the eclipse attacks in Bitcoin [30] and Ethereum [39]. The attacks are straightforward to perform, and the mitigation is temporary by increasing the amount of required IP addresses in order to exploit the vulnerability. In order to make an optimal use of SCION as backup, an optimized

73 74 CHAPTER 10. FUTURE WORK

and accurate DDT is required. Thus, it is important to investigate how to create a reliable tool, which is efficient and detects every misbehavior in the connection. This is vital for both the application level solution and the SIG proxy solution. In both cases it is necessary to have an efficient way of deciding which protocol to use. Lastly, the NAT traversal problem was not covered by the thesis, however it is a big problem for the P2P networks. Thus, it is of interest to research how to mitigate that problem. Furthermore, NAT traversal through multiple NATs with SCION, is a difficult problem that requires extensive research. Bibliography

[1] Elli Androulaki et al. “Hyperledger Fabric: A Distributed Op- erating System for Permissioned Blockchains”. In: Proceedings of the Thirteenth EuroSys Conference. EuroSys ’18. Porto, Portugal: ACM, 2018, 30:1–30:15. ISBN: 978-1-4503-5584-1. DOI: 10.1145/ 3190508.3190538. URL: http://doi.acm.org/10.1145/ 3190508.3190538. [2] Maria Apostolaki and Laurent Vanbever. Protecting Blockchain Applications with Programmable Networks. 2017. URL: https:// nsg.ee.ethz.ch/fileadmin/user_upload/btc_p4. pdf. [Online; accessed 27.03.2018]. [3] Maria Apostolaki, Aviv Zohar, and Laurent Vanbever. “Hijack- ing bitcoin: Routing attacks on cryptocurrencies”. In: Security and Privacy (SP), 2017 IEEE Symposium on. IEEE. 2017, pp. 375– 392. [4] Hitesh Ballani, Paul Francis, and Xinyang Zhang. “A study of preﬁx hijacking and interception in the Internet”. In: ACM SIG- COMM Computer Communication Review. Vol. 37. 4. ACM. 2007, pp. 265–276. [5] Dave Bayer, Stuart Haber, and W Scott Stornetta. “Improving the efﬁciency and reliability of digital time-stamping”. In: Se- quences II. Springer, 1993, pp. 329–334. [6] BLOCKCHAIN. Bitcoin market cap. 2018. URL: https://blockchain. info/charts/market-cap. [Online; accessed 26.06.2018]. [7] IBM Blockchain. IBM Blockchain based on Hyperledger Fabric from the Linux Foundation. URL: https://www.ibm.com/blockchain/ hyperledger.html. [Online; accessed 01.03.2018].

75 76 BIBLIOGRAPHY

[8] Olivier Bonaventure, Christoph Paasch, and Gregory Detal. Use Cases and Operational Experience with Multipath TCP. 2017. URL: https://tools.ietf.org/html/rfc8041. [Online; accessed 27.03.2018]. [9] Joseph Bonneau. The Bitcoin Network. Princetion University, 2014. URL: https://www.coursera.org/learn/cryptocurrency/ lecture/SKxAO/%20the-bitcoin-network. [Online Pre- sentation; accessed 10.07.2018]. [10] Joseph Bonneau. The Task of Bitcoin Miners. URL: https : / / www.coursera.org/learn/cryptocurrency/lecture/ 0htpQ/the-task-of-bitcoin-miners. [Online; accessed 02.11.2018]. [11] Joseph Bonneau et al. “Sok: Research perspectives and challenges for bitcoin and cryptocurrencies”. In: Security and Privacy (SP), 2015 IEEE Symposium on. IEEE. 2015, pp. 104–121. [12] Kevin Butler et al. “A survey of BGP security issues and solutions”. In: Proceedings of the IEEE 98.1 (2010), pp. 100–122. [13] Matthew Caesar and Jennifer Rexford. “BGP routing policies in ISP networks”. In: IEEE network 19.6 (2005), pp. 5–11. [14] John Cox. Apple iOS 7 surprises as ﬁrst with new multipath TCP connections. Ed. by Networkworld. Sept. 2013. URL: https:// www.networkworld.com/article/2170068/lan-wan/ apple-ios-7-surprises-as-first-with-new-multipath- tcp-connections.html. [Online; accessed 27.03.2018]. [15] Oracle Dyn. Blog. URL: https://dyn.com/blog/. [Online; accessed 26.08.2018]. [16] Oracle Dyn. Pakistan hijacks YouTube. URL: https://dyn.com/ blog/pakistan-hijacks-youtube-1/. [Online; accessed 1.11.2018]. [17] Ethereum. Clients, tools, dapp browsers, wallets and other projects. July 2018. URL: https://github.com/ethereum/wiki/ wiki / Clients, - tools, - dapp - browsers, - wallets - and-other-projects. [Online; accessed 17.07.2018]. [18] Ethereum. ÐΞVp2p Wire Protocol. URL: https://github.com/ ethereum/wiki/wiki/%C3%90%CE%9EVp2p-Wire-Protocol. [Online; accessed 15.07.2018]. BIBLIOGRAPHY 77

[19] Ethereum. Geth. Dec. 2017. URL: https://github.com/ethereum/ go-ethereum/wiki/geth. [Online; accessed 17.07.2018]. [20] Ethereum. Node Discovery Protocol v4. URL: https://github. com/ethereum/devp2p/blob/master/discv4.md. [On- line; accessed 20.07.2018]. [21] Ethereum. RLPx Encryption. URL: https : / / github . com / ethereumproject/go-ethereum/wiki/RLPx-Encryption. [Online; accessed 20.07.2018]. [22] Ethereum. White Paper. URL: https://github.com/ethereum/ wiki/wiki/White-Paper. [Online; accessed 10.07.2018]. [23] Simone Ferlin. BGP Internet Routing: What Are the Threats? URL: https://securityintelligence.com/bgp-internet- routing-what-are-the-threats/. [Online; accessed 1.11.2018]. [24] Thomas Fox-Brewster. A $152,000 Cryptocurrency Theft Just Ex- ploited A Huge ’Blind Spot’ In Internet Security. Apr. 2018. URL: https : / / www . forbes . com / sites / thomasbrewster / 2018/04/24/a-160000-ether-theft-just-exploited- a-massive-blind-spot-in-internet-security/. [On- line; accessed 26.06.2018]. [25] Sharon Goldberg. “Why is it taking so long to secure internet routing?” In: Queue 12.8 (2014), p. 20.

[26] Manav Gupta. Blockchain For Dummies R , IBM Limited Edition. John Wiley & Sons, Inc, 2017. ISBN: 978-1-119-37123-6. [27] William Haag et al. [Project Description] Secure Inter-Domain Routing– Part 1: Route Hijacks. 2017. URL: https://www.nccoe.nist. gov/sites/default/files/library/project-descriptions/ sidr - project - description - draft . pdf. [Online; accessed 26.03.2018]. [28] Stuart Haber and W Scott Stornetta. “How to time-stamp a digital document”. In: Conference on the Theory and Application of Cryptography. Springer. 1990, pp. 437–455. [29] Mark Handley et al. TCP extensions for multipath operation with multiple addresses. 2013. URL: https : / / tools . ietf . org / html/rfc6824. [Online; accessed 27.03.2018]. 78 BIBLIOGRAPHY

[30] Ethan Heilman, Alison Kendler, and Aviv Zohar. “Eclipse At- tacks on Bitcoin’s Peer-to-Peer Network”. In: Proceedings of the 24th USENIX Security Symposium, Washington, D.C. 2015. ISBN: 978-1-931971-232. [31] Yih-Chun Hu, Adrian Perrig, and Marvin Sirbu. “SPV: Secure path vector routing for securing BGP”. In: ACM SIGCOMM Com- puter Communication Review 34.4 (2004), pp. 179–192. [32] Apple Inc. Improving Network Reliability Using Multipath TCP. 2017. URL: https://developer.apple.com/documentation/ foundation/urlsessionconfiguration/improving%5C_ network%5C_reliability%5C_using%5C_multipath% 5C_tcp. [Online; accessed 27.03.2018]. [33] Apple Inc. Use Multipath TCP to create backup connections for iOS. 2017. URL: https://support.apple.com/en-us/HT201373. [Online; accessed 27.03.2018]. [34] BGPmon Network Solutions Inc. BGPmon - Blog. URL: https: //bgpmon.net/blog/. [Online; accessed 26.06.2018]. [35] Paula Jabloner. The Two-Napkin Protocol. Mar. 2015. URL: http: //www.computerhistory.org/atchm/the-two-napkin- protocol/. [Online; accessed 27.06.2018]. [36] Adam Langley et al. “The QUIC Transport Protocol: Design and Internet-Scale Deployment”. In: Proceedings of the Conference of the ACM Special Interest Group on Data Communication. SIGCOMM ’17. Los Angeles, CA, USA: ACM, 2017, pp. 183–196. ISBN: 978- 1-4503-4653-5. DOI: 10.1145/3098822.3098842. URL: http: //doi.acm.org/10.1145/3098822.3098842. [37] The Go Programming Language. Package net. URL: https:// golang.org/pkg/net/. [Online; accessed 25.07.2018]. [38] Alex Leverington. RLPx: Cryptographic Network & Transport Pro- tocol. URL: https : / / github . com / ethereum / devp2p / blob/master/rlpx.md. [Online; accessed 15.07.2018]. [39] Yuval Marcus, Ethan Heilman, and Sharon Goldberg. “Low-Resource Eclipse Attacks on Ethereum’s Peer-to-Peer Network”. In: (2018). BIBLIOGRAPHY 79

[40] Petar Maymounkov and David Mazieres. “Kademlia: A peer-to- peer information system based on the xor metric”. In: Interna- tional Workshop on Peer-to-Peer Systems. Springer. 2002, pp. 53– 65. [41] Satoshi Nakamoto. “Bitcoin: A peer-to-peer electronic cash system”. In: (2008). [42] RIPE NCC. Routing Information Service (RIS). URL: https : / / www.ripe.net/analyse/internet-measurements/routing- information-service-ris. [Online; accessed 27.08.2018]. [43] Ola Nordström and Constantinos Dovrolis. “Beware of BGP attacks”. In: ACM SIGCOMM Computer Communication Review 34.2 (2004), pp. 1–8. [44] M Tamer Özsu and Patrick Valduriez. Principles of distributed database systems. Springer Science & Business Media, 2011. [45] Panagiotis Papadimitratos and Zygmunt J Haas. “Secure data communication in mobile ad hoc networks”. In: IEEE Journal on Selected Areas in Communications 24.2 (2006), pp. 343–356. [46] Panagiotis Papadimitratos and Zygmunt J Haas. “Securing the Internet routing infrastructure”. In: IEEE Communications Maga- zine 40.10 (2002), pp. 60–68. [47] Adrian Perrig et al. SCION: A Secure Internet Architecture. Springer, 2017. ISBN: 978-3-319-67079-9. [48] Barath Raghavan, Saurabh Panjwani, and Anton Mityagin. “Anal- ysis of the SPV secure routing protocol: Weaknesses and lessons”. In: ACM SIGCOMM Computer Communication Review 37.2 (2007), pp. 29–38. [49] Yakov Rekhter and Tony Li. A Border Gateway Protocol 4 (BGP-4). July 1994. URL: https://tools.ietf.org/html/rfc1654. [Online; accessed 27.06.2018]. [50] Alfonso de la Rocha and Panos Papadimitratos. “Blockchain- based Public Key Infrastructure for Inter-Domain Secure Rout- ing”. In: IFIP WG 11.4 Workshop on Open Problems in Network Se- curity (IFIP iNetSec). Rome, Italy, May 2017. [51] Pavlos Sermpezis et al. “ARTEMIS: Neutralizing BGP Hijacking within a Minute”. In: arXiv preprint arXiv:1801.01085 (2018). 80 BIBLIOGRAPHY

[52] Kotikalapudi Sriram and Matthew Lepinski. “BGPsec Protocol Speciﬁcation”. In: (2017). [53] Yixin Sun et al. “RAPTOR: Routing Attacks on Privacy in Tor”. In: ArXiv e-prints (Mar. 2015). arXiv: 1503.03940 [cs.NI]. [54] Henry Tan, Micah Sherr, and Wenchao Zhou. “Data-plane defenses against routing attacks on Tor”. In: Proceedings on Privacy Enhancing Technologies 2016.4 (2016), pp. 276–293. [55] Tesssares. APPLE OPENS MULTIPATH TCP IN IOS11. 2017. URL: http://www.tessares.net/highlights-from-advances- in-networking-part-1/. [Online; accessed 27.03.2018]. [56] Andree Toonk. BGPmon - The Canadian Bitcoin Hijack. Aug. 2014. URL: https://bgpmon.net/the- canadian- bitcoin- hijack. [Online; accessed 26.06.2018]. [57] Route Views. University of Oregon Route Views Project. URL: http: //www.routeviews.org/routeviews/. [Online; accessed 27.08.2018]. [58] Gavin Wood. “Ethereum: A secure decentralised generalised transaction ledger”. In: Ethereum project yellow paper (2014). [59] Karl Wüst and Arthur Gervais. “Do you need a Blockchain?” In: (2017). [60] Karl Wüst and Arthur Gervais. Ethereum Eclipse Attacks. Tech. rep. ETH Zurich, 2016. URL: https://doi.org/10.3929/ ethz-a-010724205. [Online; accessed 09.04.2018]. [61] He Yan et al. “BGPmon: A real-time, scalable, extensible monitoring system”. In: Conference For Homeland Security, 2009. CATCH’09. Cybersecurity Applications & Technology. IEEE. 2009, pp. 212–223. [62] Zheng Zhang et al. “Practical defenses against BGP preﬁx hijacking”. In: Proceedings of the 2007 ACM CoNEXT conference. ACM. 2007, p. 3. Appendix A

Typical scenario

In this appendix, a typical scenario of application level solution and SIG proxy solution are demonstrated by Figure A.1 and A.2. In both figures a typical packet flow with respective protocol and default port numbers between two Ethereum clients and a bootnode is presented. Furthermore, new commands introduced for running Ethereum client and bootnode with SCION are explained. In these scenarios three VMs were used to simulate two users and a bootnode hosted somewhere in the wild. The setup was chosen to illustrate a realistic scenario, where two distinct clients find each other through a bootnode and establish a connection. Furthermore, the port numbers can be adjusted individually by the user, and both proposed solutions are compatible with the nodes not supporting SCION. Thus, enabling an easy deployment in the main network.

A.1 Application level solution

In the application level solution, each client is started through a ter- minal with the following command: geth -datadir="" -bootnodesSCION=enode//... -port <30303 is default> -networkid 8014 console -scion The bootnode is generated with the command bootnode -genkey=boot.key, and then started with the command bootnode -nodekey=boot.key -scion ISD-AS,[IP]:port. 1. Ethereum clients can either connect to the bootnode or to a peer in order to obtain network information. In this scenario both

81 82 APPENDIX A. TYPICAL SCENARIO

clients connect to the bootnode, with the command: -bootnodesSCION=enode://41edca7f3ea8878ece845bd4742dfe8f85bd5 fba45c30c92154668d0793c22f036567e3e323538c0b17463e1cc513eb4 2d9b280501a0b624c1d6ee49ef346e42@[192.168.0.31]:30301 @SCION@17-ffaa:1:1f,[192.168.0.31]:30301. The bootnodesSCION ﬂag is implemented to enable specifying bootnodes running SCION, and contains the bootnode’s ID encoded in the username por- tion of the URL, IP, port, and SCION address and port after the @SCION@ delimiter.

2. When the clients have exchanged their information and obtained the information about their neighbors, the node discovery part is done. Next, the clients have to establish encrypted connections with the neighbors received from the bootnode.

IP: 192.168.0.31 VM2 SCION: 17-ffaa:1:1f

Ethereum Bootnode

SCION Port: 30301

UDP

1 IP Port: 30301 1

IP: 192.168.0.21 UDP IP: 192.168.0.30 VM1 VM3 SCION: 17-ffaa:1:1d SCION: 17-ffaa:1:3e

Ethereum Client Ethereum Client

SCION SCION

Port: 30303 UDP UDP Port: 30303 2 Port: 30304 QUIC QUIC Port: 30304

IP 1 1 IP

Port: 30303 UDP UDP Port: 30303 2 Port: 30303 TCP TCP Port: 30303

Figure A.1: A typical application level solution scenario with two Ethereum clients (geths) and a bootnode is shown. The various ways of communication is shown, as well as default ports, IP and SCION addresses used for in scenario.

If everything went well, such as the clients have the same genesis block, the connection between the two clients is established and en- APPENDIX A. TYPICAL SCENARIO 83

crypted. Each successfully established connection with peers, will be used for all future communications. By typing admin.peers in the Ethereum’s console, a list of currently successfully connected peers will be shown, see Listing A.1. 1 > admin.peers 2 [{ 3 caps: ["eth/63"], 4 id: "e88928ab203169d7fbb8ea0c3d7ab5093205...", 5 name:"Geth/v1.8.4-unstable-d1d69509/linux-amd64/go1.9.4", 6 network: { 7 inbound: true, 8 localAddress: "192.168.0.30:30303", 9 localSCION: "17-ffaa:1:3e,[192.168.0.30]:30304", 10 remoteAddress: "192.168.0.21:33806", 11 remoteSCION: "17-ffaa:1:1d,[192.168.0.21]:1026", 12 static: false, 13 trusted: false 14 }, 15 protocols: { 16 eth: { 17 difficulty: 131072, 18 head: "0xf9d84fe0a9b529f5fdab3efd98fc31e4093e...", 19 version: 63 20 } 21 } 22 }] Listing A.1: The command admin.peers shows the list of currently successfully connected peers for the VM3 client. The list contains details about the peers, such as Ethereum version, network details and which protocols are used. In this particular scenario eth protocol is used, and the client is connected to only one peer over both IP and SCION. The remoteAddress port and remoteSCION port indicate that the remote peer initiated the connection. Furthermore, the localSCION port is incremented by 1 from the default 30303, because the SCION dispatcher does not support UDP and QUIC over the same port.

The clients can now communicate with each other without the bootnode, and they have established a connection over both IP and SCION. Now, depending on how they are conﬁgured and if there are disruptions in the connection, the best suitable protocol will be used. 84 APPENDIX A. TYPICAL SCENARIO

Furthermore, there is a command called admin.addPeer(""), which enables a client to directly try to establish an encrypted connection with another client if the enode of that client is known.

A.2 SIG proxy solution

The SIG proxy solution has to be provided with the binary of the desired application, listening port and SCION details in order to initiate it during execution. These details need to be provided to the source code, because they cannot be detected automatically by the SIG proxy solution. However, when details are provided, the source code has to be either compiled and then executed, or executed directly with the command go run ./SIGproxy.go. The command to start geth is slightly different in SIG proxy solution, because the running application is not aware of SCION. The command used in this scenario is geth -datadir="" -bootnodes=enode//... -port <30303 is default> -networkID 8014 console. Al- though, a different command needs to be speciﬁed for any other application or individual desire, such as different port numbers. The bootnode is generated and started with the same commands as in the application level solution, namely bootnode -genkey=boot.key and bootnode -nodekey=boot.key. APPENDIX A. TYPICAL SCENARIO 85

IP: 192.168.0.31 VM2 - User X SCION: 17-ffaa:1:1f User Y

Ethereum Bootnode

SIG Proxy Port: 10001 SCION IP Enc Port: 10080 SIG Ctrl Port: 10081

IP: 192.168.0.21 IP: 192.168.0.30 VM1 - User X VM3 - User X SCION: 17-ffaa:1:1d SCION: 17-ffaa:1:3e User Y User Y

Ethereum Client Ethereum Client

IP IP

SIG Proxy SIG Proxy Port: 10001 Port: 10001 SCION SCION IP Enc Port: 10080 IP Enc Port: 10080 SIG SIG Ctrl Port: 10081 Ctrl Port: 10081

Figure A.2: A typical SIG proxy solution scenario with two Ethereum clients (geths) and a bootnode is shown. The various ways of communication is shown, as well as default ports, IP and SCION addresses used in this scenario.

1. Ethereum clients can either connect to the bootnode or to a peer in order to obtain network information. In this scenario both clients connect to the bootnode, with the command: –bootnodes=enode://41edca7f3ea8878ece845bd4742dfe8f85bd5 fba45c30c92154668d0793c22f036567e3e323538c0b17463e1cc513eb4 2d9b280501a0b624c1d6ee49ef346e42@[192.168.0.31]:30301. This command contains the bootnode’s ID encoded in the username por- tion of the URL and IP and port.

2. When the clients have exchanged their information and obtained the information about their neighbors, the node discovery part is 86 APPENDIX A. TYPICAL SCENARIO

done. Next, the clients have to establish encrypted connections with all neighbors received from the bootnode. Each successfully established connection, will be used for all future communications with the respective peer.

Upon a successful connection between the two clients, it is possible to show the connected peers through the Ethereum console like in the application level solution. However, in this case the output will be slightly different comparing to Listing A.1. The localSCION and re- moteSCION ﬁelds are missing, since this solution does not modify the source code of Ethereum. The clients can now communicate with each other without the bootnode, and they have established a connection over the IP. Simultane- ously, the SIG discovery protocol has been running on port 10001, and gathered all necessary information in order to know if the peers support SIG. The default encapsulation and control ports are 10080 and 10081, as shown in Figure A.2. Now, depending on how the SIG proxy solutions are conﬁgured, and if there are disruptions in the connection, the best suitable protocol will be used. The switching between IP and SCION is transparent and handled by the SIG proxy application, which includes DDT. Thus, Ethereum clients and bootnode, think the connection is over IP only, although it could be over SCION. Furthermore, there is the command admin.addPeer("") like in the application level solution, which enables a client to directly try to establish an encrypted connection with another client if the enode of that client is known. TRITA TRITA-EECS-EX-2018:592