Internet Routing (COS 598A)
Today: Routing Protocol Security
Jennifer Rexford
http://www.cs.princeton.edu/~jrex/teaching/spring2005
Tuesdays/Thursdays 11:00am-12:20pm
Course Projects
• Report (May 10, end of day)
– Ten pages (11pt, double-spaced, single column)
– Like the 6-pagers (two-column) we’ve read
– Include discussion of related work and evaluation
results (or plan for how to do an evaluation)
• Presentation (May 16, 1:30pm, room 302)
– 15 minutes (20 minutes for two-person projects)
– Allow a few minutes at the end for questions
– Consider giving a practice talk to someone
• Advice is free
– See Web site for guidelines on papers and talks
– Feel free to bounce a draft or outline by me
Outline
• Security goals for BGP
• Security limitations of BGP, and protection
– IP address blocks
– TCP sessions
– BGP route attributes
• Proposed enhancements to BGP
– A three-slide introduction to PKI
– Secure origin BGP (So-BGP)
– Secure BGP (S-BGP)
– Research proposals (e.g., SPV, Whisper, and IRV)
Security Goals for BGP
• 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?
• Validity of the routing information
– Origin authentication
• Is the prefix owned by the AS announcing it?
– AS path authentication
• Is the AS path the sequence of ASes the BGP update traversed?
– AS path policy
• Does the AS path adhere to the routing policies of each AS?
• Correspondence to the data path
– Does the traffic follow the advertised AS path?
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: Hijacking is Hard to Debug
• Real origin AS doesn’t see the problem
– Picks its own route
– Might not even learn the bogus route
• May not cause loss of connectivity
– E.g., if the bogus AS snoops and redirects
– … then may only cause performance degradation
• Or, loss of connectivity is isolated
– E.g., only for sources in parts of the Internet
• Diagnosing prefix hijacking
– Analyzing BGP updates from many vantage points
– Launching traceroute from many vantage points
Address Ownership: Hijacking & Deaggregation
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
Address Ownership: How to Hijack a Prefix
• The hijacking AS has
– Router with eBGP session(s)
– Configured to originate the prefix
• Getting access to the router
– Network operator makes configuration mistake
– Disgruntled operator launches an attack
– Outsider breaks in to the router and reconfigures
• Getting other ASes to believe the bogus route
– Neighbor ASes not filtering the routes
– … e.g., by allowing only expected prefixes
– But, specifying filters on peering links is hard
TCP Connection Underlying BGP Session
• BGP session runs over TCP
– TCP connection between neighboring routers
– BGP messages sent over TCP connection
– Makes BGP vulnerable to attacks on TCP
• Main kinds of attacks
– Against confidentiality: eavesdropping
– Against integrity: tampering
– Against performance: denial-of-service
• Main defenses
– Message authentication or encryption
– Limiting access to physical path between routers
– Defensive filtering to block unexpected packets
TCP Connection: Attacks Against Confidentiality
• Eavesdropping
– Monitoring the messages on the BGP session
– … by tapping the link(s) between the neighbors
• Reveals sensitive information
– Inference of business relationships
– Analysis of network stability
BGP session
• Reasons why it may be hard
– Challenging to tap the link
physical link
• Often, eBGP session traverses just one link
• … and may be hard to get access to tap it
– Encryption may obscure message contents
• BGP neighbors may run BGP over IPSec
TCP Connection: Attacking Message Integrity
• Tampering
– Man-in-the-middle tampers with the messages
– Insert, delete, modify, or replay messages
• Leads to incorrect BGP behavior
– Delete: neighbor doesn’t learn the new route
– Insert/modify/replay: neighbor learns bogus route
• Reasons why it may be hard
– Getting in-between the two routers is hard
– Use of authentication (signatures) or encryption
– Spoofing TCP packets the right way is hard
• Getting past source-address packet filters
• Generating the right TCP sequence number
TCP Connection: Denial-of-Service Attacks
• Third party sends bogus TCP packets
– FIN/RST to close the session
– SYN flooding to overload the router
• Leads to disruptions in BGP
– Session resets, causing transient routing changes
– Route-flapping, which may trigger flap damping
• Reasons why it may be hard
– Spoofing TCP packets the right way is hard
• Difficult to send FIN/RST with the right TCP header
– Packet filters may block the SYN flooding
• E.g., filter packets to BGP port from unexpected source
• … or destined to router from unexpected source
TCP Connection: Exploiting the IP TTL Field
• BGP speakers are usually one hop apart
– To thwart an attacker, can check that the packets
carrying the BGP message have not traveled far
• IP Time-to-Live (TTL) field
– Decremented once per hop
– Avoids packets staying in network forever
• Generalized TTL Security Mechanism
(RFC 3682)
– Send BGP packets with initial TTL of 255
– Receiving BGP speaker checks that TTL is 254
– … and flags and/or discards the packet others
• Hard for third-party to inject packets remotely
BGP Message Attributes
• BGP route attributes
– AS path (and the resulting AS path length)
– MED, origin type, next-hop, communities, etc.
• Main kinds of attacks
–
–
–
–
Bogus path: AS path that does not exist
Invalid path: AS path that violates routing policy
Missing/inconsistent routes: violating peering agreement
Bogus attributes: unexpected MED, origin, etc.
• Main defenses
– Route filtering based on ASes in AS path
– Resetting attributes to default/expected values
– Collecting and analyzing measurement data
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
BGP
• Main defense
data
– 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
http://www.cs.princeton.edu/~jrex/papers/imc04.pdf
data
src
BGP Attributes: Bogus Attributes
• BGP neighbor (mis)assigning attributes
– With the goal of misleading the neighbor
– … to affect how data packets are forwarded
• Examples
– MED: trick neighbor to cold-potato routing
– Origin type: trick neighbor to (dis)favor route
– Next-hop: trick neighbor to forward wrong way
• Main defense
– Resetting attributes to default value
– E.g., set MED to zero on all sessions
– E.g., set next-hop to the peer’s IP address
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
Proposed Enhancements to BGP
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 advertisement
– 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
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
• But, the cryptography is very heavy-weight
– … and sBGP is less incrementally deployable than soBGP
Current Status
• IETF proposals
– soBGP: relatively new, in the last couple of years
– sBGP: worked on for much longer
• Active research area
– Secure Path Vector: lower crypto complexity
– Whisper: detect (and hopefully diagnose)
inconsistencies without using a PKI
– Interdomain Route Validation: separate server per
AS for validating BGP information
– … <your proposal here>
Next Time: Overlay Services
• Two papers
– “Resilient Overlay Networks”
– “On Selfish Routing in Internet-Like Environments”
• Review just of second paper
– Summary
– Why accept
– Why reject
– Avenues for future work
• Optional
– “A System for Authenticated Policy-Compliant
Routing” (Bonus points: Why is it called Platypus?)