Towards Deployment of a Next- Generation Secure Internet Architecture

Transcription

1 Towards Deployment of a Next- Generation Secure Internet Architecture Adrian Perrig Network Security Group, ETH Zürich 1

2 monumental structure stood the test of time & seems immutable 2

3 Just like today s Internet? Can we fix its issues, though? Control Transparency Availability Trust 3

4 Problem 1: Non-Scalability of Trust Control Transparency Availability Trust 4

5 Pervasive Trust in Early Internet There were only two other Dannys on the Internet then. I knew them both. We didn't all know each other, but we all kind of trusted each other, and that basic feeling of trust permeated the whole network. Danny Hillis, about the Internet in the early 1980s, TED talk, Feb

6 Non-Scalability of Trust As the Internet has grown to encompass a large part of the global population, not everyone trusts everyone else on the Internet anymore The heterogeneity of global environment complicates entity authentication infrastructures Relevant in this context: authentication of routing updates, DNS replies, TLS certificates Two models for trust roots for authentication Monopoly model Oligarchy model 6

7 Monopoly Model for Trust Root Single root of trust (i.e., root public key) that is globally accepted to authenticate entities Examples: RPKI for BGPSEC or DNSSEC rely on a public key that forms root of trust All AS certificates or DNS records are authenticated based on that root of trust Problems Entire world needs to agree on one entity to hold root of trust Single point of failure Inefficient revocation / update 7

8 Oligarchy Model for Trust Root Numerous roots of trust that are globally accepted to validate entities Example: TLS PKI relies on > 1000 roots of trust TLS certificate accepted if signed by any root of trust Problems Single point of failure: any single compromised root of trust can create any bogus TLS certificate Revocation/updates are handled through OS or browser update 8

9 Proposed Approach: Isolation Domains Observation: subset of the Internet can agree on roots of trust! form Isolation Domain with that root of trust Authenticate entities (only) within each Isolation Domain Users & domains can select Isolation Domain based on root of trust Also supports modern log-based PKI approaches: CT, AKI, ARPKI, Challenge: retain global verifiability 9

10 Problem 2: Control Control Transparency Availability 10

11 Who controls Internet Paths? Current Internet offers limited control of paths Border Gateway Protocol (BGP) floods announcements for destinations 11

12 Who controls Internet Paths? Current Internet offers limited control of paths Border Gateway Protocol (BGP) floods announcements for destinations No inbound traffic control 12

13 Who controls Internet Paths? Current Internet offers limited control of paths Paths can be hijacked and redirected 13

14 Who should control Paths? Clearly, ISPs need some amount of path control to enact their policies. How much path control should end points (sender and receiver) have? Control is a tricky issue how to empower end points without providing too much control? No Endpoint Control Limited Endpoint Control Complete Endpoint Control

15 Problem 3: Transparency Transparency Availability 15

16 Transparency: Internet Paths Today, sender cannot obtain guarantee that packet will travel along intended path Impossible to gain assurance of packet path Because router forwarding state can be inconsistent with routing messages sent 16

17 Proposed Approach: Packet-Carried State Packets carrying forwarding information provides path transparency Note: orthogonal issue to path control, as network can still define permitted paths

18 Problem 4: Availability Availability 18

19 Poor Availability Well-connected entity: 99.9% availability (86 s/day unavailability) [Katz-Bassett et al., Sigcomm 2012] Numerous short-lived outages due to BGP route changes Route convergence delays Outages due to misconfigurations Outages due to attacks E.g., prefix hijacking, DDoS 19

20 Is a 10s Outage per Day Harmful? 99.99% reliability! average 8.6 s/day outage Level of availability achieved by Amazon datacenter Insufficient for many applications Critical infrastructure command and control E.g., air traffic control, smart grid control Internet-based business Financial trading / transactions Telemedicine 20

21 Proposed Approach: Replace BGP BGPSEC suffers several fundamental problems Trust: Uses single root of trust (RPKI / BGPSEC) Control: Almost no path choice by end points Transparency: no path guarantees Availability Frequent periods of unavailability when paths change Slow convergence during iterative route computation Susceptible to attacks and misconfigurations 21

