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

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

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

6. 4 3 5 2 6 7 1 Address Ownership: Prefix Hijacking • 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 12.34.0.0/16 12.34.0.0/16

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

8. 4 3 5 2 6 7 1 Address Ownership: Hijacking & Deaggregation • Originating a more-specific prefix • Every AS picks the bogus route for that prefix • Traffic follows the longest matching prefix 12.34.0.0/16 12.34.158.0/24

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

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

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 peer’s 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! • 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

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

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

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

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 • … <your proposal here>

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