(Inter)Network Protocols: Theory and Practice Lecture 3 Dr (Inter)Network Protocols: Theory and Practice Lecture 3 Dr. Michael Schapira

Quick Reminder

The Inter-Net: A Network of Networks Over 42,000 Autonomous Systems (ASes) AT&T Comcast Google Verizon Interdomain routing: Between ASes, handled by the Border Gateway Protocol (BGP) Intradomain routing: within an AS

Formal Model of BGP Routing: The AS Graph Internet modeled as “AS graph” G=(V,E) Each vertex in V represents a single AS V consists of n source nodes 1,…,n and a unique destination node d Each edge represents a BGP connection

Formal Model of BGP Routing: Routing Policies Let Ri denote the set of all simple (loop-free) routes from source node i to the destination d. Each source node i has an order ≤i over all routes in Ri This captures ASes’ routing policies (including import and export)

Formal Model of BGP Routing: Dynamics The system evolves over infinitely many discrete time steps t=1,… At each time step a subset of the nodes is “activated” Each node is activated infinitely many times

Formal Model of BGP Routing: Dynamics (Cont.) Whenever a node i is activated it executes the following actions: Examine the most recent route announcement of each neighboring node. Select best available route according to ≤i Announce newly chosen route to all neighbors via update messages. Sent update messages can arrive after an arbitrary delay (but are received in the order of delivery along each link)

Illustration: BGP Dynamics Prefer routes through 1 Prefer routes through 2 1 2 1, my route is 2d 1, I’m available 2, I’m available d A stable state is reached

Formal Model of BGP Routing: Stable State Defn: A stable state is a collection of routes (P1, …, Pn), where PiєRi for every iє[n], such that Consistency: If node j is node i’s next-hop node on Pi then Pi = (i,j)Pj Stability: If node j is node i’s neighbor, and i is not on Pj, then Pi ≥ (i,j)Pj

Guaranteeing BGP Convergence We want BGP to always (eventually) reach a stable state (and quickly!). Defn: BGP is safe if convergence to a stable state is guaranteed for every initial state of the network schedule of node activation and update message arrivals

Illustration: BGP Oscillation 31d 3d 312d … 12d 1d 123d … 3 1 d 23d 2d 231d … 2 No stable state even exists in this network

Unique Stable State is Necessary

Illustration: BGP Oscillation Prefer routes through 2 Prefer routes through 2 BGP might oscillate indefinitely between 1d, 2d and 12d, 21d 1 2 2, my route is 1d 1, my route is 2d 1, 2, I’m the destination d

Observable-Actions Model n nodes 1,…,n Node i has action space Ai A=A1•…•An A-i=A1•…•Ai-1•Ai+1•…•An Node i has reaction function fi:A-i→Ai f=(f1,…,fn) fi can capture node i’s “best-responses”

Observable-Actions Model (Cont.) Infinite sequence of discrete time steps t=1,… A schedule s:{1,…} →2[n] maps each time step to the subset of nodes “activated” at that time step a fair schedule activates each node infinitely often An initial action-profile and schedule naturally induce a dynamics.

Observable-Actions Model (Cont.) Defn: An action-profile a*=(a1,…,an) is a stable state if fi(a*)=ai for all i. that is, a* is a fixed point of f. Defn: A system is convergent if for every choice of initial action-profile and fair schedule the induced dynamics converges to a stable state.

Non-Convergence Result Thm: If there exist multiple stable states, then the system is not convergent.

Application: Diffusion of Technologies in Social Networks Two technologies: {X,Y} Each node wishes to have the same technology as most of his neighbors (with ties broken in X’s favor).

Proof via a Valency Argument [Fischer-Lynch-Patterson, 1983] We will use a valency argument a classical technique for proving impossibility results in distributed computing theory first introduced by Fischer, Lynch and Patterson [FLP] in 1983 in the context of consensus protocols. This result does not follow from FLP’s impossibility result for consensus protocols (or vice versa). We now proceed to proving the theorem.

The Dynamics Graph State R i-transition aR:=aS except aRi:=fi(bS) bR:=bS State S knowledge transition State T action vector aS=(aS1,…,aSn) knowledge vector bS=(bS1,…,bSn) aT:=aS bT:=aS

Visualizing Dynamics The dynamics graph captures all dynamics. The scenario where the initial state is a0. nodes 1 and 3 react simultaneously. then nodes 2 and 3 react simultaneously. is captured as follows:

