BGP Policy

Jennifer Rexford

Challenges of BGP

Large distributed system

More than 20,000 nodes
Autonomous nodes
Diverse policy goals

Trade-off of goals
Flexible policy
Convergence speed
Large scale

Policies in practice
Business relationships, traffic engineering,
scalability, security,

Outline

BGP policy mechanics

Import and export policies
Route attributes
Decision process

BGP policies in practice

Business relationships
Distributing routes inside the AS
Traffic engineering
BGP security

Components of BGP
BGP protocol
Definition of how two BGP neighbors communicate
Message formats, state machine, route attributes, etc.
Standardized by the IETF

Policy specification
Flexible language for filtering and manipulating routes
Indirectly affects the selection of the best route
Varies across vendors, though constructs are similar

BGP decision process

Complex sequence of rules for selecting the best route
De facto standard applied by router vendors
Being codified in a new RFC for BGP coming soon

Border Gateway Protocol

ASes exchange reachability information
IP prefix: block of destination addresses
AS path: sequence of ASes along the path

Policies configured by the network

operator
Path selection: which of the paths to use?
Path export: which neighbors to tell?
I can reach 12.34.158.0/24
via AS 1
I can reach 12.34.158.0/24
2

1
data traffic
12.34.158.5

3
data traffic

BGP Protocol: Update Messages

Update messages
Advertisement
New route for the prefix (e.g., 12.34.158.0/24)
Attributes such as the AS path (e.g., 2 1)

Withdrawal
Announcing that the route is no longer available

Numerous BGP attributes

AS path
Next-hop IP address
Local preference
Multiple-Exit Discriminator

BGP Policy: Influencing Decisions

Open ended programming.
Constrained only by vendor configuration language

Receive Apply Policy =

filter routes &
BGP
Updates tweak attributes
Apply Import
Policies

Based on
Attribute
Values

Best
Routes

Best Route
Selection

Best Route
Table

Apply Policy =
filter routes &
tweak attributes
Apply Export
Policies

Install forwarding
Entries for best
Routes.
IP Forwarding Table

11/11/16

Transmit
BGP
Updates

BGP Decision Process: Path Selection on a

Router

Routing Information Base

Store all BGP routes for each destination
prefix
Withdrawal message: remove the route entry
Announcement message: update the route
entry

Selecting the best route

Consider all BGP routes for the prefix
Apply rules for comparing the routes
Select the one best route
Use this route in the forwarding table
Send this route to neighbors

BGP Decision Process: Multiple Steps

Highest local preference
Set by import policies upon receiving advertisement

Shortest AS path
Included in the route advertisement

Lowest origin type

Included in advertisement or reset by import policy

Smallest multiple exit discriminator

Included in the advertisement or reset by import policy

Smallest internal path cost to the next hop

Based on intradomain routing protocol (e.g., OSPF)

Smallest next-hop router id

Final tie-break

Import Policy: Local Preference

Favor one path over another
Override the influence of AS path length
Apply local policies to prefer a path

Example: prefer customer over peer

Local-pref = 90
AT&T

Sprint

Local-pref = 100
Tier-2
Tier-3

Yale

Import Policy: Filtering

Discard some route announcements
Detect configuration mistakes and attacks

Examples on session to a customer

Discard route if prefix not owned by the customer
Discard route with other large ISP in the AS path

AT&T

Princeton
128.112.0.0/16

USLEC

Export Policy: Filtering

Discard some route announcements
Limit propagation of routing information

Examples
Dont announce routes from one peer to
another
Dont announce routes for management
hosts
Sprint
UUNET

AT&T

Princeton
128.112.0.0/16

network
operator

Export Policy: Attribute Manipulation

Modify attributes of the active route

To influence the way other ASes behave

Example: AS prepending
Artificially inflate AS path length seen by
others
Convince some ASes to send traffic another
way
AT&T

88 88

USLEC

Sprint

Princeton
128.112.0.0/16

88

BGP Policy Configuration

Routing policy languages are vendor-specific
Not part of the BGP protocol specification
Different languages for Cisco, Juniper, etc.

Still, all languages have some key features

Policy as a list of clauses
Each clause matches on route attributes
and discards or modifies the matching routes

Configuration done by human operators

Implementing the policies of their AS
Business relationships, traffic engineering, security

BGP Policies in Practice

Business Relationships

Common relationships
Customer-provider
Peer-peer
Backup, sibling,

