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
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
Sprint
AT&T
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
– Don’t announce routes from one peer to another
– Don’t announce routes for management hosts
UUNET
AT&T
Princeton
128.112.0.0/16
Sprint
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 customer’s routes to everybody
– Customer exports provider’s routes to customers
Traffic to the customer
Traffic from the customer
d
AT&T
advertisements
AT&T
traffic
Princeton
d
Princeton
Peer-Peer Relationship
• Peers exchange traffic between customers
– AS exports only customer routes to a peer
– AS exports a peer’s routes only to its customers
Traffic to/from the peer and its customers
advertisements
Sprint
AT&T
traffic
Princeton d
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”)
Don’t 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
B
select UPMC route
select A’s 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
don’t send
send to customers
select A’s route
select A’s route
132.239.0.0/16
C
A
FT
DT
UPMC
Suppose DT, FT,
and BT are peers
B
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
A
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
send to other iBGP
send to other iBGP
send to other iBGP
route to
UPMC
FT
What will router
D choose?
DT
UPMC
A
B Wanadoo
C
BT
D
Hot-Potato (Early-Exit) Routing
route to
UPMC
FT
A
B
1
7
2
2
C 1
2
5
1
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, what’s 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
7
1
6
12.34.0.0/16
12.34.0.0/16
• Consequences for the affected ASes
– 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
6
7
1
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 shouldn’t
– 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
• Reasons for violating the policy dest
– 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!
– Doesn’t address fundamental problems
• Can’t tell who owns the IP address block
• Can’t tell if the AS path is bogus or invalid
• Can’t 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 can’t 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, …