Visualizing Dynamics The dynamics graph captures all dynamics. The scenario where the initial state is a0. nodes 1 and 3 react simultaneously. then nodes 2 and 3 react simultaneously. is captured as follows: State S aS=bS=a0

Visualizing Dynamics The dynamics graph captures all dynamics. The scenario where the initial state is a0. nodes 1 and 3 react simultaneously. then nodes 2 and 3 react simultaneously. is captured as follows: State S aS=bS=a0 1-transition 3-transition k-transition

Visualizing Dynamics The dynamics graph captures all dynamics. The scenario where the initial state is a0. nodes 1 and 3 react simultaneously. then nodes 2 and 3 react simultaneously. is captured as follows: State S aS=bS=a0 1-transition 3-transition k-transition 2-transition 3-transition k-transition

Stability and Fairness Defn: A state S in the dynamics graph is stable if every outgoing edge from S leads to S. Defn: A fair path in the dynamics graph is a path that for each i, contains an i-transition contains a knowledge transition.

Attractor Regions Defn: The attractor region of a stable state S are all states from which every (long enough) fair path reaches S.

Proof Sketch (Cont.) Claim: A fair cycle in the dynamics graph implies an oscillation in our model. Proposition: If there are multiple stable states then there are states in the dynamics graph that are not in any attractor region (“neutral states”).

Coloring States Color each attractor region in a different color – red, blue, etc. Color the neutral states in purple.

Creating Oscillations Key idea: We show that from every purple state there is a fair path that leads to another purple state. The number of purple states is finite and so this implies a fair cycle.

Proof Sketch (Cont.) Lemma: There cannot be two edges leading from a purple state to two non-purple states that do not have the same color. Intuition: We can swap the order of activations without affecting the outcome. a b a,b : different transitions b a ?

Proof Sketch (Cont.) Fix a purple state p. Let R be a “maximal” fair path from p to another purple state. R q … … p

Proof Sketch (Cont.) Let a be a transition that is not on R. Observe that a at q takes us to a non-purple (say, red) state. R q … … a p

Proof Sketch (Cont.) Because q is purple it must have a fair path to a non-purple non-red state. R u … q … … … a p

Proof Sketch (Cont.) Now, we prove that a at u must take us to a red state --- a contradiction! R u … q … a … … a p

The Gao-Rexford Theorem

Business Relations Imply Structure No customer provider cycles Stub Tier-3 Tier-1 Tier-1 Tier-2

Business Relations Affect Route Selection E.g., prefer providers over customers Tier-1 d Tier-3 LocalPref = 100 LocalPref = 90 Tier-2

Business Relations Affect Route Export E.g., do not announce provider-learned routes to other providers Tier 1 Tier 1 I have a route to d Tier 2

Gao-Rexford Conditions Topology Condition: No customer-provider cycles in the AS graph Preference Condition: Prefer customer-learned routes to provider- and peer-learned routes Export Condition: Only export provider- and peer-learned routes to customers

Business Relations Imply Structure No customer provider cycles Stub Tier-3 Tier-1 Tier-1 Tier-2

Business Relations Affect Route Selection E.g., prefer customers over providers Tier-1 d Tier-3 LocalPref = 100 LocalPref = 90 Tier-2

Business Relations Affect Route Export E.g., do not announce provider-learned routes to other providers Tier 1 Tier 1 I have a route to d Tier 2

Gao-Rexford Conditions Topology Condition: No customer-provider cycles in the AS graph Preference Condition: Prefer customer-learned routes to provider- and peer-learned routes Export Condition: Export provider- and peer-learned routes to customers only.

Gao-Rexford Conditions imply BGP Safety! Thm: If the Gao-Rexford conditions hold for a network then BGP is safe on that network.

Proof of Gao-Rexford Thm Defn: Let P=(i,…,d)єRi and let j be a node on P. Nxt(j,P) denotes the node that comes after j on P (j’s “next-hop” node). Defn: Let P=(i,…,d)єRi. P is a customer-path if i is a provider of nxt(i,P). provider i customer j d

Proof of Gao-Rexford Thm Defn: Let P=(i,…,d)єRi and let j be a node on P. Nxt(j,P) denotes the node that comes after j on P (j’s “next-hop” node). Defn: Let P=(i,…,d)єRi. P is a customer-path if i is a provider of nxt(i,P). Peer-paths and provider-paths are defined similarly

Proof of Gao-Rexford Thm (Cntd.) Defn: Let P=(i,…,d)єRi. P is export-consistent if for every node j on P it holds that nxt(j,P) is willing to export P|nxt(j,P) to j. Claim: If P is an export-consistent customer-path then for every node j on P it holds that P|j is a customer-path. i j k d

