Shutup An E2E Approach to DoS Defense Paul Francis Saikat 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 dont 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 dont see a good business model for them A small number of OS vendors could achieve broad deployment quickly Unlike ISPs.....

Were not the first..... Marianne Shaw suggested the basic idea of pure E2E DoS prevention on the basis of cooperative hosts (SRUTI06) 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 dont 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 wed 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!)

3 rd party inserts bogus shutup Initiator SM only accepts Shutup message for recently sent flow packet If 3 rd party not on path, hard to guess response Nonce_I Eavesdropping 3 rd 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 doesnt 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 shutupd 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