Interdomain Routing Security
Jennifer Rexford
Advanced Computer Networks
http://www.cs.princeton.edu/courses/archive/fall08/cos561/
Tuesdays/Thursdays 1:30pm-2:50pm
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
• Discussion
Security Goals
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?
BGP session
physical link
Validity of Route Announcements
• Origin authentication
– Is the prefix owned by the AS announcing it?
4
3
5
2
1
7
6
12.34.0.0/16
12.34.0.0/16
Validity of Route Announcements
• AS path authentication
– Is AS path the sequence of ASes the BGP update
traversed?
“4 6”
4
3
5
2
1
“7 5 6”
7
6
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
1
2
0
customer
1
2
0
Correspondence to the Data Path
• Agreement between control and data plane
– Does the traffic follow the advertised AS path?
“4 5 6”
4
3
5
2
1
“7 5 6”
7
6
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
BGP (In)Security Today
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
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!
• Doesn’t address fundamental problems
– Can’t
– Can’t
– Can’t
– Can’t
tell who owns the IP address block
tell if the AS path is bogus or invalid
be sure data packets follow the chosen route
easily bound the memory requirements
Security Enhancements to BGP
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
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
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
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.colostate.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
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
Discussion
Security Goals
• What kind of attacks should we withstand?
– Misconfiguration?
– Control-plane adversary?
– Colluding adversaries?
– Data-plane adversaries?
• What solution would we want, from scratch?
– S-BGP?
– Data-plane path verification?
– Multipath routing?
• What kind of solution can be deployed?
– S-BGP? Anomaly detection? Multipath routing?
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
– E.g., Sharon Goldberg’s guest lecture on 11/20
Backup Slides on soBGP
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
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
Public Key Infrastructure (PKI)
• Problem: getting the right key
– How do you find out someone’s public key?
– How do you know it isn’t someone else’s key?
• Certificate Authority (CA)
– Bob takes public key and identifies himself to CA
– CA signs Bob’s public key with digital signature to
create a certificate
– Alice can get Bob’s 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 CA’s public key
Secure Origin BGP (soBGP)
• Design requirements
– Incrementally deployable
– Distributed Web of trust
– Scalability by advertising security info only once
– Trade-off level of security vs. convergence speed
• Verify the AS path is not bogus
– Verify the origin AS is authorized to originate
– Verify the AS path is a valid path to origin AS
• BGP Security message
– Security information carried inside the protocol
– New message; no changes to existing messages
Certificates in Secure Origin BGP (soBGP)
• Entity: establish identity of the AS
– Public key for the AS, and the AS number itself
– Signature created using the AS’s private key
• Authentication: assign/delegate address space
– Address ranges an AS can advertise, and the AS number
– AS validating that the AS can advertise
• E.g., AS owning 10.0.0.0/8 can validate another for 10.1.1.0/24
– Signature created by the validating AS’s private key
• Policy: define policies and connectivity
– A list of ASes that an AS attaches to
– Routing policies applied by the AS
– Signature created using the AS’s private key
Using soBGP
• Upon receiving a BGP announcement
– Can validate information in the BGP updates
– … using information in PolicyCerts and AuthCerts
• Obtaining the certificates
– From new BGP Security message type
– Gathered from well-known Web site
• Though you have to be able to route to the Web site!
• Flexible processing order
– Fast convergence: route handling 1st, security 2nd
– High security: security 1st, during route handling
Pros and Cons of soBGP
• Advantages
– Provides origin authentication
– Incrementally deployable
– Doesn’t interfere with BGP message processing
• Disadvantages
– Path authentication requires a topology database
– Policy checking requires a policy database
– Doesn’t ensure the data path follows the BGP path
• Though, in fairness, this is true for all of the proposals