Future Internet Projects @ CMU XIA & SCION expressive Internet Architecture Security Architecture Dave Andersen, Adrian Perrig, Peter Steenkiste David Eckhardt, Sara Kiesler, Jon Peha, Srini Seshan, Marvin Sirbu, Hui Zhang Carnegie Mellon University Aditya Akella, University of Wisconsin John Byers, Boston University Adrian Perrig 1 2 1
XIA Vision We envision a future Internet that: Is trustworthy Security broadly defined is the biggest challenge Supports long- term evoluoon of usage models Including host- host, content retrieval, services, Supports long term technology evoluoon Not just for link technologies, but also for storage and compuong capabilioes in the network and end- points Allows all actors to operate effecovely Despite differences in roles, goals and incenoves P1: Evolvable Set of Principals Specifying intent allows future network support to opomize performance, efficiency No need to force all communicaoon at a lower level (hosts), as in today s Internet Allows the network to evolve Content a581fe9... Services d9389fa 3 Host 024e881 Future Entities 39c0348 4 2
P2: Security as Intrinsic as Possible Security properoes are a direct result of the design of the system Do not rely on correctness of external configuraoons, acoons, data bases Malicious acoons can be easily idenofied Host 024e881 Content a581fe9... Services d9389fa Future Entities 39c0348 5 Other XIA Principles Narrow waist for trust management Intrinsically secure idenofiers must match the user s trust assumpoons and intensions Narrow waist allows leveraging diverse mechanisms for trust management: CAs, reputaoon, personal, Narrow waist for all principals Defines the API between principals and network protocol mechanisms All other network funcoons are explicit services XIA provides a principal type for services (visible) Keeps the architecture simple and easy to reason about 6 3
XIA: expressive Internet Architecture Each communicaoon operaoon expresses intent of operaoons Also: explicit trust management, APIs among actors XIA is a single inter- network in which all principals are connected Not a collecoon of architectures implemented through, e.g., virtualizaoon or overlays Not based on a preferred principal (host or content), that has to support all communicaoon What Do We Mean by Evolvability? Narrow waist of the Internet has allowed the network to evolve significantly But need to evolve the waist as well! Can make the waist smarter IP: Evolvability of: Applications Link technologies XIA adds evolvability at the waist: Applications Evolving set of principals Link technologies 7 8 4
Evolvability IntroducOon of a new principal type must be incremental no flag day! Not all routers and ISPs will provide support from day one No universal connecovity Some ISPs may never support certain principal types SoluOon is to provide an. intent and fallback address CID Intent address allows in- AD:HID network opomizaoons based AD:HID on user intent. Fallback address is guaranteed Payload to be reachable 9 Generalizing Evolvable Address Format Use a directed acyclic graph to represent address Router traverses the DAG Priority among edges AD 1 AD 2 Fallback DAG format supports many addressing styles Shortcut rouong, binding, source rouong, infrastructure evoluoon,.. Common case: small dag, most routers look at one XID CID Intent 10 5
XIA Security A key feature of XIA is flexibility, thus, the architecture can be extended in ways we cannot anocipate XIA security depends on Underlying architecture XIA extension principals and mechanisms Specific extensions future designers choose Consequently, detailed security analysis depends on specific principal types 12 XIA High- Level Security Goals Support today's Internet- style host- to- host communicaoon with drasocally improved security Provide improved security for two classes of communicaoon we anocipate being important: content retrieval & accessing services Provide groundwork for future extensions to make good decisions w.r.t. security and availability 13 6
Main Security ProperOes Availability CommunicaOon availability (hosts and services) Finding nearby contents and services Defenses against DoS aqacks AuthenOcity / integrity AuthenOcaOon of user, host, domain, service, content AuthenOcaOon and Accountability Both authorizaoon and deterrence, respecovely Secrecy of idenoty, anonymity, privacy Sender / receiver privacy if desired Trust management How to set up trust relaoons, roots of trust XIA Security Design Principles Well- foundedness: IdenOfiers, associaoons match user s intent Fault isolaoon: Good design reduces dependencies, insulates correct poroons of network operaoon from incorrect/malicious Fine- grain control: Allow users to specify their intent Explicit chain of trust: Allow users to understand the basis for trust, underlying assumpoons 15 7
Check us out at: hqp://www.cs.cmu.edu/~xia/ SCION: Scalability, Control and IsolaOon On Next- GeneraOon Networks Xin Zhang, Hsu- Chun Hsiao, Geoff Hasker, Haowen Chan, Adrian Perrig, David Andersen 16 17 8
Auer years of patching, the Internet is soll neither Reliable nor Secure! Reliable Network Layer Wishlist" Imagine if we had:" Feb 2008: Pakistani ISP hijacks YouTube prefix Apr 2010: A Chinese ISP inserts fake routes affecong thousands of US networks. Nov 2010: 10% of Internet traffic 'hijacked' to Chinese servers due to DNS Tampering. Fixes to date ad hoc, patches Inconvenient truths S- BGP: delayed convergence Global PKI: single root of trust ApplicaOon S- BGP route aqestaoon DNSSec Physical Transport Data link Network S- BGP origin aqestaoon MulO- path rouong Explicit understanding whom you must trust for network operations" Application All relevant parties have balanced control over path selection" Transport The architecture isolates attacks to domains with common laws and economic incentives" No single global root of trust" High efficiency, scalability, flexibility" Physical Data link Network 18 19 9
LimitaOons of the Current Internet DesOnaOon or ISP have no control over inbound paths Route inconsistencies B C D s prefix here! Forwarding state may be different from announced state A D Prefer the red path M 20 LimitaOons of the Current Internet (cont d) Lack of rouong isolaoon A failure/aqack can have global effects Global visibility of paths is not scalable Slow convergence / route oscillaoon Large rouong tables MulO- homing / flat namespaces prevent aggregaoon Lack of route freshness Current (S- )BGP cannot prevent replay of old paths Note that these issues are fundamental to (S)- BGP! 21 10
IsolaOon of aqacks Wish List (1): IsolaOon Scalable and reliable rouong updates Operate with mutually distrusong enooes without a global single root of trust: enforceable accountability Wish List (2): Balanced Control Transit ISPs, source and desonaoon all need path control A B D C Aqacks (e.g., bad routes) M L3 PSC CMU I2 A B D C Hide the peering link from CMU L3 PSC I2 CMU 22 23 23 11
Wish List (3): Explicit Trust SCION Architectural Goals Know who needs to be trusted Absence of consistency in BGP prevents knowing exactly who needs to be trusted Level 3 Who will forward packets on my path? X Y Z Internet PSC CMU I2 24 High availability, even for networks with malicious paroes Explicit trust for network operaoons Minimal TCB: limit number of enooes that need to be trusted for any operaoon Strong isolaoon from untrusted paroes Operate with mutually distrusong enooes No single root of trust Enable route control for ISPs, receivers, senders Simplicity, efficiency, flexibility, and scalability 25 12
SCION Architecture Overview Hierarchical DecomposiOon Trust domain (TD)s IsolaOon and scalability Path construcoon Path construcoon beacons (PCBs) Path resoluoon Control Explicit trust Route joining (shortcuts) Efficiency, flexibility PCB PCB PCB Source TD TD Core path srv S: blue paths D: red paths DesOnaOon Global set of TD (Trust Domains) Map to geographic, poliocal, legal boundaries TD Core: set of top- Oer ISPs that manage TD Route to other TDs IniOate path construcoon beacons Manage Address and Path TranslaOon Servers Handle TD membership Root of trust for TD: manage root key and ceroficates AD is atomic failure unit, conoguous/autonomous domain Transit AD or endpoint AD 26 27 13
Hierarchical DecomposiOon Split the network into a set of trust domains (TD) TD: isolaoon of route computaoon AD: atomic failure unit Down- paths DesOnaOon core TD cores: interconnected large ISPs core Up- paths Source Path Construction" Goal: each endpoint learns multiple verifiable paths to its core" Discovering paths via Path Construction Beacons (PCBs)" TD Core periodically initiates PCBs" Providers advertise upstream topology to peering and customer ADs" ADs perform the following operations " Collect PCBs" For each neighbor AD, select which k PCBs to forward" Update cryptographic information in PCBs" Endpoint AD will receive up to k PCBs from each upstream AD, and select k down-paths and up-paths" 28 29 14
Path ConstrucOon : interface : Opaque field : expiraoon Ome : signature Path ConstrucOon Interfaces: I(i) = previous-hop interfaces local interfaces Opaque field: O(i) = local interfaces MAC over local interfaces and O(i-1) = MAC( ) = SIG( ) = MAC( ) = SIG( ) = MAC( ) = SIG( ) Embed into pkts TD Core PCB PCB PCB A B PCB C 30 Signature: Σ(i) = sign over I(i), T(i), O(i), and Σ(i-1), with cert of pub key TC A: I(TC): ϕ {ϕ, TC1} O(TC) : {ϕ, TC1} MAC Ktc ( {ϕ, TC1} ϕ) Σ(TC): Sign( I(TC) T(TC) O(TC) ϕ) A C: I(A): I(TC) {A1, A2} O(A) : {A1, A2} MAC Ka ( {A1, A2} O(TC) ) Σ(A): Sign( I(A) T(A) O(A) Σ(TC) ) E TD Core (TC) 1 2 1 A 2 1 B 2 1 2 3 1 C D 4 3 2 1 1 1 F G 31 15
C? One PCB per neighbor C E: I(C): I(A) {C1, C4} Path ConstrucOon Interfaces: I(i) = previous-hop interfaces local interfaces Opaque field: O(i) = local interfaces MAC over local interfaces and O(i-1) Signature: Σ(i) = sign over I(i), T(i), O(i), and Σ(i-1), with cert of pub key O(C) : {C1, C4} MAC Ka ( {C1, C4} O(A) ) Σ(C): Sign( I(C) T(C) O(C) Σ(A) ) Also include peering link! I C,D (C): {C4, C2} TD AID D O C,D (C): {C4, C2} MAC Kc ( {C4, C2} ) Σ C,D (C): Sign( I C,D (C) T C,D (C) O C,D (C) O(C) ) E TD Core (TC) 1 2 1 A 2 1 B 2 1 2 3 1 C D 4 3 2 1 1 1 F G 32 Address/Path ResoluOon TD core provides address/path resoluoon servers Each endpoint is idenofied as an AID:EID pair. AID is signed by the containing TD, and EID is signed by the containing AD (with AID). Address is a public key [AIP 2008] Each AD registers name / address at address resoluoon server, uses an up- path to reach TD core Private key used to sign name address mapping ADs select which down- paths to announce ADs sign down- paths with private key and register down- paths with path resoluoon servers 33 16
Route Joining Local traffic should not need to traverse TD core Sender obtains receiver s k down- paths Sender intersects its up- paths with receiver s down- paths Sender selects preferred routes based on k 2 opoons Forwarding Down- path contains all forwarding decisions (AD traversed) from endpoint AD to TD core Ingress/egress points for each AD, authenocated in opaque fields ADs use internal rouong to send traffic from ingress to egress point Joined end- to- end route contains full forwarding informaoon from source to desonaoon No rouong / forwarding tables needed! 34 35 17
Discussion SCION Security Benefits Incremental Deployment Current ISP topologies are consistent with the TDs in SCION ISPs use MPLS to forward traffic within their networks Only edge routers need to deploy SCION Can use IP tunnels to connect SCION edge routers in different ADs LimitaOons ADs need to keep updaong down- paths on path server Increased packet size StaOc path binding, which may hamper dynamic re- rouong IsolaIon S- BGP + DNSSec No collusion/wormhole aqacks poor path freshness path replay aqacks single root of trust SCION Yes no cross- TD aqacks path freshness scalability no single root of trust TCB The whole Internet TD Core and on- path ADs Path Control Too lille (dst) or too much (src), empowering DDoS aqacks Balanced control enabling DDoS defenses 36 37 18
Performance Benefits EvaluaOon Scalability RouOng updates are scoped within the local TD Flexibility Transit ISPs can embed local rouong policies in opaque fields Simplicity and efficiency No interdomain forwarding table Current network layer: rouong table explosion Symmetric verificaoon during forwarding Simple routers, energy efficient, and cost efficient Methodology Use of CAIDA topology informaoon Assume 5 TDs (AfriNIC, ARIN, APNIC, LACNIC, RIPE) We compare to S- BGP/BGP Metric 1: addioonal path length (AD hops) compared to BGP Without shortcuts: 21% longer With shortcuts: o 1 down/up- path: 6.7% longer o 2 down/up- path: 3.5% longer o 5 down/up- path: 2.5% longer 38 39 19
EvaluaOon (cont d) Metric 2: Expressiveness FracOon of BGP paths available under SCION Related Work RouOng security S- BGP, sobgp, psbgp, SPV, PGBGP Only topological correctness; addressed a subset of aqacks addressed in SCION RouOng control MulOpath (MIRO, DeflecOon, Path splicing, Pathlet), NIRA Only given control to the source, and/or liqle security assurance Next- generaoon architectures HLP, HAIR, RBF, AIP, ICING/IGLOO, LISP, OpenFlow, NDN Focusing on other aspects (reducing rouong churns and rouong table sizes, enforcing rouong policies, and providing source accountability, content- centric networking) 40 41 20
Conclusions " Basic architecture design for a next- generaoon network that emphasizes isolaoon, control and explicit trust " Highly efficient, scalable, available architecture " Enables numerous addioonal security mechanisms, e.g., network capabilioes ApplicaOon Physical Transport Data link Network 42 21