Presentation on theme: "Shutup An E2E Approach to DoS Defense Paul Francis Saikat Guha Cornell."— Presentation transcript:
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
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