Verified Secure Routing David Basin ETH Zurich EPFL, Summer Research Institute June 2017
Team Members Verification Team Scion Design & Development Team Information Security David Basin Tobias Klenze Ralf Sasse Christoph Sprenger Thilo Weghorn Programming Methodology Marco Eilers Peter Müller Network Security Samuel Hitz Adrian Perrig 2
Motivation and Context Routing problems with the status quo (inter-AS routing)
Routing between autonomous systems • Network of networks run by di ff erent institutions • Nodes correspond to Autonomous Systems (ASes) - Set of routers run by common institution (Telcos, ISPs, companies) - 50,000+ ASes, e.g., your typical university or large corporation. 4
Autonomous systems and routers AS 4 AS 1 1. finds paths between ASes AS 3 (and within ASes) 2. forwards data along paths AS 2 • Multiple paths between ASes: 2,1,4 and 2,3,4 • Computed in background by Border Gateway Protocol (BGP) and just one will be selected and used to configure routers 5
Path between two ASes computed using Border Gateway Protocol (BGP) 3 5 7 2 6 4 8 Path : 8,7,5,4,2,1 1 Tra ffi c flow: 1,2,4,5,7,8 Destination Source 6
Boarder Gateway Protocol “I can reach ip “I can reach ip” over AS 8” … 5 8 7 data data ip My network, Destination ip: some IP address range, my rules! e.g., 208.65.153.0/24 • ASes exchange reachability information ( paths ) • Policies programmed by network operators - Decisions on what is accepted, rejected, or propagated - Any AS can announce any address range it wants • It is all based on trust! Motivations may vary! 7
Who controls the Internet? Routers on path can read and modify data NSA data storage center Utah • Control over paths is completely distributed - Border Gateway Protocol (BGP): all nodes flood path announcements • No inbound tra ffi c control 8
Who controls Internet paths? 9
Three concrete examples 208.65.153.0/24 208.65.153.0/22 Pakistan DoS against Youtube (2 hours, 2008) Fribourg’s government Ukraine ISP hijacks UK routes address space stolen including UK Atomic Weapons for 3 days by SPAMers 10
Scion Routing as it should be
Scion Project Secure Future Internet Architecture ▪ Design & Implementation, 75+ man years ▪ Design of routing / forwarding protocols, support ecosystem, and numerous extensions ▪ Clean slate, yet compatible with existing Internet ▪ Not just a research prototype: Growing deployment on 5 continents, 4 ISDs, 26 ASes ▪ See www.scion-architecture.net and related publications CACM 2017, IEEE S&P 2011, CCS 2015, NDSS 2016, S&P 2016 12
SCION Overview ▪ Isolation Domains (ISD) ▪ Control Plane : routing ▪ Path exploration ▪ Path registration ▪ Path resolution ▪ Data Plane : packet forwarding 13
SCION Isolation Domain (ISD) (1) Agreement : (2) Failure Isolation : Each regions agrees on a No ISD can influence common trust root. another ISD’s control TRC ISD plane. core TRC ISD ISD TRC TRC ISD core TRC core core ISD ISD ISD ISD ISD core ISD H F E D D G A A C C I B B 14
SCION Routing (Control Plane) Routing Phases: TRC ISD Beaconing core (1) Path Exploration (2) Path Registration 1 2 (3) Path Resolution PCB ISD 5 3 Core: Out: 4 4 AS E: In: 1, Out: 4 1 AS F: 2 E 5 In: 1, Out: 3 3 4 AS B: In: 1 D 2 1 G 3 1 4 A F 2 3 1 C • Path Construction Beacons (PCB) are 3 H Sequence of signed Hop Fields 2 1 B • Hop Fields (HF) carry the AS X: 1 In: y, Out: z I routing information for one AS 15
SCION Routing (Control Plane) Routing Phases: TRC ISD Beaconing core (1) Path Exploration (2) Path Registration 1 2 (3) Path Resolution PCB ISD 5 3 Core: Out: 4 4 AS E: In: 1, Out: 4 1 AS F: 2 E 5 In: 1, Out: 3 3 4 AS B: In: 1 D 2 1 G 3 1 4 A F 2 3 1 C • Path Construction Beacons (PCB) are 3 H Sequence of signed Hop Fields 2 1 B • Hop Fields (HF) carry the AS X: 1 In: y, Out: z I routing information for one AS 16
SCION Routing (Control Plane) Routing Phases: TRC ISD Path Server Beaconing core (1) Path Exploration B I I (2) Path Registration 1 2 (3) Path Resolution PCB ISD 5 3 Core: Out: 4 4 AS E: In: 1, Out: 4 1 AS F: 2 E 5 In: 1, Out: 3 3 4 AS B: In: 1 D 2 1 G 3 1 4 A F 2 3 1 C 3 H 2 1 B 1 I 17
SCION Routing (Control Plane) Routing Phases: TRC ISD Path Server core (1) Path Exploration B I I (2) Path Registration 1 2 (3) Path Resolution ISD 5 3 4 PCB PCB 1 2 E 5 Core: Core: 3 4 Out: 4 Out: 4 AS E: AS E: = In: 1, Out: 4 In: 1, Out: 3 D 2 1 G 3 1 AS F: AS G: 4 A F In: 1, Out: 3 In: 1, Out: 4 2 3 AS B: In: 1 AS H: 1 C 3 In: 1, Out: 2 H 2 1 B AS I: In: 1 1 Packet Header I 18
SCION Forwarding (Data Plane) Common Packet header TRC ISD Header core Up- Segment Forwarding along: 1 AS B: 2 In: 1, Out: ⊥ • Up-Segment ISD 5 3 • Core-Segment AS F: 4 In: 1, Out: 3 • Down-Segment AS E: In: 1, Out: 4 1 2 E 5 3 4 Segments are Down- sequences of Hop Fields Segment D 2 1 AS E: G 3 (HFs). In: 1, Out: 3 1 4 A F 2 3 AS G: In: 1, Out: 4 1 C 3 H Hop Field contain AS H: 2 1 B routing information of In: 1, Out: 2 1 one AS. AS I: I In: 1, Out: ⊥ 19
Verification High-level, omitting formal details
Can We Verify Scion? • Control and data plane guarantees • Functional correctness of actual code - Suitable for high-assurance business cases - Ensures that routers are backdoor-free • S cion routers are simple and stateless - This is the key to their (feasible) verification - Not possible for current Internet with highly complex routers and giant code bases of millions of lines 21
Correctness and Security SCION approach Code Protocol Properties Properties Verification of the protocol Verification of the components at the network level at the code level • Code-level guarantees • Abstract models of network & network-wide properties (e.g., secure information flow) • Protocol verification guarantees • Guarantees that each SCION that security properties hold in an component behaves as specified adversarial environment, assuming that each SCION component behaves as specified Data Plane Initial focus Router code 22
Network-Level Verification: Approach ▪ Formal specification of network and network-wide properties • Description of network topology, beaconing and path construction, … • Network adversary (on and off-path) • Network-wide security properties ▪ Formal verification : refinement used to go from high-level models to precise assumptions on the individual components needed to ensure security properties. • Correctness by construction: stepwise refinement between (transition) systems • Proofs: forward simulation and invariant preservation • Invariants preserved under refinement ▪ Tool support : verification using Isabelle/HOL system with ETH Zurich developed theory extensions. 23
Scion Properties On both control and data planes Control planes properties: address beacons’ authenticity • Security critical, but not in focus of this talk Data plane properties: address how routers forward messages • Path Authorization: Packets traverse the network only along previously authorized paths. • Weak Detectability: An active attacker cannot hide his presence on the path. 24
SCION Border Routers Z 1 Z 2 PCB ISD PCB core PCB Z 3 PCB Border router Internal router E ISD K D A AS C C B AS Peering link Prov.-Cust. link def router(): while (pkt.nxt()): pkt.process() 25
Concrete Attacker Model We use a localized, colluding Dolev-Yao attacker model TRC ISD core ISD D A C B Attacker controls the Attacker controls entire network entire ASes 26
System & Environment Attacker Environment Network End hosts System OS & Libraries Border Router 27
SCION Router Verification Overview Model Reality Environment Model Real Environment attacker, network Router Router Model Code } Protocol Code Security Properties Security Properties 28 refined by unproven justified proven satisfies
SCION Router Verification Overview Model Reality Environment Model Real Environment attacker, network Router Router Model Code } Protocol Code Security Properties Security Properties 29 refined by unproven justified proven satisfies
Abstract Packet Format The Path is the Packet = Past Path Future Path The Path (consisting of Past and Future) contains Hop Fields (HF) Example: HF1 HF2 HF3 HF4 HF5 HF6 A Hop Field contains routing information of one AS 30
Refinement Overview Communication channels Hop Field format Attacker A Refinement ( ,A, ) ( ,A, , ) ( ,A, , ) A Idea : strengthen attacker while increasing protection of paths. : Fields protected by MAC : Neighbor ASes : MAC : Message set 31
Recommend
More recommend