22 Evolutionary vs. Revolutionary Change Revolutionary approach is necessary Some problems are fundamental, not fixable through evolution Revolutionary approach is desirable A fresh redesign can cleanly incorporate new mechanisms Revolutionary technology change is easy through evolutionary deployment If IP is relegated to provide local (intra-domain) communication, only a small fraction of border routers need to change Simultaneous operation with current Internet possible Strong properties provide motivation for deployment 22

23 SCION Project Scalability, Control, and Isolation On Next-Generation Networks [IEEE S&P 2011, CCS 2015, NDSS 2016] Current main team: Daniele Asoni, David Barrera, Cristina Basescu, Chen Chen, Laurent Chuat, Sam Hitz, Jason Lee, Tae-Ho Lee, Steve Matsumoto, Chris Pappas, Adrian Perrig, Raphael Reischuk, Stephen Shirley, Pawel Szalachowski, Ercan Ucan 23

24 SCION Architectural Design Goals High availability, even for networks with malicious parties Adversary: access to management plane of router Communication should be available if adversary-free path exists Secure entity authentication that scales to global heterogeneous (dis)trusted environment Flexible trust: operate in heterogeneous trust environment Transparent operation: Clear what is happening to packets and whom needs to be relied upon for operation Balanced control among ISPs, Senders, and Receiver Scalability, efficiency, flexibility 24

25 SCION Isolation Domain (ISD) SCION Isolation Domain requirements Region that can agree on a common root of trust groups a number of ASes Set of ISPs to operate Isolation Domain Core to manage ISD Certificates for roots of trust Manage core path and beacon servers Other ISDs need to agree to connect as peer or as provider Open research issue how to best structure ISDs: political and legal issues arise Possible partition is along geographical regions 25

26 SCION Isolation Domain (ISD) SCION Isolation Domain composition ISD Core with ISD Core ASes Other ISP ASes or end-domain ASes ISD Core TD1 ISD Core

27 Beaconing for Route Discovery Periodic Path Construction Beacon (PCBs) Scalable and secure dissemination of path/topological information from core to edge Policy-constrained multi-path flood to provide multiple paths TD1 Core

28 SCION Forwarding (Data Plane) Domains register paths at DNS-like server in ISD Core End-to-end communication Source fetches destination paths Source path + destination path! end-to-end path Packet contains forwarding information Advantages Isolates forwarding from routing No forwarding table at routers Transparent forwarding Balanced route control TD1 Core path server

29 Path Construction and Usage Path Construction Beacon (PCB) construction: PCB 1 = < T exp Int 1 OF 1 S 1 > Opaque field OF 1 = Int 1 MAC K ( T exp Int 1 ) TD Signature S 1 = { PCB 1 } K PCB 2 = < T exp Int 1 OF 1 S 1 Int 2 Int 3 OF 2 S 2 > Int 1 Opaque field OF 2 = Int 2 Int 3 MAC K ( T exp Int 2 Int 3 OF 1 ) Signature S 2 = { PCB 2 } K Int 2 Int 3 AS receiving PCB 2 : Verify signatures Use opaque fields O 1 O 2 to send packet to ISD Core 29

30 Inter-ISD Communication ISD1 Core PS1 ISD2 Core ISD Core Interconnect ISD 4 Core ISD 3 Core PS3 A D G H I E B C F

31 Shortcuts through Peering Links ISD1 Core ISD2 Core ISD Core Interconnect ISD 4 Core ISD 3 Core A D G Peer H I C B Peer E F

32 Handling Link Failures SCION clients use multi-path communication by default, other paths are likely to still function Path construction beacons are constantly sent, disseminating new functioning paths Link withdrawal message sent upstream to cause path servers to remove paths with broken link downstream to cause beacon servers to remove paths with broken link 32

33 SCION Implementation Status V1.0 specification almost completed 3 rd generation C/C++ implementation 4 th generation: Python implementation High-speed router implementation switching 120Gbps on off-the-shelf PC So far ~60 person-years of effort invested Growing testbed 33

