5.7 Supporting Routers with Multiple Victim Routes
5.8.4 Precision problem
The last deployment issue concerns the precision in the TPN calculation sub- routine. The worst consequence of this problem is a reduced guarantee on the correctness of the RPPM algorithm.
Cause of the problem
In the TPN calculation subroutine, the accumulative state-change probabil-
ity Xi−1 in Equation (5.4) is updated whenever a new edge is added to the
constructed graph. Theoretically speaking, Xi−1 > P∗ is always true because:
∵ τ∗ ∈ Z+ & 0 < P (T (Ge) = e′) < 1, ∴ 1 − (1 − P (T (Ge) = e′))τ ∗ > P∗ Xi−1 ⇒ Xi−1 > P ∗ .
Though Xi−1 > P∗is always true, Xi−1is approaching to P∗after each update.
At each update, a value less than one is multiplied to Xi−1.
Specifically, if P∗
is very close to Xi−1, then it will result in a precision
problem: there may not have enough precision for the calculation of the ex-
pression log(1 − P∗
Xi−1) in Equation (5.4). In the worst case, the expression
log(1 − P∗
Xi−1) may become log(0), which is a floating-point exception.
The floating-point exception must be avoided, and, to avoid such a problem, the TPN calculation subroutine should stop the update of the accumulated
state-change probability Xi−1.
Denote Xlimit as a real number between 0 and 1. When the difference
between P∗
and Xi−1 is smaller than Xlimit, the TPN calculation algorithm
stops updating the accumulated state-change probability Xi−1. Then, Equa-
tion (5.5) (on Page 137), which originally updates Xi−1, is changed as follows.
Xi−1 = Xi−2 × 1 − 1 − P (T (Gi) = ei) τi−1∗ , i > 1 & |Xi−2− P∗| > Xlimit; Xi−2, i > 1 & |Xi−2− P∗| ≤ Xlimit; 1, i = 1. (5.8) Nevertheless, Equation (5.8) would lead to the failure of the guarantee on the correctness of the constructed graph although the equation can effectively
prevent the difference between Xi−1 and P∗ from becoming one.
Reduced correctness
We show why the guarantee is void. Let X∗
i−1 be the value of the accumu-
lative state-change probability obtained by Equation (5.5), and let Xi−1 be
Equation (5.8). Originally, the upper-bounded TPN τ∗ i is obtained as follows: τi∗ = log1 − P∗ X∗ i−1 log(1 − pmin) + 1 . Since X∗
i−1 ≤ Xi−1, then
∵ log(x) is decreasing when 0 < x < 1,
⇒ log1 − P∗ X∗ i−1 < log1 − P∗ Xi−1 ;
∵ log(x) is negative when 0 < x < 1,
⇒ log „ 1− P ∗ X∗ i−1 « log(1−pmin) > log“1− P ∗ Xi−1 ” log(1−pmin) .
Therefore, the TPN obtained by the bounded accumulated state-change prob-
ability Xi−1 is smaller than that is obtained by the original accumulated state-
change probability X∗
i−1.
The above finding implies a very undesirable consequence: the RPPM al- gorithm terminates before it has truly reached the guaranteed correctness.
In the following, we introduce the runtime probability as a tool to under- stand how the correct guarantee of the RPPM algorithm is void.
Runtime probability and graph reconstruction example
Runtime probability is the probability that the constructed graph is the same as the attack graph calculated during the RPPM algorithm is running. By definition, the accumulated state-change probability is already the runtime probability, and the runtime probability is merely a more meaningful alias.
We take another look at the graph reconstruction example in Section 5.5 (on Page 139) to show how the runtime probability helps understanding how the RPPM algorithm cannot provided the said guarantee. In the example,
we assume that Xlimit = 1, and thus the accumulative state-change probabil-
ity would not be updated when a new edge is added. Still, we assume that the constructed graph is always connected. The marking probability and the
When the first marked packet arrives, it should encode the edge (R1, v) in
Figure 4.7. But, this time, X1 should not be updated and X1 is still equal to
1. Then, when the edge (R2, R1) is added to the constructed graph, the TPN
at state C2 becomes: τ2 = $ log 1 − 0.51 log 1 − 1 7 + 1 % = ⌊5.4966⌋ = 5 ;
If the number of marked packets arrived at the victim is larger than τ2
before the third edge arrives, the runtime probability is:
1 − 1 −132
×1 − 1 − 175
= 0.2985 .
while, according to Section 5.5 (on Page 139), the original runtime probability is:
1 − 1 −132
×1 − 1 − 1715
= 0.5005 .
The above example shows that the runtime probability is 0.2985, and this means the RPPM algorithm could provide only a guarantee on the correctness of the constructed graph of 0.2985 although the required guarantee is 0.5. Repeated executions
We propose that the RPPM algorithm should be executed more than one time in order to provide the promised correctness again. The trick of the repeated execution method is to treat the returned constructed graph from the previous execution instance as the input of the new execution instance.
Intuitively, this method works as follows. Say, at the first execution instance of the RPPM algorithm, the construction graph is not yet the attack graph. Then, continuing the second execution instance means giving the constructed graph chances to continue to evolve.
Mathematically, denote Prun,i as the runtime probability of the ithinstance
Repeated RPPM Algorithm(Traceback Confidence Level P∗)
1. Execute the RPPM algorithm at traceback confidence level P∗
and with an empty constructed graph;
2. Obtain the runtime probability P run;
3. Obtain the constructed graph Gc;
4. While P run < P∗ ; do
5. Execute the RPPM algorithm at traceback confidence level P∗
and
with the constructed graph Gc;
6. Obtain the runtime probability P run′;
7. Obtain the constructed graph Gc;
8. P run := 1 − ((1 − P run) × (1 − P run′
)); 11. Done
Figure 5.26: The pseudocode of repeating the RPPM algorithm to increase the runtime probability.
correct after n consecutive executions of the RPPM algorithm, P (repeat n times), is given by: P (repeat n times) = 1 − n Y i=1 (1 − Prun,i) . (5.9)
Since Prun,i > 0, as n increases, P (repeat n times) also increases. There-
fore, one can keep repeating the execution of the RPPM algorithm until the guaranteed correctness is reached.
Pseudocode of repeated execution
Figure 5.26 shows the pseudocode of repeating the executions of the RPPM algorithm until the probability that the constructed graph is same as the attack
graph is larger than the traceback confidence level P∗.
The pseudocode works as follows. After the RPPM algorithm has been executed for the first time, the runtime probability as well as the constructed graph can be obtained after. If the runtime probability P run is less than
the traceback confidence level P∗
, then the RPPM algorithm algorithm will
be executed repeatedly until P run is larger than P∗.
To summarize, the RPPM algorithm has a precision problem when it is deployed. We observed that the precision problem would cause the RPPM algorithm to fail to guarantee on the correctness of the constructed graph. We propose executing the RPPM algorithm repeatedly so as to increase such a
correctness until the traceback confidence level P∗ is reached.
5.9
Chapter Summary
Based on the termination condition analysis, one can conclude that the ex- pected sufficient packet number (described and derived in Chapter 4) is not a desirable termination condition of the PPM algorithm. Yet, there is a need for the PPM algorithm to have a guarantee of the correctness of the constructed graph.
In this chapter, we have suggested a new termination condition of the PPM algorithm. We devised the rectified graph reconstruction procedure that gives a precise termination condition for the PPM algorithm, and we called the new traceback approach the rectified probabilistic packet marking algorithm (RPPM algorithm for short). The RPPM algorithm, on one hand, does not require any previous knowledge about the network graph, and, on the other hand, guarantees that the constructed graph is a correct one with a specified probability, and such a probability is an input parameter of the algorithm.
We have carried out a series of simulations to show the correctness and robustness of the RPPM algorithm. The simulation results show that the RPPM algorithm can always satisfy our claim that the constructed graph is correct with a given probability. Also, the algorithm is robust under different values of the marking probability and different structures of the attack graphs. Moreover, we have addressed issues when the RPPM algorithm is deployed. To
conclude, the RPPM algorithm is an effective means to improve the reliability of the original PPM algorithm.
In this thesis, we focus on the defense mechanisms against the distributed denial-of-service attack (DDoS attack for short). Specifically, we target on the traceback of the locations of the attackers who are demonstrating a flood-based DDoS attack. Yet, we narrow down our scope, and we consider only the sources that are sending out attack traffic as the attackers.
We have proposed a revolutionary, divide-and-conquer traceback method- ology, and the methodology is twofold. When a global-scale attack happens, we proposed that the first step of the traceback process is to locate the Internet service providers (ISPs for short) that are contributing overwhelming traffic through a macroscopic traceback algorithm. Once the problematic ISPs are uncovered, in the next step, each concerned ISP should locate the attackers within its administrative domain using a microscopic traceback algorithm.
Such a divide-and-conquer approach has two merits. First, it provides a fast way to confine the domain of the DDoS attack. Second, if the scale of the DDoS attack is large, this approach divides the traceback problem into several sub-problems, and conquers them in a parallel manner. In the thesis, we first devised a macroscopic traceback algorithm called the distributed snap- shot traceback algorithm. Then, we employed and enhanced the well-known probabilistic packet marking algorithm, which suits the conditions of being a microscopic traceback algorithm.
The distributed snapshot traceback algorithm (snapshot algorithm for short)
is the first traceback algorithm of its kind. Leveraging the well-known Chandy- Lamport distributed snapshot algorithm, the snapshot algorithm coordinates the border routers of the ISPs, and collects statistics from the border routers in a distributed sense. Given the collected data, the victim can determine the ISPs that contain the possible locations of the attackers. The proof has justified the correctness of the algorithm, and the simulation results have demonstrated the robustness of the algorithm.
The probabilistic packet marking algorithm (PPM algorithm for short) is a prized traceback approach in terms of simplicity and effectiveness, and it is one of the best candidates for a microscopic traceback algorithm. Yet, algorithm this is a renowned traceback algorithm, the termination condition of the PPM algorithm is, however, seldom studied in the literature. Nevertheless, our finding has shown that the well-accepted termination condition of the PPM algorithm is not correct in general cases. Worse, the defective termination condition would lead to incorrect traceback results.
Having known that the traditional termination condition is defective, we provided a discrete-time Markov chain model that corrects the faults in the calculation of the traditional termination condition of the PPM algorithm. Nevertheless, the effort spent on correcting such a calculation is in vain. In order to have a precise calculation of the tradition termination condition, one has to know the paths taken by the attack traffic in advance. However, these paths are the results that the PPM algorithm aims to achieve. This contra- dicting condition led us to discontinue to follow the traditional termination condition of the PPM algorithm.
On the contrary, we introduced a new termination condition for the PPM algorithm, and based on the new termination condition, we devised the rectified probabilistic packet marking algorithm (RPPM algorithm for short). The most signification contribution of the RPPM algorithm is that when the algorithm terminates, the algorithm guarantees the traceback result with a specified level
of confidence. Our finding showed that the RPPM algorithm can provide such a guarantee under different deployment scenarios. In conclusion, the RPPM algorithm provides an autonomous way for the original PPM algorithm to determine its termination, and it is a promising means to enhance the reliability of the PPM algorithm.
Though the proposed solutions in the thesis are self-contained, there is room for future research. For both the distributed snapshot traceback algo- rithm and the RPPM (PPM) algorithm, they are prone to attacks caused by compromised border routers or fake request (or marker) packets. A tailor-made authentication protocol can be designed to resist the attacks, in a best-effort manner.
For the RPPM algorithm, the scalability problem is worth noticing. As mentioned in Section 5.8.3, when the scale of the real attack graph increases, the number of the marked packets required to have the correct constructed graph also increases. This prohibits the PPM algorithm to be deployed in a world-wide scale. One possible research direction is to devise a methodol- ogy to adaptively change the marking probability. This solution can minimize the number of packets required by cleverly changing the marking probability. Though it is believed that this approach would work mathematically, the pro- tocol for autonomously changing the marking probability may be difficult to formulate. Further research effort is required.
[1] F. Lau, S. H. Rubin, M. H. Smith, and L. Trajkovic, “Distributed Denial of Service Attacks,” in IEEE International Conference on Systems, Man, and Cybernetics, pp. 2275–2280, 2000.
[2] “Computer Emergency Response Team, CERT Advisory CA-2000- 01: Denial-of-Service Developments, http://www.cert.org/advisories/CA- 2000-01.html.”
[3] “Computer Emergency Response Team, CERT Advisory CA-1996-21: TCP SYN Flooding and IP Spoofing Attacks, http://www.cert.org/- advisories/CA-1996-21.html.”
[4] “DARPA Internet Program. RFC 793: Transmission Control Protocol,” Sept. 1981.
[5] J. Lemon, “Resisting SYN Flood DoS Attacks with a SYN Cache,” in Proceedings of BSDCON 2002, pp. 89–98, 2002.
[6] A. Kuzmanovic and E. W. Knightly, “Low-rate TCP-Targeted Denial of Service Attacks: the Shrew vs. the Mice and Elephants,” in Proceedings of ACM SIGCOMM 2003, pp. 75–86, 2003.
[7] H. Sun, J. C. S. Lui, and D. K. Y. Yau, “Distributed Mechanism in Detecting and Defending Against the Low-rate TCP Attack,” Computer Networks Journal, vol. 50, Sep 2006.
Conference on Network Protocols (ICNP), Berlin, Germany, 2004. [9] A. Shevtekar, K. Anantharam, and N. Ansari, “Low Rate TCP Denial-
of-Service Attack Detection at Edge Routers,” IEEE Communications Letters, vol. 9, pp. 262–265, April 2005.
[10] J. Elliott, “Distributed Denial of Service Attacks and the Zombie Ant Effect,” IT Professional, vol. 2, no. 2, pp. 55–57, 2000.
[11] R. Chang, “Defending against Flooding-based Distributed Denial-of- Service Attacks: a Tutorial,” IEEE Communications Magazine, vol. 40, no. 10, pp. 42–51, 2002.
[12] S. Dietrich, N. Long, and D. Dittrich, “Analyzing Distributed Denial of Service Tools: The Shaft Case,” in Proceedings of the 14th System Ad- ministration Conference, pp. 329–339, 2000.
[13] W. Lee and S. J. Stolfo, “A Framework for Constructing Features and Models for Intrusion Detection Systems,” ACM Transactions on Infor- mation and System Security (TISSEC), vol. 3, no. 4, pp. 227–261, 2000. [14] J. Beale, Snort 2.1 Intrusion Detection, Second Edition. Syngress, 2 ed.,
May 2004.
[15] V. Paxson, “An Analysis of Using Reflectors for Distributed Denial-of- Service Attacks,” ACM SIGCOMM Computer Communication Review, vol. 31, no. 3, pp. 38 – 47, 2001.
[16] N. Naoumov and K. Ross, “Exploiting P2P Systems for DDoS Attacks,” in Proceedings of the 1st International Conference on Scalable Information Systems. Article Number 47, 2006.
02 10 a.html,” 2000.
[18] D. Dittrich, “The DoS Project’s “Trinoo” Distributed Denial of Service Attack Tool. http://staff.washington.edu/dittrich/misc/trinoo.analysis,” 1999.
[19] D. Dittrich, “The “Stacheldraht” Distributed Denial of Service Attack
Tool. http://staff.washington.edu/dittrich/misc/stacheldraht.analysis,”
1999.
[20] C. C. Zou, W. Gong, and D. Towsley, “Code Red Worm Propagation Modeling and Analysis,” in Proceedings of the 9th ACM Conference on Computer and Communications Security, pp. 138–147, 2002.
[21] “Netcraft: Web Server Survey Archive. http://www.netcraft.com.” [22] D. Moore, V. Paxson, S. Savage, C. Shannon, S. Staniford, and N. Weaver,
“Inside the slammer worm,” IEEE Security and Privacy, vol. 1, no. 4, pp. 33–39, 2003.
[23] S. Adler, “The Slashdot Effect: an Analysis of Three Internet Publica- tions. http://ssadler.phy.bnl.gov/adler/SDE/SlashDotEffect.html,” 1999. [24] R. Mahajan, S. M. Bellovin, S. Floyd, J. Ioannidis, V. Paxson, and S. Shenker, “Controlling High Bandwidth Aggregates in the Network,” ACM SIGCOMM Computer Communication Review, vol. 32, pp. 62–73, Jul 2002.
[25] X. Chen and J. Heidemann, “Flash Crowd Mitigation via Adaptive Ad- mission Control based on Application-Level Observations,” ACM Trans- actions on Internet Technology (TOIT), vol. 5, no. 3, pp. 532–569, 2005.
vol. 34, no. 2, pp. 39 – 53, 2004.
[27] A. Hussain, J. Heidemann, and C. Papadopoulos, “A Framework for Clas- sifying Denial of Service Attacks,” in Proceedings of the 2003 conference on Applications, Technologies, Architectures, and Protocols for Computer Communications (SIGCOMM), pp. 99 – 110, 2003.
[28] D. Barry, “Proactive Protection: New techniques and best practices help service providers counter increase in cyber attacks,” Packet: Cisco Sys- tems Users Magazine, vol. 16, no. 1, pp. 64–68, 2004.
[29] T. Y. Wong, K. T. Law, J. C. S. Lui, and M. H. Wong, “An Efficient Dis- tributed Algorithm to Identify and Traceback DDoS Traffic,” The Com- puter Journal, vol. 49, no. 4, pp. 418–442, 2006.
[30] S. Savage, D. Wetherall, A. Karlin, and T. Anderson, “Practical Network Support for IP Traceback,” in Proceedings of the 2000 ACM SIGCOMM Conference, pp. 295–306, 2000.
[31] T. Y. Wong, J. C. S. Lui, and M. H. Wong, “Markov Chain Modeling of the Probabilistic Packet Marking Algorithm,” International Journal of Network Security, vol. 5, no. 1, pp. 32–40, 2007.
[32] T. Y. Wong, M. H. Wong, and J. C. S. Lui, “A Precise Termination Condition of the Probabilistic Packet Marking Algorithm,” Accepted by IEEE Transactions on Dependable and Secure Computing, August 2007. [33] E. Dijkstra and C. Scholten, “Termination detection for diffusing com-
putuations,” Information Processing Letter, vol. 11, pp. 1–4, Aug 1980.
vol. 3, pp. 63–75, Feb 1985.
[35] L. Lamport, “Time, Clocks, and the Ordering of Events in a Distributed System,” Communications of the ACM, vol. 21, pp. 558–565, Jul 1978. [36] M. J. Fischer, N. D. Griffeth, and N. A. Lynch, “Global States of a Dis-
tributed System,” IEEE Transactions on Software Engineering, vol. 8, no. 3, pp. 198–202, 1982.
[37] R. Koo and S. Toueg, “Checkpointing and Rollback-Recovery for Dis- tributed Systems,” IEEE Transactions on Software Engineering, vol. 13, no. 1, pp. 23–31, 1987.
[38] E. N. Elnozahy, L. Alvisi, Y. M. Wang, and D. B. Johnson, “A Survey of Rollback-Recovery Protocols in Message-Passing Systems,” ACM Com- puting Surveys, vol. 34, no. 3, pp. 375–408, 2002.
[39] P. A. Bernstein, V. Hadzilacos, and N. Goodman, Concurrency Control and Recovery in Database Systems. Addison-Wesley, 1987.
[40] S. Bellovin, “Security Problems in the TCP/IP Protocol Suite,” ACM Computer Communications Review, vol. 19, no. 2, pp. 32 – 48, 1989. [41] P. Ferguson and D. Senie, “RFC 2267: Network Ingress Filtering: Defeat-
ing Denial of Service Attacks which Employ IP Source Address Spoofing,” The Internet Society, January 1998.
[42] “Egress filtering v 0.2, global incident analysis center. http://- www.sans.org/y2k/egress.htm.”
Proceedings of ACM SIGCOMM 2001, pp. 15 – 26, 2001.
[44] D. K. Y. Yau, J. C. S. Lui, F. Liang, and Y. Yam, “Defending Against Distributed Denial-of-service Attacks with Max-min Fair Server-centric Router Throttles,” IEEE/ACM Transactions on Networking, vol. 13, no. 1, pp. 29–42, 2005.
[45] S. Chen and Q. Song, “Perimeter-Based Defense against High Bandwidth DDoS Attacks,” IEEE Transactions on Parallel and Distributed Systems, vol. 16, no. 6, pp. 526– 537, 2005.
[46] J. Xu and W. Lee, “Sustaining Availability of Web Services under Dis- tributed Denial of Service Attacks,” IEEE Transactions on Computers, vol. 52, no. 2, 2003.
[47] K. T. Law, J. C. S. Lui, and D. K. Y. Yau, “You Can Run, But You Can’t Hide: An Effective Methodology to Traceback DDoS Attackers,” IEEE Transactions on Parallel and Distributed Systems, vol. 15, no. 9, pp. 799 – 813, 2005.
[48] D. X. Song and A. Perrig, “Advanced and Authenticated Marking Schemes for IP Traceback,” in Proceedings of IEEE INFOCOM ’01, pp. 878–886, April 2001.
[49] K. Park and H. Lee., “On the Effectiveness of Probabilistic Packet Mark- ing for IP Traceback under Denial of Service Attack,” in Proceedings of IEEE INFOCOM ’01, pp. 338 – 347, 2001.
[50] D. Dean, M. Franklin, and A. Stubblefield, “An Algebraic Approach to IP Traceback,” in Proceedings of Network and Distributed System Security Symposium, NDSS ’01, February 2001.