Shutup

An E2E Approach to DoS Defense

Paul FrancisSaikat Guha

Cornell

Most approaches to DoS prevention involve the middle

Is a pure E2E approach possible?

A packet recipient can tell a packet sender to stop sending or slow down

Partially or exclusively

Yes!

Requires that the majority of end hosts don’t opt out.

Only applies to botnet-based attacks

With some caveats....

We call it the Shutup Protocol

This is not just an interesting academic exercise

Although we don’t see a good business model for them

A small number of OS vendors could achieve broad deployment quickly

Unlike ISPs.....

We’re not the first.....

Marianne Shaw suggested the basic idea of pure E2E DoS prevention on the basis of cooperative hosts (SRUTI’06)

Katarina Argyraki and Cheriton suggest a “trust but verify” approach, where the middle can punish the end host (Usenix 2005)

Dave Andersen et.tus. propose AIP, E2E DoS control, but which is clean slate and requires address spoofing enforcement in the network

This works as long as....

All these messages are received, and

Third parties don’t insert additional messages

Spoofed source addresses

Initiator spoofs source address

Shutup request goes somewhere else

Solution exploits notion of “return reachability”

Its hard to authenticate the address assignment process

A host can always assign its own address

SM interprets existence of received packet as evidence that the address is legit

Need to protect against collaborator on same LAN sending packets with bogus destination address

Packets are rate-limited until address is validated

Normally that is the MAC of the router

Packets are validated by one received packet, but only for MAC address of sender

SM prevents MAC address spoofing

Our assumption is that such colluding opportunities are rare

Local colluder with disabled SM allows spoofed source addresses

By spoofing MAC of router

Hard to build a big botnet this way

Shutup request blocked by firewall

Initially thought we’d have to transmit shutup request inline with 5-tuple flow

But using ICMP with associated 5-tuple in payload works well

Firewall interprets as a legitimate ICMP message (which it is!)

3rd party inserts bogus shutup

Initiator SM only accepts Shutup message for recently sent flow packet

If 3rd party not on path, hard to guess response Nonce_I

Eavesdropping 3rd party can disrupt flow anyway (TCP RST, etc.)

Heavy forward volume prevents challenge from getting through

Initially SM allows a heavy flow, but later slows down flow if recipient doesn’t explicitly authorize higher rate

Authorized with “throttle” request handshake

“Later” = 5 to 10 seconds

This is effectively a capability

Actually, we allow full rate for a while as long as any packet received from recipient...

What about legacy recipients?They cannot send an explicit throttle

But use random-ish port numbers, TCP seq numbers, etc. to try to “authenticate” received packets

Yeah, this is a bit lame....recipients that want protection should deploy shutup

ns2 simulated attack, attack BW = 240X of bottleneck, 2500 attackers, throttle time = 10s, throttle aggregate BW > bottleneck

Attack starts

Most challenges are dropped

Attackers start to self-throttle. Bottleneck still saturated, but more challenges get through Number of shutup’d

attackers drops quickly

We experimented with having the SM try to detect scanning attacks

What about other unwanted traffic?

Characterized as a large proportion of shutups from many recipients

Tricky part is applications that expect a number of failures, as well as black-holed spam error messages

Some promising results, but. . . .

The case for network witnesses, feng schluessler