Interdomain Routing Security

1. Interdomain Routing Security Jennifer Rexford Advanced Computer Networks http://www.cs.princeton.edu/courses/archive/fall08/cos561/ Tuesdays/Thursdays 1:30pm-2:50pm

2. 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

3. Security Goals

4. BGP session physical link 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?

5. 4 3 5 2 6 7 1 Validity of Route Announcements • Origin authentication • Is the prefix owned by the AS announcing it? 12.34.0.0/16 12.34.0.0/16

6. 4 3 5 2 6 7 1 Validity of Route Announcements • AS path authentication • Is AS path the sequence of ASes the BGP update traversed? “4 6” “7 5 6”

7. 1 2 0 1 2 0 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 customer

8. 4 3 5 2 6 7 1 Correspondence to the Data Path • Agreement between control and data plane • Does the traffic follow the advertised AS path? “4 5 6” “7 5 6”

9. 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

10. BGP (In)Security Today

11. 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

12. 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

13. Security Enhancements to BGP

14. 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

15. 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

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

17. 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

18. 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

19. Discussion

20. 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?

21. 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

22. Backup Slides on soBGP

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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