Interdomain Routing Security Jennifer Rexford Advanced Computer Networks Tuesdays/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 /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? “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? customer peers

Correspondence to the Data Path Agreement between control and data plane –Does the traffic follow the advertised AS path? “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: –Prefix Hijack Alert System: 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 /8 can validate another for /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 1 st, security 2 nd –High security: security 1 st, 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