Our work on "Flooding Attack by Exploiting Permanent Forwarding Loops"
(Note that ideally we would like to trace four IP addresses in each /24 network, the beginning one, the middle one and two random IP addresses. Due to lots of complains received from DoD/companies/organizations/reseach centers/etc, the experiment has to be stopped before finished.)
1. Normal traceroute will send probe with ttl-value from 1 to 30 unless it receives the reply from destination or it receives the unreachable/inexistent reply from a router. However, if a router does not reply any ICMP packets, we will expect to get reply as follows,
traceroute:: time-1111872625-seq-3-IP-204.54.187.1-PREFIX-204.54.187.0-LEN-24-.txt.fn
1 128.119.91.254 6.788 ms
2 128.119.2.238 7.928 ms
3 128.119.2.194 4.930 ms
4 65.77.95.161 5.640 ms
5 64.200.240.245 10.673 ms
6 64.200.68.157 8.295 ms
7 64.200.210.178 13.763 ms
8 64.200.240.194 13.506 ms
9 157.130.30.245 14.243 ms
10 152.63.41.34 14.020 ms
11 152.63.35.249 17.372 ms
12 152.63.13.41 33.883 ms
13 152.63.65.165 36.861 ms
14 152.63.64.41 35.709 ms
15 *
16 *
17 *
18 *
19 *
20 *
21 *
22 *
23 *
24 *
25 *
26 *
27 *
28 *
29 *
30 *
In this case, even we send up to 30 probes, but we could not get more information than sending first 15 probes. Most complains we have got belong to this case.
2. In order to reduce the overload of measurement, and also make the traceroute result as meaningful as traditional one, I have modified the "traceroute" tool. We stop the traceroute if we detect timeout in two consecutive hops. So, the result of our lightweight traceroute should be:
1 128.119.91.254 6.788 ms
2 128.119.2.238 7.928 ms
3 128.119.2.194 4.930 ms
4 65.77.95.161 5.640 ms
5 64.200.240.245 10.673 ms
6 64.200.68.157 8.295 ms
7 64.200.210.178 13.763 ms
8 64.200.240.194 13.506 ms
9 157.130.30.245 14.243 ms
10 152.63.41.34 14.020 ms
11 152.63.35.249 17.372 ms
12 152.63.13.41 33.883 ms
13 152.63.65.165 36.861 ms
14 152.63.64.41 35.709 ms
15 *
16 *