1

Leveraging BGP Dynamics to Reverse-Engineer Routing

Policies

Sridhar MachirajuRandy H. KatzUC, 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 preference2.Route with smallest # of hops3.Route learnt over IGP4.Route with smallest MED, same next hop5.Route learnt over eBGP6.Route with smallest IGP metric7.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 preference2.Route with smallest # of hops3.Route learnt over IGP4.Route with smallest MED, same next hop5.Route learnt over eBGP6.Route with smallest IGP metric7.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

B C

1. ABDXRouter in X failsD withdraws DX from BD withdraws DX from CB withdraws BDX from A

2. ACDXC 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

B C

1. ABDXRouter in X failsD withdraws DX from B,CC selects CEXC advertised CEX to A

2. ACEXB withdraws BDX from AE withdraws EX from CC 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) <= 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

A

D

B C

Default: Shortest path preferredLocprefA(ABD) > LocprefA(AD)LocprefB(BCD) > LocprefB(BD)

D advertises to A,B,C1. C receives AD

B advertises BD to A2. C receives ABD

C advertises CD to BB chooses BCDB advertises BCD to AA prefers AD to ABCD

3. C receives AD

updates seenby C

ABD is not less preferred than AD by A!

20

Simulations• If policies depend only on next

hop…A

D

B C

Default: Shortest path preferredLocprefA(AB*D) > LocprefA(AD)LocprefB(BC*D) > LocprefB(BD)

D advertises to A,B,C1. C receives AD

B advertises BD to A2. C receives ABD

C advertises CD to BB chooses BCDB advertises BCD to AA prefers ABCD to AD

3. C receives ABCD

updates seenby 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 – 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

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)