Don’t Secure Routing, Secure Data Delivery
-
Upload
chadwick-stokes -
Category
Documents
-
view
48 -
download
0
description
Transcript of Don’t Secure Routing, Secure Data Delivery
Don’t Secure Routing, Secure Data Delivery
Dan Wendlandt (CMU)With:
Ioannis Avramopoulos (Princeton), David G. Andersen (CMU), and Jennifer Rexford
(Princeton)
Availability Centric Routing (ACR): A Multipath Alternative
to Secure BGP Protocols.
Availability Centric Routing (ACR)
The point of this talk:
You don’t need to secure BGP!
Instead:
1) Multipath routing exposes possible paths
2) Hosts find and securely use working paths
=> More bang for your security buck!
Requirements for Secure Communication?
Needs end-to-end security
(e.g., SSL & IPsec).
• Secrecy of Data
• Authenticity of Data
• Availability of the Communication Channel
Depends on routing and forwarding.
Requirements for Routing & Forwarding?
Claim:
The routing and forwarding infrastructure need only ensure availability.
Any additional security should be end-to-end.
Define: Availability
A source can learn about and use a working network path to the destination if such a path exists.
Control plane
Data plane
S*BGP is too much AND too little!
Too Much:
Too Little:
Deployment Requirements:
Global agreement on a protocol + PKI,
Heavy-weight, Internet-wide router upgrades.
Limited Protection:
Cannot avoid data plane attacks or outages on valid BGP paths.
Achieving Availability
Achieving availability is easier than securing the routing protocol:
Multi-path routing
+ check that path “works”
+ alternate path selection
= Availability
Even if the routing protocol is insecure!
Traffic Sources provide end-to-end check (e.g., SSL or IPSec)
Realizing ACR
Collect & offer multiple routes.
Availability Provider (AP): Expose path diversity
Traffic Source: Select & use routes.
Host or Edge Router
“Deflect” packets on alternate paths.
Control Plane
Data Plane
Selecting from set of alternate paths
Monitor quality of current path.
AS Z
Egress #2
APs Offer Alternate Path “Deflections”
AS A
AS D
AS X AS Y
Host A
Host B
Egress #1AP
Deflections use IP-in-IP to
traverse alternate BGP paths learned
by the AP
APs Offer Alternate Path “Deflections”
AS A
AS D
AS X AS Y
RouteMonitor
1. The AP stores all BGP path
information learned by border routers.
Host B
Host A
Egress #1Egress #2
AS Z
AP
2. Source requests alternate paths from the AP. Recieves:
“Y D” via Egress #2
APs Offer Alternate Path “Deflections”
AS A
AS D
AS X AS Y
RouteMonitor
Host B
Host A
Egress #1Egress #2
AS A
AS Z
AP
3. Source chooses desired alternate path, which is deflected by egress #2.
APs Offer Alternate Path “Deflections”
AS A
AS D
AS X AS Y
RouteMonitor
Egress #2
Host B
Host A
Egress #1
AS Z
AP
4. Source encapsulates packet to the egress
point, includes deflection ID.
SRC: Host A
Data
APs Offer Alternate Path “Deflections”
DST: Egress #2
SRC: Host A
DST: Host B
Deflection ID: Y
AS A
AS D
AS X AS Y
RouteMonitor
Egress #2
Host B
Host A
Egress #1
AS Z
AP
5. Packet forwarded with IP to alternate egress.
SRC: Host A
Data
APs Offer Alternate Path “Deflections”
DST: Egress #2
SRC: Host A
DST: Host B
Deflection ID: Y
AS A
AS D
AS X AS Y
RouteMonitor
Egress #2
Host B
Host A
Egress #1
AS Z
AP
6. Egress point decapsulates
packet, sends it to alternate next-hop AS based on ID.
APs Offer Alternate Path “Deflections”
Data
SRC: Host A
DST: Host B
Deflection ID: Y
AS A
AS D
AS X AS Y
RouteMonitor
Egress #2
Host B
Host A
Egress #1
AS Z
AP
6. Packet is forwarded over IP to the destination.
APs Offer Alternate Path “Deflections”
Data
SRC: 10.1.1.1
DST: 20.2.2.2
AS A
AS D
AS X AS Y
RouteMonitor
Egress #2
Host B
Host A
Egress #1
AS Z
AP
Properties of Routing Deflections
1) ACR != source routing. • Source can select only valid BGP paths.
• APs can easily limit or deny access to any path.
2) Deflections already supported in hardware!
Functionality Implemented at Source
Traffic Source: Select & use routes.
Host or Edge Router
Selecting from set of alternate paths
Monitor quality of current path.
Sources Monitoring Path Quality
1) Does current path preserve authenticity?
(e.g., IPSec, SSL)
• Was initial destination authentication valid?
• Are packets being corrupted on the path?
2) Does current path perform well?
(e.g., detect TCP-failures, NetFlow)
• Is loss rate, etc., sufficient to consider this path usable?
Two criteria for a “working path”:
Selecting Alternate Paths
=> Internet outages become brief delays in connection setup.
Key Insight: Single-path BGP limits bogus paths from attackers!
Evaluation of Shortest AS-Path Hueristic: Hosts will explore several a few bad paths per attacking AS before finding a legit path.
Optimizing Path Selection: History
1) History of stable/working routes. • Prefer AS-paths that worked in
the past. • Also prefer similar paths.
Past work suggests that AS-paths change infrequently in practice:
• Rexford, et al. (IMW ’02)
• Chang, et al. (ICNP ’03)
• Butler, et al. (CCS ’06)
Optimizing Path Selection: Hints
2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix.
AP
AS C
AS ZAS X
AS D
If bank.com provides NO hints
Optimizing Path Selection: Hints
2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix.
AP
AS C
AS ZAS X
AS D
If bank.com provides hint:
“D”
AS D
Optimizing Path Selection: Hints
2) Destination-specific connectivity “hints” indicate what upstream ASes are most likely to be legitimately announcing their prefix.
AP
AS C
AS ZAS X
AS D
If bank.com provides hint:
“C D”
AS C AS D
Hints are Simple and Effective
No additional PKI required
Hints verified using end-to-end authentication mechanism.
Evaluation of simple hints:
Only a few TOTAL paths must be explored regardless of the number of attackers!
Evaluation: Resistance to BGP Hijacks
Realistic simulation on inferred AS topology:
• A single tier-1 ISP acts as an availability provider.
• Vary number of attackers, placed in random ASes.
• Test each AS to see if it receives a “valid” route.
What attack resistance can this offer, even with only one AS participating?
Resistance to BGP Hijacks
Evaluate how often three source types have a path to the valid destination, while varying the number of attackers.
1) Single-Path BGPASes use single “best’’ BGP path, as today.
2) Intelligent Multi-homingStub ASes with 5 upstreams succeed if any provider
offers a valid route.
3) Tier-1 Availability ProviderA single tier-1, offering deflections via peer and customer-
learned routes.
ACR Resists BGP Hijacks
ACR Resists BGP Hijacks
Preventing BGP Availability Attacks
Single-Path BGP ACR
Requirements for a successful BGP availability
attack
Attacker must get victim to
hear a path that is “better” than its current path.
Attacker must prevent AP
from hearing any valid path
Adoptability Advantages
Low Barriers to Entry
Strong Deployment Incentives
Drives Incremental Control Plane Security
Performance Benefits of Multipath
Adoptability Advantages
Low Barriers to Entry
• No routing PKI, registries, or S*BGP standardization.• End-to-end security is already widely deployed.• Router hardware already supports deflections.
Strong Deployment Incentives
Drives Incremental Control Plane Security
Performance Benefits of Multipath
Adoptability Advantages
Low Barriers to Entry
Strong Deployment Incentives
Drives Incremental Control Plane Security
Performance Benefits of Multipath
• Large ISPs can sell “path diversity” as a service.• Edge networks receive immediate security benefits.
Adoptability Advantages
Low Barriers to Entry
Strong Deployment Incentives
Drives Incremental Control Plane Security
Performance Benefits of Multipath
• Path selection optimizations (e.g., “hints”) provide incentives for additional routing security.
Adoptability Advantages
Low Barriers to Entry
Strong Deployment Incentives
Drives Incremental Control Plane Security
Performance Benefits of Multipath
• Multipath also supports selection of high performance (e.g., low latency) paths.
Contributions of ACR
1) Secure communication without secure routing.
2) ACR’s benefits (e.g. avoiding data plane threats) are valuable even with s*BGP.
3) Low barriers to entry and clear benefits for early adopters.
Thanks!
Joint work with: Ioannis Avramopoulos (Princeton)
David G. Andersen (CMU) Jennifer Rexford (Princeton)
Contact:
Dan Wendlandt (CMU)
Questions & Comments Please!
Handling Traffic Analysis Attacks?
S*BGP ACR
Cryptographic path attestation makes it difficult for attacker
to get “on path”
Path selection heuristics like route history and “hints”
avoid new and suspicious paths
Is it worth the added complexity of S*BGP?
S*BGP provides stronger protection against malicious ASes getting “on path”, but both are vulnerable to traffic
analysis by well-connected ASes. Only end-to-end techniques (e.g., mix-nets) offer strong protection.
Handling Hijacks of Unused Address Space?
S*BGP ACR
Cryptographic database of prefix
ownership has routers reject invalid
announcements.
Routers accept all announcements.
Is it worth the added complexity of S*BGP?
Unused hijacks are a lesser threat, as they do not compromise availability. Those needing to block traffic
from such addresses can easily use “bogon-like” filters.
What about stupid users?
Single-Path: If an e2e authentication check fails, the only alternative is no reachability. Thus, they prompt the user as a last resort.
Multi-Path: If one check fails, explore alternates until authentication works. No need to prompt the user unless all paths fail.
But You’re Just Asking for More From Sources!
Yes! But consider that:1) End-to-end security is already widely
deployed for many types of traffic. 2) Deploying changes on the edge is easier
(look at speed of SSL/IPSec adoption!)3) No need for global agreement on a “single
best approach”4) Immediate benefits for any application that
adds end-to-end security.
Sure, But Isn’t This Just a Stop-gap?
Not really: It would likely solve the problem more quickly than S*BGP, but:
1) It helps drive improvements to the security of control plane data, helping S*BGP.
2) Prevents data-plane availability attacks not handled by S*BGP
=> ACR offers evolving adoptability path.
Compromised routers in AP network?
• Attacks on AP’s internal routes possible, but prevention & detection is significantly easier
• Internal network probing can easily be done securely.
• Defenses can use knowledge of complete “true” network topology
• Link-state routing protocols are significantly easier to secure.
• Highest robustness from having multiple independent tier-1s as availability providers.
• Paths through other egress routers will still be valid.
Q1: Resistance to Attacks
Tier-1 AP protection degrades slightly with
“local” attackers.
Q1: Adding Customer-Only Filters
Q2: Path Exploration with Intelligent Attacker
Handling Availability Attacks?
S*BGP ACR
Control Plane
Availability
Data Plane Availability
Single-Path, PKI, registry & signatures
Multi-Path, probing to
find working pathsNone
Two Views
The Optimist:
It will be YEARS before S*BGP is in
full use.
The Pessimist:
This is NEVER going to happen.
Members of both sides are asking:
- How will everyone agree on one protocol, and one PKI?
- What incentives are there for ISPs to invest in adoption?
- What can we do in the mean time?
- What is the real problem here???
Progress with Secure Routing Protocols
‘97: S-BGP started
’93: Kumar, authenticated inter-domain route updates
‘96: Smith, path and origin
validation
‘98: Bates, DNS to
verify AS origin
’02: so-BGP
’03:IRV
’04: SPV
’04: Listen & Whisper
’05: psBGP
’06: APNIC begins cert. generation software
dev.
Still, no agreement on a protocol or a PKI