Implementing in BGP
Import policy
Ranking customer routes over peer routes

Export policy
Export only customer routes to peers and
providers

Customer-Provider Relationship
Customer pays provider for access to Internet
Provider exports customers routes to everybody
Customer exports providers routes to customers

Traffic to the customer

Traffic from the customer

d

AT&T

advertisements
AT&T
traffic

Princeton

Princeton

Peer-Peer Relationship
Peers exchange traffic between customers
AS exports only customer routes to a peer
AS exports a peers routes only to its customers

Traffic to/from the peer and its customers

advertisements
Sprint

AT&T
traffic
Princeton

UBC

How Peering Decisions are Made?

Peer
Reduces upstream
transit costs
Can increase end-to-end
performance
May be the only way to
connect your customers
to some part of the
Internet (Tier 1)

Dont Peer
You would rather have
customers
Peers are usually your
competition
Peering relationships
may require periodic
renegotiation

Backup Relationship
Backup provider
Only used if the primary link fails
Routes through other paths

AT&T

Princeton
128.112.0.0/16

USLEC

Sibling Relationship

Two ASes owned by the same institution

E.g., two ASes that have merged
E.g., two ASes simply for scaling reasons
Essentially act as a single AS

AT&T

CerfNet

Internal BGP

An AS is Not a Single Node

Multiple routers in an AS
Need to distribute BGP information within the AS
Internal BGP (iBGP) sessions between routers

AS1

eBGP
iBGP
AS2

Internal BGP and Local Preference

Example
Both routers prefer the path through AS 100 on the
left
even though the right router learns an external
path
AS 200

AS 100

AS 300

Local Pref = 100

AS 256

Local Pref = 90

I-BGP

Example: Customer to Provider

router import policies route selection export policies

A

local pref = 100

select UPMC route

select As route

B
132.239.17.0/24

FT

DT
A
UPMC

send to other
iBGP neighbors
send to other
eBGP neighbors

Wanadoo
FT

Example: Peers

router import policies route selection export policies

A

local pref = 90

B
C

select DT route

send to other
iBGP routers
dont send
send to customers

select As route
select As route
132.239.0.0/16

FT
DT
UPMC
Suppose DT, FT,
and BT are peers

Wanadoo
BT

Example: Customers vs. Peers

router import policies route selection export policies

A

local pref (D)= 100

local pref (B)= 80

select DT route

send to other
iBGP and eBGP
neighbors
B

132.239.0.0/16

FT
Suppose:
DT is a customer
of FT and BT
FT and BT are peers

DT
UPMC

Wanadoo
BT

Example: Multiple Egress Points

router import policies route selection export policies

A
B
C

local pref = 80
local pref = 80
local pref = 80

select FT route
select FT route
select BT route

FT
What will router
D choose?

DT
UPMC

send to other iBGP

send to other iBGP
send to other iBGP
route to
UPMC
A
B Wanadoo
C

BT

Hot-Potato (Early-Exit) Routing

route to
UPMC

FT

A
B

1
2

C 1

2
5

IGP distances
D-A : 10
D
D-B: 8
D-C: 7

BT
traffic to UPMC

Hot-potato routing = route to closest egress point

when there is more than
one route to destination

Traffic Engineering

Traffic Engineering Goals

Load balancing
Making good use of network resources
Alleviating network congestion

End-to-end performance
Avoiding paths with downstream congestion
By moving traffic to alternate paths

Mechanisms
Preferring some paths over other paths
E.g., by setting local-preference attribute
Among routes within the same business
class

BGP Decision Process in Action

(2, 1)

(3, 4, 1)

(2, 1)

But, what if the path (3,4,1) would be better?

Manipulating Policy to Move the Traffic

Assign local preference to

Prefer one neighbor over another for a prefix
Prefer certain AS paths over others

Router configuration languages

Specifying rules for setting local-pref attribute
if path(3, *, 1), then local-pref=110
else, local-pref=100

Allow policy to over-ride shortest AS path

Indirect way of making one path look better
or worse than another
Main way to do BGP traffic engineering today

BGP Security

Security Goals for BGP

Secure message exchange between neighbors

Confidential BGP message exchange
Can ASes exchange messages w/o someone watching?

No denial of service
Prevent overload, session reset, tampered messages?

Validity of the routing information

Origin authentication
Is the prefix owned by the AS announcing it?

AS path authentication
Is AS path the sequence of ASes the update traversed?

