1 Leveraging BGP Dynamics to Reverse-Engineer Routing Policies Sridhar Machiraju Randy H. Katz UC, Berkeley OASIS Retreat, Summer 2005

2 Outline Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work

3 Internet Routing Two-level –Intra-domain (OSPF, IS-IS etc.) –Inter-domain (BGP) Border Gateway Protocol –Policy-aware –Path-vector –Based on bilateral peering relationships

4 BGP Routing Policies Often proprietary and rarely revealed Influence –Whether or not to accept routes –Route selection process –Whether or not to propagate routes to neighbors

5 BGP Routing Policies (contd.) AS A 1.Route with highest local preference 2.Route with smallest # of hops 3.Route learnt over IGP 4.Route with smallest MED, same next hop 5.Route learnt over eBGP 6.Route with smallest IGP metric 7.Route advertised by smallest ID router a) Apply import policies b) Tie-breaking steps in route selection c) Apply export policies

6 BGP Routing Policies (contd.) AS A 1.Route with highest local preference 2.Route with smallest # of hops 3.Route learnt over IGP 4.Route with smallest MED, same next hop 5.Route learnt over eBGP 6.Route with smallest IGP metric 7.Route advertised by smallest ID router a) Apply import policies b) Tie-breaking steps in route selection c) Apply export policies

7 Outline Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work

8 Goal Reverse-engineer local preference values Why? –Assist operators in performing inter- domain traffic engineering (TE) –Prevent mis-configured and divergence- causing policies –To understand Internet routing and influence future architectures

9 Prior Work AS relationships –[Subram02characterizing, Wang03inferring, Gao01inferring] –Analyze BGP routing tables Use BGP dynamics for root cause analysis –[Feldmann04locating, Caesar03localizing]

10 Outline Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work

11 Solution Overview Leverage BGP dynamics to infer routing policies A D X BC 1.ABDX Router in X fails D withdraws DX from B D withdraws DX from C B withdraws BDX from A 2.ACDX C withdraws CDX from A 3.A withdraws ACDX Loc_pref(B) > Loc_pref(C)

12 Basic Observation ObsDec: AS A advertises paths in order of decreasing preference if –No new paths are advertised to A –A’s policy is unchanged ObsInc: AS A advertises paths in order of increasing preference if –No paths are withdrawn from A –A’s policy is unchanged

13 Proposed Algorithm To use ObsDec –Look at PrefixDown events Use timeout to classify per-prefix updates at a BGP speaker into events Consider events in which a(n initially) stable route was withdrawn. –During PrefixDown New short-lived paths may be advertised in pathological convergence processes

14 Pathological Convergence Process e.g., A’s local preference is not dependent only on next-hop AS A D X BC 1.ABDX Router in X fails D withdraws DX from B,C C selects CEX C advertised CEX to A 2.ACEX B withdraws BDX from A E withdraws EX from C C withdraws CEX from A 3.A withdraws ACEX Loc_pref(B) > Loc_pref(C) E Loc_pref(CEX) >

15 Justifying Heuristics Policies mostly dependent only on next hop A neighbor that did not export earlier will not do so after failure too. Induced updates are rare ([Feldmann04]) New short-lived path advertisements are limited by MRAI timer (30secs) unlike withdraw messages –Only look at first/last update

16 Deducing local preferences BGP router/monitor of AS A observes, for prefix P, a PrefixDown event –Stable route R1 UVWXZD –Followed by route update R2 UVWYD Deduce W’s locpref(X) >= W’s locpref(Y)

17 Deducing local preferences Use ObsDec and ObsInc –On update stream(s) PrefixDown/ PrefixUp events If R1 preferred over R2, –length(R1) > length(R2) implies locpref(R1) > locpref(R2) (+ve inference) –length(R1) = locpref(R2) (-ve inference)

18 Outline Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work

19 Simulations Use SSFNet; pathological example A D BC Default: Shortest path preferred Locpref A (ABD) > Locpref A (AD) Locpref B (BCD) > Locpref B (BD) D advertises to A,B,C 1.C receives AD B advertises BD to A 2.C receives ABD C advertises CD to B B chooses BCD B advertises BCD to A A prefers AD to ABCD 3.C receives AD updates seen by C ABD is not less preferred than AD by A!

20 Simulations If policies depend only on next hop… A D BC Default: Shortest path preferred Locpref A (AB*D) > Locpref A (AD) Locpref B (BC*D) > Locpref B (BD) D advertises to A,B,C 1.C receives AD B advertises BD to A 2.C receives ABD C advertises CD to B B chooses BCD B advertises BCD to A A prefers ABCD to AD 3.C receives ABCD updates seen by C B does prefer BCD over over BD.

21 Archived BGP Data Routeviews archived BGP data –About 50 peers –Updates from Jan 2003 – Jan 2005 –Jan 2005 – million events available – PrefixDown and PrefixUp events MRAI timer –Inferences regarding IP prefixes 6% Positive inferences

22 Validation Whois registries –Incomplete –Confusion regarding RPSL syntax Some specs seem correct – AS5511 –Validated 3 cases manually with registered policy 5511,6505(4),21826 > 5511,3549,21826 –Path prepending was seen to be useless

23 Consistency Validation

24 Consistency Validation Same inference was made from each of the views No new path seen in any of the views –Our heuristic does not see induced updates

25 Applications Non-conforming policies –Deviant policy in about prefixes! –Verio prefers GBX over AS15270, a customer of Verio Inter-domain TE –OpenTransit prefers AS6505 over AS354; path prepending does not help

26 Outline Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work

27 Conclusions and Future Work A novel approach to reverse-engineer local preference using BGP dynamics Pros –Prefix owners (edge ASs) can artificially cause events! More simulations and validation –Clarify/determine when heuristic fails (induced updates)