Leveraging BGP Dynamics to ReverseEngineer Routing Policies

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) gt 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
• As policy is unchanged
• ObsInc AS A advertises paths in order of
  increasing preference if
• No paths are withdrawn from A
• As 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., As 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
A
Loc_pref(CEX) gt
Loc_pref(B) gt 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 Ws locpref(X) gt Ws locpref(Y)

17
Deducing local preferences

• Use ObsDec and ObsInc
• On update stream(s) PrefixDown/ PrefixUp events
• If R1 preferred over R2,
• length(R1) gt length(R2) implies locpref(R1) gt
  locpref(R2) (ve inference)
• length(R1) lt length(R2) implies locpref(R1) gt
  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) gt
LocprefA(AD) LocprefB(BCD) gt 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(ABD) gt
LocprefA(AD) LocprefB(BCD) gt 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 gt 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 10000 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)