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


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


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.


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


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


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.


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.


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



AP

AS C

AS ZAS X

AS D

If bank.com provides hint:

“D”

AS D



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



• No routing PKI, registries, or S*BGP standardization.• End-to-end security is already widely deployed.• Router hardware already supports deflections.









• Large ISPs can sell “path diversity” as a service.• Edge networks receive immediate security benefits.






• Path selection optimizations (e.g., “hints”) provide incentives for additional routing security.






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

[email protected]

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

Documents

Don’t Secure Routing, Secure Data Delivery