1 / 26

Leveraging BGP Dynamics to Reverse-Engineer Routing Policies

Leveraging BGP Dynamics to Reverse-Engineer Routing Policies. Sridhar Machiraju Randy H. Katz UC, Berkeley OASIS Retreat, Summer 2005. Outline. Internet Routing and Policies Goal Proposed Solution Evaluation Conclusions and Future Work. Internet Routing. Two-level

emilie
Download Presentation

Leveraging BGP Dynamics to Reverse-Engineer Routing Policies

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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.) a) Apply import policies b) Tie-breaking steps in route selection 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 AS A c) Apply export policies

  6. BGP Routing Policies (contd.) a) Apply import policies b) Tie-breaking steps in route selection 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 AS A 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 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 A Loc_pref(B) > Loc_pref(C) B C D X

  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 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(CEX) > A Loc_pref(B) > Loc_pref(C) B C D E X

  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) <= length(R2) implies locpref(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 • D advertises to A,B,C • 1. C receives AD • B advertises BD to A • 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 A updates seen by C D B C Default: Shortest path preferred LocprefA(ABD) > LocprefA(AD) LocprefB(BCD) > LocprefB(BD) ABD is not less preferred than AD by A!

  20. Simulations • If policies depend only on next hop… • D advertises to A,B,C • 1. C receives AD • B advertises BD to A • 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 A updates seen by C D B C Default: Shortest path preferred LocprefA(AB*D) > LocprefA(AD) LocprefB(BC*D) > LocprefB(BD) 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 – 1.188 million events available • 740000 PrefixDown and 450000 PrefixUp events • MRAI timer • Inferences regarding 40000 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 • 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

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

  25. Outline • Internet Routing and Policies • Goal • Proposed Solution • Evaluation • Conclusions and Future Work

  26. 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)

More Related