Proof of Gao-Rexford Thm (Cntd.) Claim: If P is an export-consistent peer-path then i and nxt(i,P) are peers for every node j≠i on P it holds that P|j is a customer-path i j peers k d

Proof of Gao-Rexford Thm (Cntd.) What does an export-consistent provider-path look like?

Proof of Gao-Rexford Thm (Cntd.) Lemma 1: Fix a fair schedule of node activations and update message. Then, for each node i, from some point in time onwards i’s BGP route is either a stable customer-path; or never a customer-path.

Proof of Gao-Rexford Thm (Cntd.) Lemma 2: Fix a fair schedule of node activations and update message. Then, for each node i, such that from some point in time onwards i’s BGP route is never a customer-path, it holds that from some point in time onwards i’s BGP route is stable.

Proof of Gao-Rexford Thm (Cntd.) The combination of Lemmas 1 and 2 implies the theorem QED

BGP Stability: Summary BGP enables network operators great expressiveness at the potential cost of persistent route oscillations Protocol divergence is bad for network network becomes unpredictable Performance degradation! Gao-Rexford conditions imply BGP safety partial explanation to the Internet’s relative stability

BGP Security

BGP security BGP designed based on trust … and is consequently very vulnerable to attacks Every few years a serious BGP-related failure makes the news

1. BGP Session Security BGP session physical link

To attack BGP, attack TCP! BGP session runs over TCP TCP connection between neighboring routers BGP messages sent over TCP connection Makes BGP vulnerable to attacks on TCP BGP session physical link

Attacks against the BGP session Eavesdropping by tapping the link e.g., to infer routing policies Tampering with packets traversing the link dropping, modifying, or adding packets changing, filtering, or replaying BGP routes Resetting the session or congesting the link

Defending the BGP Session is Easy Two end-points can Use known IP addresses and ports to communicate Can agree to sign and encrypt messages Limited physical access to the link Direct physical link, often in same building Low volume of special traffic Filter packets from unexpected senders Filter packets that travel more than one hop Can give BGP packets higher priority

2. Manipulating BGP No, I’m YouTube! AS 1 AS 2 I’m YouTube

BGP is Vulnerable to Manipulations February 2008: Pakistan Telecom hijacks YouTube! The Internet Pakistan Telecom YouTube I’m YouTube: IP 208.65.153.0/22 -level of autonomous systems -e.g., YouTube, AT&T, pakistan telecom -routing is done on IP addresses, so when someone wants to go to YouTube they get YouTube’s IP address and YouTube announces to the world that they have the ip address and traffic is forwarded towards them. So here multinet would route to it’s provider pakistan telecom that then forwards the traffic on to youtube. -these networks chosen for a specific reason which is that there was an incident in february 2008 pakistan telecom actually high jacked traffic going to youtube (misconfiguration). -they announced to the world that they’re youtube and traffic destined to youtube was routed to them -youtube was unavailable for a couple of hours as operators phone each other to figure out what was going on. Multinet Pakistan Telnor Pakistan Aga Khan University

BGP is Vulnerable to Manipulations What should have happened… drop packets Pakistan Telecom X YouTube I’m YouTube: IP 208.65.153.0/22 -level of autonomous systems -e.g., YouTube, AT&T, pakistan telecom -routing is done on IP addresses, so when someone wants to go to YouTube they get YouTube’s IP address and YouTube announces to the world that they have the ip address and traffic is forwarded towards them. So here multinet would route to it’s provider pakistan telecom that then forwards the traffic on to youtube. -these networks chosen for a specific reason which is that there was an incident in february 2008 pakistan telecom actually high jacked traffic going to youtube (misconfiguration). -they announced to the world that they’re youtube and traffic destined to youtube was routed to them -youtube was unavailable for a couple of hours as operators phone each other to figure out what was going on. Multinet Pakistan Telnor Pakistan Aga Khan University

BGP is Vulnerable to Manipulations What did happen… No, I’m YouTube! IP 208.65.153.0/24 Pakistan Telecom Pakistan Telecom YouTube I’m YouTube: IP 208.65.153.0/22 -level of autonomous systems -e.g., YouTube, AT&T, pakistan telecom -routing is done on IP addresses, so when someone wants to go to YouTube they get YouTube’s IP address and YouTube announces to the world that they have the ip address and traffic is forwarded towards them. So here multinet would route to it’s provider pakistan telecom that then forwards the traffic on to youtube. -these networks chosen for a specific reason which is that there was an incident in february 2008 pakistan telecom actually high jacked traffic going to youtube (misconfiguration). -they announced to the world that they’re youtube and traffic destined to youtube was routed to them -youtube was unavailable for a couple of hours as operators phone each other to figure out what was going on. Multinet Pakistan Telnor Pakistan Aga Khan University

