The 5 takeaway messages on BGP

1. Operation regulated by agreements (i.e. money)
2. Routing is based on policies
3. Outbound traffic is under your control: you decide which prefixes to accept
   Inbound traffic is dependent on what your peers do with your advertisements
4. Based on Autonomous Systems, used to create AS paths

BGP Attributes

In order of path selection importance:

• LOCAL_PREF
• AS_PATH (length)
• ORIGIN (historical, always 0)
• MULTI_EXT_DISC (multi-exit discriminator)

Not used for path selection:

• NEXT_HOP
  • Needs to be reachable directly, or via IGP, otherwise it will not be used
  • Used by e.g. route servers in Internet Exchange Points (IXP)

Route Selection Criteria

• (Drop if own AS in AS_PATH)
• (Weight; Cisco specific)
• Highest Local Preference
• Shortest AS Path
• (Lowest Origin; hardly used; historic)
• Lowest MED (to the same neighbor)
• Prefer eBGP over iBGP

Tiebreakers:

• Lowest IGP cost to BGP egress (next hop)
• "Oldest" (longest established) received path
• Lowest router ID
• Lowest neighbour IP

BGP Protocol

State Machine

Description of the above

The Messages

BGP > TCP > IP

Types:

• OPEN: After the TCP session is established, both neighbours send Open messages. Each neighbour uses this message to identify itself and to specify its BGP operational parameters.
• UPDATE: advertises feasible routes, withdrawn routes, or both. – An UPDATE message can act as a KEEPALIVE to reduce unnecessary traffic.
• NOTIFICATION: sent whenever an error is detected and always causes the BGP connection to close.
• KEEPALIVE: exchanged every one-third of the Hold Timer agreed upon between the two BGP routers.
• ROUTE-REFRESH: a request for the peer to re-send all or some of its routes – A ROUTE-REFRESH helps with a soft reset

BGP OPEN

Capability codes:

• (1) Multiprotocol Extensions for BGP-4
• (2) Route Refresh Capability for BGP-4
• (7) BGPsec Capability
• (65) Support for 4-octet AS number capability

BGP UPDATE

BGP NOTIFICATION

BGP REFRESH

Table of prefixes per peer
Incoming routes are filtered on the current policy
If policy changes due to new agreements:

1. Clean routing table, and reset the whole connection (hard reset), creates downtime
2. Instead, do a soft reset. Leave current table intact and ask the neighbour to resend their prefixed, thereby running them through the new policy
   

• Route refresh is a better solution than the soft-reconfiguration solution, which kept all received updates unmodified in memory (Adj-RIB-In).
• This message can be used to ask a BGP peer to resend all routes of a particular address family (say, IPv4 or IPv6).
• If using the Route Refresh, a router does not need to store a separate unmodified copy of all routes from a BGP peer. Whenever it needs to reapply a new inbound policy, it simply sends the peer a Route Refresh message, and the peer will automatically resend all routes of a particular address family.
• Beware: route refresh and soft reset used at times interchangeably.

Traffic Engineering

Outbound

Outbound TE works by manipulating incoming routes

• Change local preference
• Extend inbound AS paths (i.e. 1, 2, 3 -> 1, 1, 1, 2, 3)
• Manipulate the metric (MED), e.g. by using inbound communities

Relatively simple, as it is done through your own policies, you are in control

Examples:

(Prefer customer, so that routes advertised by both go directly to the actual destination, i.e. the customer)

Any routes advertised by both will go through main provider, routes only advertised by backup will use the backup

Always use backup link as long as it is up

Inbound Traffic Engineering

Inbound TE works by manipulating outgoing routes

• Extending AS path is a common hack
• Manipulating MED is the official way
• Setting outbound communities is a modern approach
  • But this does require common policy

More complex than outbound

• Depends on neighbour's policy and willingness to cooperate
• You do not have full control

Last ditch effort: advertise a more specific route, something with a longer prefix

• Some neighbours might not accept it
• Makes yourself less preferable
• Advertise a couple of /20 instead of a single /16 and hope that someone else advertises something more specific
• BGP likes less-specific paths to use as a dumping ground

Examples:

Advertise a longer path to a provider/router you do not want traffic from:

However, providers can "overrule" this and use your routes anyway
You can make the path as long as you want, in the end they make the choice

Through agreements on what community numbers mean, you can still accomplish less traffic from certain providers

Communities

An optional, transitive attribute

• Used to communicate preferred treatment of a route
• Can be used on both in- and outbound
• Can also be used in iBGP

Certain communities have well-known semantics:

• NO_EXPORT: don't export beyond current AS
• NO_ADVERTISE: don't export at all

When receiving a community from an upstream you:

• Can learn where your upstream imported this route
• Can set MED and other policies, as requested

When sending communities outbound to your upstream

• Request specific treatment
  • Set local preference
  • Announce (or not) to specific ASes
  • AS_PATH prepend for certain peerings
• Needs an agreement with upstream to actually implement requested policy

Hot Potato Routing

Hot potato: you want the traffic out of your network/AS ASAP

Choose egress with tiniest IGP distance (the closest router to your device)

But hot potato can also cause issues, e.g. for the other party/AS as it might cause the use of a bad route on their end

Pros:

• Decrease your link usage, let your peers carry it
• (Sometimes) improve round-trip latency, as the peer might have better infra
  Cons:
• Lose control over traffic carried by the peer, it is out of your network
• Sometimes your links might be faster, so forcing it through a peer might be slower

Cold Potato Routing with MED

Inform provider through MED about your preference (lower wins)

iBGP Scaling

Meshes

BGP in Datacentres

Allows the network to carry both L2 and L3 addresses

BGP Security

For example, one can advertise bogus routes and:

• Black-hole the traffic
• Redirect the traffic through your own AS, and save interesting traffic

IP prefix borrowing: look for unused prefixes and use them for malicious purposes

Stability versus Security

No authority to check which prefix belongs to which AS
What neighbours announce to you cannot be controlled
BGP routing depends on trust

BGPSec

Use BGPsec_PATH instead of AS_PATH
Include the intended recipient AS
Adds signatures of all information added to the path, to see who did what
Support incremental deployment: fall back to AS_PATH when needed

Is resource intensive, but not as much as sBGP
Updates are larger, due to signatures
Each update contains only a single prefix
Separate update sent to each peer

MANRS

Four actions that network operators should take:

• Filtering: Ensure the correctness of your own announcements and of announcements from your customers to adjacent networks
• Anti-spoofing: Enable source address validation for at least single-homed stub customer networks, your own end-users, and infrastructure
• Coordination: Maintain globally accessible up-to-date contact information
• Global Validation: Publish your data, so others can validate routing information on a global scale

RPKI and ROA

RPKI is based on X.509 certs
Route Origin Authorisation (ROA)

• Each ROA is signed by only one End Entity (EE)
• Specifies which AS may originate which prefix
  RPKI repositories store ROAs

Validated through a separate protocol (RPKI-PRT)
When routes fail to validate (optionally) discard them

Currently for IPv4

• 53% validated
• 0.45% invalid
• 45% not found

Beyond BGP

BGP expresses policy -> Policy is messy -> BGP is messy

Alternatives:
Locator-Identifier Separation Protocol (LISP)
SCION
Named Data Networking (NDN)