Phalanx: Withstanding (?) Multimillion-Node (?) Botnets Paper by Colin Dixon, Thomas Anderson and Arvind Krishnamurthy NSDI ‘08 ?? by Mark Ison and Gergely Biczók

Nice idea, good conference, top university Use against large botnets Modest assumption: swarm’s aggregate BW exceeds botnet’s aggregate BW Detailed design Combines ideas from a number of areas Uses iPlane Evaluation PlanetLab Simulation on real topologies How can this ever go wrong?

The devil is in the details… About the modest assumption Routing and access control Mailbox buffers Attacking routers Deployment Transport protocols and congestion control Evaluation, evaluation, evaluation!

Modest assumption “Swarm’s aggregate BW exceeds botnet’s aggregate BW” Works for near-future scenarios as well! So, let’s calculate (10^6*10^7 bps)/10^4 = 10^9 bps ~1 Gbps This should be the average access link BW of a mailbox You must give very good incentive to deploy this More of this in evaluation

Routing and access control How and how much do you have to change routing, to use these multiple paths? Loose source routing of requests from server to mailbox…OK Although double IP headers for small request packets What happens in the forward path? So you want every packet to go through a different mailbox You need root privileges on client to do that Yet applet is used (zero-installation) Either users have to trust all applets or click “I grant root access” for every single website

Mailbox buffers Don’t forget that the number of actual packets at least doubles!!! Given ~ 1 Gbps access links, what about mailbox buffer sizes? Recent work on sizing router buffers cannot be used (B = (RTT*C)/sqrt(n)) You have no “number of flows”! Badly needs further research

Attacking routers Mailboxes and end-systems are protected What about simple routers? near the border of filter ring at clients

Deployment How can you build a filter ring of 4 ASes in diameter? Contract issues

TCP, UDP, xxxP Concerned about how TCP performs in a multi-path scenario – you’d better be But what about UDP? Significant connection establishment delay for a connectionless transport? More of this in evaluation Back to TCP: simply get rid of it (“we build a simple congestion control protocol”) on all nodes! 30 years of engineering (Postel, Cerf, Kahn, Jacobson, Floyd, Kuzmanovic…) Congestion only at access links: not anymore! FEC or retransmissions: “we could use both” Not TCP friendly: “cannot be” – really?

(The lack of ) Evaluation By far the weakest part of the paper Integration w/ DNS is NOT implemented Evaluation without a major function ready PlanetLab 10 mailboxes: good against VERY-VERY small botnets UDP probe traffic: fetching dynamic webpages w/ UDP??? 25 kBps: going retro??? Attack resilience: 25 kBps can be sustained – bravo! Simulation for scalability Mailbox access links: 10 Mbps (<< 1 Gbps needed) Gain vs. TVA: minimal – even by sending every packet 3x Acceptable connections: ~50% when 2M attackers – good against multimillion-node botnets???

Not only in the details… Complex with a lot of problems But it is worth it right? You (claim to) beat large-scale DDoS at last! Wait a minute…. Works only for fetching dynamic web-content from a single server with UDP at 25 kBps Oops…so this is not THE solution for DDoS