Interdomain Routing SecurityInterdomain Routing Security

Jennifer RexfordJennifer Rexford

Advanced Computer NetworksAdvanced Computer Networkshttp://www.cs.princeton.edu/courses/archive/fall08/http://www.cs.princeton.edu/courses/archive/fall08/

cos561/cos561/Tuesdays/Thursdays 1:30pm-2:50pmTuesdays/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

1

2

3

4

5

67

12.34.0.0/1612.34.0.0/16

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

Validity of Route Announcements

• AS path authentication– Is AS path the sequence of ASes the BGP

update traversed?

1

2

3

4

5

67

“7 5 6”

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

1 2

0

1 2

0

customer

peers

Correspondence to the Data Path

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

path?

1

2

3

4

5

67

“7 5 6”

“4 5 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 tell who owns the IP address block– Can’t tell if the AS path is bogus or invalid– Can’t be sure data packets follow the

chosen route– Can’t 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