Prefix Hijacking IP address block assignment Regional Internet Registries (ARIN, RIPE, APNIC) Internet Service Providers Proper origination of a prefix into BGP by the AS who owns the prefix … or, by its upstream provider(s) in its behalf However, what’s to stop someone else? prefix hijacking: another AS originates the prefix BGP does not verify that the AS is authorized registries of prefix ownership are inaccurate

How to Do Prefix Hijacking The hijacking AS needs a router with BGP session(s) … configured to originate the prefix This could happen because a network operator makes configuration mistake a network operator launches an attack an outsider breaks into the router and reconfigures

Prefix Hijacking is Hard to Debug The victim AS doesn’t see the problem might not even learn the bogus route May not cause loss of connectivity e.g., if the bogus AS snoops and redirects … may only cause performance degradation Diagnosing prefix hijacking analyzing updates from many vantage points launching traceroute from many vantage points

Defending Against Prefix Hijacks Today: Best common practices (BCPs) filter routes based on prefix (e.g., stubs should only announce their own IP prefixes packet filters to avoid unwanted traffic Not good enough depends on vigilant application of BCPs … and does not handle misconfigurations! does not address the fundamental problem (who owns the IP address block?) Proposed solution: Origin Authentication

Origin Authentication A secure database maps IP prefixes to owner ASes v, Prefix v, Prefix AS 1 AS 2 v v IP Prefix IP AS 3 Simulations run over the whole graph m, Prefix m m m, Prefix Deployment is on the horizon!

Does Origin Authentication Solve Everything? v, Prefix v, Prefix AS 1 AS 2 v v IP Prefix IP AS 3 Simulations run over the whole graph m, v, Prefix m m m, v, Prefix

Bogus AS Paths Path-shortening attacks: Remove ASes from the AS path e.g., turn “1 2 3” into “1 3” Why? to make the AS path look shorter than it is to attract sources that try to avoid AS 2 Other attacks e.g., adding ASes to the path to trigger loop detection AS 1 AS 3 AS 2 ?

AS-Path-Related Attacks Not hard to launch just need a BGP-speaking router Hard to debug need many vantage points Today’s best common practices (e.g., filtering routes based on AS path) not good enough and don’t address the fundamental problem. Proposed solution: Secure BGP other proposals (e.g., Secure Origin BGP) exist

Secure BGP Origin Authentication + cryptographic signatures a1: (v, Prefix) a1 a2 v a3 m IP Prefix In the last slide, attacker announced a path that doesn’t’ exist The next security mechansim we consider V authorizes a1 to send the path (v,Prefix) Add the security property pr ovided “can’t announce paths that don’t exist (no announced) a1: (v, Prefix) m: (a1, v, Prefix) Public Key Signature: Anyone who knows v’s public key can verify that the message was sent by v.

S-BGP Deployment Challenges Complete, accurate registries e.g., of prefix ownership Public Key Infrastructure to know the public key for any given AS Cryptographic operations e.g., digital signatures on BGP messages Need to perform operations quickly to avoid delaying response to routing changes Difficulty of incremental deployment “flag day” to deploy S-BGP not likely

BGP is So Hard to Fix Complex system large decentralized control among competitive ASes critical Hard to reach agreement on the right solution S-BGP with public key infrastructure, registries, crypto? who should be in charge of running PKI and registries? Hard to deploy the solution once you pick it hard enough to get ASes to apply route filters now you want them to upgrade to a new protocol?

3. Data-Plane Attacks

Control Plane vs. Data Plane BGP is a routing protocol, i.e., it computes routes Data plane Routers forward data packets …supposedly along the path chosen in the control plane…

Data-Plane Attacks Drop packets … while still sending the routing announcements maybe just some (BitTorrent? Skype?) Send packets on a different path or to a different destination …

BGP Security: Summary BGP is amazingly vulnerable to configuration errors and deliberate attacks Three types of attacks: attacks on the BGP session manipulating the routing protocol itself data-plane attacks Security measures: today’s (unsatisfactory) best common practices proposed security mechanisms (Origin Authentication, S-BGP, …)