The Top Speed of Flash Worms, Stuart Staniford, David Moore, Vern Paxson and Nick Weaver (Nevis Networks, CAIDA/UCSD, ICSI); WORM (Workshop on Rapid Malcode) 2004.

Summary

The paper discusses the possibility of a worm spreading incredibly fast by using a pre-computed list of targets. The paper discusses previous worms such as slammer and witty as a basis for their simulation. Both of these worms were single packet UDP worms that infected various services running on a target machine. This paper picks their infection number to be N = 1 million. This implies that the node infects 9260 nodes and each node after that infects 107 hosts (actually totaling 1 million and 80 hosts). For their model they assume a fixed latency of 103ms with a worm length equal to the size of the worm code in bytes plus four times the number of address in bytes. They also assume that the initial node has a bandwidth of 750 Mbps. After saying this model is too crude, they use a Monte Carlo simulator and find that 95% of hosts can be infected in 510ms and 99% in 1.2s. Similar simulations are used to test a TCP flashworm and it is found that 95% in 1.3s and 99% in 3.3s. The paper then discusses the affect of having false negatives in the map of the worms infection plan. It was found that the infection scheme is not affected much in the broad tree model outlined before and conversely, narrower trees have a much higher failure rate if 20% of the nodes are false positives. Resilient issues are taken into account by having siblings infect the same children in case another sibling fails as well as introducing the concept of acknowledgement (although this factor can slow the worm a lot). Containment defenses are also discussed by reducing parameters such as the spread rate, scanning rate.

Pros:

The paper answers all the questions that might come to the mind of the reader.

All the approximations and data that they are using are probably the best one can get.

The paper is like an ultimate “what if,” so it is still hard to assume this is something that is going to be really done, but it might be an ultimate goal in future.

The timing results are not for a %100 success rate, but it was mentioned that even 90+ percent is still quite a lot and is really impressive.

Cons:

The numbers are really high, and it seems hard to be able to actually have the assumptions they have in a real case. The assumption like the Giga-bit link is kind of too much.

The information collection phase might take a long time and such information should be hard to collect.

It is not know why the congestion window comes into the discussion of sending data over TCP.

Notes and Questions:

Q) How or why do they perform a combination of different RTT data from different regions? Answer: They do a weighted average. Maybe they prefer to have their equations on a unified latency number. They took all the information they could get and combined them into one single number to use.

- Instead of bothering with this tree, if the sender can have a huge bandwidth it can affect many hosts by just blasting out. But still we know that even the tree they build here has still a big branching factor.

- The root might need to have really good processing capabilities, but all the processing is not done the root and the intermediate nodes need to do processing too.

- It seems that once one can get a good up to date hit list this approach would work very well, but getting such list is not easy at all.

- This method can bypass the method proposed the protection model paper we read in the seminar earlier about having protection against buffer overflow attack in firewalls.

- One problem with this approach might be that if it takes some time to generate the hit list so that in the meantime the vulnerability might have been patched.

More Unanswered Questions:

Is this a reliable simulation? What flaws are in their model?