interdomain routing security. how secure are bgp security protocols? some strange assumptions? –...
TRANSCRIPT
Interdomain Routing SecurityInterdomain 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?
1
2
3
4
5
67
12.34.0.0/1612.34.0.0/16
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