BGP Security

1
BGP Security

• CS2520 -TELCOM2321
• Wide Area Networks
• KyoungSoo Park
• University of Pittsburgh
• Many slides borrowed from Dr. Jen Rexford

2
Outline

• Security goals for interdomain routing
• Secure message exchange
• Prefix ownership and attributes
• Agreement with the forwarding path
• Preventing resource exhaustion
• BGP (in)security today
• Best common practices
• Proposed security enhancements
• Secure BGP (S-BGP)
• Anomaly-detection schemes

3
Security Goals
4
Secure Message Exchange Between Neighbors

• Confidential BGP message exchange
• Can two ASes exchange messages without someone
  watching?
• No denial of service
• Prevent CPU overload, session reset, and tampered
  BGP messages?

5
Validity of Route Announcements

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

12.34.0.0/16
12.34.0.0/16
6
Validity of Route Announcements

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

4 6
7 5 6
7
Adherence to Business Contracts

• AS path policy
• Does the AS path adhere to the routing policies
  of each AS?
• Is a path announced when it should be?

peers
customer
8
Correspondence to the Data Path

• Agreement between control and data plane
• Does the traffic follow the advertised AS path?

4 5 6
7 5 6
9
Preventing Resource Exhaustion

• Limiting the size of the BGP table
• Can the router run out of memory?
• Storing routes for many prefixes, with long
  paths?
• Limiting the number of BGP messages
• Can the router run out of CPU and bandwidth?
• Due to flapping prefixes, duplicate messages, etc.

BGP sessions
10
BGP (In)Security Today
11
BGP Security Applying Best Common Practices

• Securing the BGP session
• Authentication, encryption, TTL tricks
• Filtering routes by prefix and AS path
• Preventing your customers from hijacking others
• Resetting attributes to default values
• Preventing your peers from tricking you
• Packet filters to block unexpected BGP traffic
• Blocking port 179 from unexpected places
• Preventing resource exhaustion
• Limiting prefixes/session, and prefix lengths

12
Best Practice is Not Good Enough

• Depends on vigilant application of BCPs
• By your neighbors, and your neighbors neighbors,
  and your neighbors neighbors neighbors
• And nobody 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 data packets follow the chosen
  route
• Cant easily bound the memory requirements

13
Security Enhancements to BGP
14
Secure BGP (S-BGP)

• Address attestations
• Claim the right to originate a prefix
• Signed and distributed out-of-band
• Checked through delegation chain from ICANN
• Route attestations
• Distributed as an attribute in BGP update message
• Signed by each AS as route traverses the network
• Signature signs previously attached signatures
• S-BGP can validate
• AS path indicates the order ASes were traversed
• No intermediate ASes were added or removed

15
S-BGP Deployment Challenges

• Complete, accurate registries
• E.g., of prefix ownership
• Public Key Infrastructure
• To know the public key for any given AS
• Cryptographic operations
• E.g., digital signatures on BGP messages
• Need to perform operations quickly
• To avoid delaying response to routing changes
• Difficulty of incremental deployment
• Hard to have a flag day to deploy S-BGP

16
S-BGP

• Prevents many threats
• Prefix hijacking
• Route modification
• But not others
• Collusion two ASes claiming to have an edge
• Policy violation distributing a route from one
  provider to another
• Data-plane attacks announcing one path but using
  another
• Resource exhaustion announcing too many routes

17
Anomaly-Detection Schemes

• Monitoring BGP update messages
• Use past history as an implicit registry
• E.g., AS that announces each address block
• E.g., AS-level edges and paths
• Out-of-band detection mechanism
• Generate reports and alerts
• Internet Alert Registry http//iar.cs.unm.edu/
• Prefix Hijack Alert System http//phas.netsec.co
  lostate.edu/
• Soft response to suspicious routes
• Prefer routes that agree with the past
• Delay adoption of unfamiliar routes when possible
• Some (e.g., misconfiguration) will disappear on
  their own

18
Anomaly-Detection Schemes

• Risk of false positives
• Temporarily (?) avoiding legitimate routes
• Risk of false negatives
• Possibly vulnerable to a smart adversary
• Can detect some paths S-BGP cannot
• E.g., announcing from one provider to another
• Does not prevent all attacks
• Does not prevent collusion or data-plane attacks
• More amenable to incremental deployment

19
Conclusions

• BGP is highly vulnerable
• Based on trust, even of ASes many hops away
• BGP security is a serious problem
• Blackholing, snooping, impersonating, spamming
• Defining the threat is challenging, too
• Control-plane validation or much, much more?
• Incremental deployment is a real challenge
• Bootstrapping a PKI (though this has improved)
• Still a very active area of research

20
Background Materials
21
Encrypting and Decrypting With Keys

• Encrypt to hide message contents
• Transforming message contents with a key
• Message cannot be read without the right key
• Symmetric key cryptography
• Same secret key for encrypting and decrypting
• makes it hard to distribute the secret key
• Asymmetrical (or public key) cryptography
• Sender uses public key to encrypt message
• Can be distributed freely!
• Receiver uses private key to decrypt message

22
Authenticating the Sender and Contents

• Digital signature for authentication
• Data attached to the original message
• to identify sender and detect tampering
• Sender encrypts message digest with private key
• Receiver decrypts message digest with public key
• and compares with message digest it computes
• Certificate
• Collection of information about a person or thing
• ... with a digital signature attached
• A trusted third party attaches the signature

23
Public Key Infrastructure (PKI)

• Problem getting the right key
• How do you find out someones public key?
• How do you know it isnt someone elses key?
• Certificate Authority (CA)
• Bob takes public key and identifies himself to CA
• CA signs Bobs public key with digital signature
  to create a certificate
• Alice can get Bobs key and verify the
  certificate with the CA
• Register once, communicate everywhere
• Each user only has the CA certify his key
• Each user only needs to know the CAs public key