Internet Routing (COS 598A) Today: Routing Protocol Security

1
Internet Routing (COS 598A)Today Routing
Protocol Security

• Jennifer Rexford
• http//www.cs.princeton.edu/jrex/teaching/spring2
  005
• Tuesdays/Thursdays 1100am-1220pm

2
Course Projects

• Report (May 10, end of day)
• Ten pages (11pt, double-spaced, single column)
• Like the 6-pagers (two-column) weve read
• Include discussion of related work and evaluation
  results (or plan for how to do an evaluation)
• Presentation (May 16, 130pm, 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

3
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)

4
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?

5
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, whats 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

6
Address Ownership Prefix Hijacking
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

7
Address Ownership Hijacking is Hard to Debug

• Real origin AS doesnt 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

8
Address Ownership Hijacking Deaggregation
12.34.0.0/16
12.34.158.0/24

• Originating a more-specific prefix
• Every AS picks the bogus route for that prefix
• Traffic follows the longest matching prefix

9
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

10
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

11
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
• Reasons why it may be hard
• Challenging to tap the 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

BGP session
physical link
12
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 doesnt 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

13
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

14
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

15
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

16
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?

17
BGP Attributes Invalid Paths

• AS exports a route it shouldnt
• 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
data
18
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
• Trick neighbor into cold potato
• Configuration mistake
• Main defense
• Analyzing BGP updates
• or data traffic
• for signs of inconsistency

dest
Bad AS
BGP
data
src
http//www.cs.princeton.edu/jrex/papers/imc04.pdf
19
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 peers IP address

20
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!
• 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 the data packets follow the chosen
  route

21
Proposed Enhancements to BGP
22
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

23
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

24
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

25
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

26
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 ASs 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 ASs 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 ASs private key

27
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

28
Pros and Cons of soBGP

• Advantages
• Provides origin authentication
• Incrementally deployable
• Doesnt interfere with BGP message processing
• Disadvantages
• Path authentication requires a topology database
• Policy checking requires a policy database
• Doesnt ensure the data path follows the BGP path
• Though, in fairness, this is true for all of the
  proposals

29
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

30
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
• ltyour proposal heregt

31
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?)