Interdomain Routing Security

How Secure are BGP Security Protocols? Some strange assumptions? – Focused on attracting traffic from as many Ases as possible – Subprefix attacks not considered – Can prefix lists be generated easily? (the evil of multi-homing)

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 Origin authentication – Is the prefix owned by the AS announcing it? /16

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