AS path policy
Does AS path adhere to the routing policies of each AS?

IP Address Ownership

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, whats 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

Address Ownership: Prefix Hijacking

4
3
5
2

12.34.0.0/16
Consequences for the affected ASes

12.34.0.0/16

Blackhole: data traffic is discarded

Snooping: data traffic is inspected, and then redirected
Impersonation: data traffic is sent to bogus destinations

Address Ownership: Subprefix Hijacking

4
3
5
2

12.34.158.0/24

12.34.0.0/16

Originating a more-specific prefix

Every AS picks the bogus route for that prefix
Traffic follows the longest matching prefix

Preventing (Sub)Prefix Hijacking

Best common practice for route filtering

Each AS filters routes announced by customers
E.g., based on the prefixes the customer owns

However, not everyone applies these

practices
Hard to filter routes initiated from far away
So, BGP remains very vulnerable to hijacks

Other techniques
Secure extensions to BGP (e.g., S-BGP, soBGP)
Anomaly detection of suspected hijacks

BGP Attributes: Bogus Paths

AS tampers with AS path

Deletes ASes from the AS path
Prepends with a bogus AS number

Goal: influence the path-selection process

Attract data traffic to the route
E.g., by making AS path look shorter
E.g., delete AS that might trigger route filtering

Create blackholes for parts of the Internet

E.g., prepend bogus AS to trigger loop detection

Very hard to defend against these attacks

How can you tell that the route is bogus?

BGP Attributes: Invalid Paths

AS exports a route it shouldnt

AS path is a valid sequence, but violated policy

Example: customer misconfiguration

Exports routes from one provider to another

interacts with provider policy

Provider prefers routes learned from customers
so provider picks these as the best route

leading the dire consequences

E.g., directing all Internet traffic through
customer

Main defense
Filtering routes based on prefixes and AS path

BGP Attributes: Missing/Inconsistent Routes

Peering agreements require consistent

export
Prefix advertised at all peering points
Prefix advertised with same AS path length
dest

Reasons for violating the policy

Trick neighbor into cold potato
Configuration mistake

Main defense
Analyzing BGP updates
or data traffic
for signs of inconsistency

Bad AS

BGP

data
src

BGP Security Today

Applying best common practices (BCPs)

Securing the session (authentication, encryption)

Filtering routes by prefix and AS path
Resetting attributes to default values
Packet filters to block unexpected control traffic

This is not good enough

Depends on vigilant application of BCPs
and not making configuration mistakes!

Doesnt address fundamental problems

Cant tell who owns the IP address block
Cant tell if the AS path is bogus or invalid
Cant be sure the data packets follow the chosen route

Conclusion

BGP protocol vs. policy

Protocol is simple
Policy is complicated

BGP policy is a black art

Indirect way of specifying policy
Manipulating attributes to influence decisions
Filtering routes to scope the routing
information

Common examples of policy today

Business relationships
Traffic engineering
Security

Discussion

Is BGP trying to do too many things?

Policy
Scalability
Convergence

Is BGP too indirect for its own good?

AS only learns some routes from its neighbors
And applies policies to indirectly pick the
routes

Too many protocols involved?

External BGP
Internal BGP
Intradomain protocol

Gao Paper

Inferring AS relationships
Customer-provider
Peer-peer

Every path tells a story

E.g., a path 701 7018 46
Implies edges (701, 7018) and (7018, 46)
Implies that 7018 (AT&T) allows AS 701 (UUNet)
to transit to AS 46 (Rutgers)

Can limit certain possibilities

E.g., 701-7018 and 7018-46 cant both be peers
E.g., 7018 cannot be the customer of both ASes

Valid and Invalid Paths

AS relationships limit the kinds of valid paths
Uphill portion: customer-provider relationships
Plateau: zero or one peer-peer edge
Downhill portion: provider-customer relationships

Valid

Invalid
Invalid

Characterizations of AS Topology

Tier-1: small number of tier-1 ASes

A near-clique of ~15 ASes with no providers
AT&T, Sprint, UUNET,

Transit core: peer with tier-1s and each

other
Around 100-200 large ASes
UUNET Europe, KDDI, and Singapore Telecom

Regional ISPs: non-stubs near the edge

Around 2000 medium-sized ASes
Minnesota Regional Network, US West

Stub ASes: no peer or customer neighbors

Princeton, Rutgers, MIT, AT&T Research,