34 SCION Packet Header Type Vers Src Type Dst Type Total Len TS* Source Address (variable size) Destination Address (variable size) Curr OF* Next Hdr. HDR Len Info EXP Time ISD ID hops reserved Opaque Field (0) Next Ext. Ext Hdr Len extension-related data more extension-related data Next Ext. Ext Hdr Len extension-related data L4 Proto 34

35 Incremental Deployment Aspects Current ISP topologies consistent with SCION ISDs Minor changes for ISPs SCION edge router deployment Beacon / certificate / path server deployment (inexpensive commodity hardware) Regular MPLS/IP/SDN forwarding internally IP tunnels connect SCION edge routers in different ADs Minor changes in end-domains IP routing used for basic connectivity SCION gateway enables legacy end hosts to benefit from SCION network 35

36 ISD1 Core DENA Project Initial deployment without any changes to host ISD2 Core ISD Core Interconnect G ISD 3 Core ISD 4 Core A D Peer H I E B C F

37 Demo: High-Speed Router Standard PC with dual Intel Xeon E processors (~$500) 8 cores per processor Intel 82599EB X520-DA2 NIC (2x 10Gbps) (~$600) Spirent SPTN4U-220 traffic generator 37

38 38

39 SCION Summary Complete re-design of network architecture resolves numerous fundamental problems BGP protocol convergence issues Separation of control and data planes Isolation of mutually untrusted control planes Path control by senders and receivers Simpler routers (no forwarding tables) Root of trust selectable by each ISD SCION is an isolation architecture only for the control plane, in the data plane it is a transparency architecture. 39

40 Multipath Communication SCION provides end-to-end paths to clients Using multiple paths can provide many benefits: Reliability avoid a single point of failure Bandwidth use more total bandwidth (subject to fairness constraints) Cost use cheaper links Latency use paths with lower propagation delays Different strategies are possible based on applications, path characteristics, and topology 40

41 41

42 Anonymous Communication: HORNET HORNET: High-speed Onion Routing at the Network Layer, Chen Chen, Daniele Enrico Asoni, David Barrera, George Danezis, and Adrian Perrig. [ACM CCS 2015] HORNET is a high-speed Onion Router using SCION No per-flow state on routers Highly efficient processing: 93 Gbps on our node Strong anonymity properties 42

43 OPT: Origin and Path Trace Source Authentication and Path Validation SCION-authenticated paths enable ASes to verify path compliance What about such assurances for sources and destinations? Path validation enables source and destination to check if packets exactly follow the intended AS-level path Source authentication enables routers to authenticate source and packet content High-speed operation, negligible processing overhead, no per-flow state on routers [ Lightweight Source Authentication and Path Validation, Sigcomm 2014] 43

44 SCION Extensions DRKey SIBRA OPT Multi-path Communication DENA Faultprints RainCheck HORNET FAIR ARPKI SAINT APNA 44

45 SCION Deployment at Swisscom and Switch Swisscom AS Level3 AS 3356 Cogent AS 174 TeliaSonera AS 1299 S1 C2 C1 C1 S2 S2 S1 S3 S3 S4 S4 C2 Edge router SCION router E1 E1 ETH E2 E2 45

46 Early Deployment Scenarios Properties desired by banks Guaranteed communication DDoS defense Hijacking resilience Secure certificates Properties desired by government Path control, path guarantees High availability for critical infrastructures Properties desired by education Multi-path communication Research platform 46

47 Opportunities / Trends Mobility SCION supports in-connection path update Multi-path system immediately makes use of new path DNS / path server system enables dynamic updates SDN SCION can work with SDN within domains SCION has properties of an intra-domain SDN Content-centric communication support Cloud computing 47

48 SCION Dangers Too many top-level ISDs Too many ISPs part of ISD core Large packet header size Too many extensions used Higher complexity (Extensions, PKI) Extremely high path fluctuations, changes 48

49 Summary Complete re-design of network architecture resolves fundamental problems BGP protocol convergence issues Separation of control and data planes Isolation of mutually untrusted control planes Path control by senders and receivers Simpler routers (no forwarding tables) Root of trust selectable by Isolation Domain SCION provides new properties, enabling new applications and services Communication transparency Guaranteed bandwidth Anonymity Several ISPs and corporations are now engaging in a pilot deployment 49