Internet Routing (COS Internet Routing (COS 598A)598A)

Today: Routing Protocol SecurityToday: Routing Protocol Security

Jennifer RexfordJennifer Rexford

http://www.cs.princeton.edu/~jrex/teaching/http://www.cs.princeton.edu/~jrex/teaching/spring2005spring2005

Tuesdays/Thursdays 11:00am-12:20pmTuesdays/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

1

2

3

4

5

67

12.34.0.0/1612.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

1

2

3

4

5

67

12.34.0.0/1612.34.158.0/24

• 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

• 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

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• Main defense

– Filtering routes based on prefixes and AS path

BGP

data

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 src

dest

Bad AS

data

BGP

http://www.cs.princeton.edu/~jrex/papers/imc04.pdf

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