Securing the calea architecture against denial of service attacks
Table Of Contents
- <p> </p><p><br> Page</p><p>ABSTRACT 3</p><p>ACKNOWLEDGEMENT 5</p><p>PERMISSION SHEET 6</p><p>APPROVAL SHEET 7</p><p>DECLARATION 8</p><p>LIST OF TABLES 9</p><p>LIST OF FIGURES 10</p><p>LIST OF ABBREVIATIONS/NOTATION/GLOSSARY OF TERMS 11</p><p><b>Chapter</b></p><p><b>1 INTRODUCTION- – – – – – – – – – – – – – – .12</b></p><p><b>2 LITRITURE REVIEW- – – – – – – – – – – – – – – 15</b></p><p>
- 2.1Call Data Channel(CDC) Resource Exhaustion- – – – – – – – – – 15</p><p>2.
- 1.1ISDN Feature Keys- – – – – – – – – – – – ..17</p><p>2.
- 1.2SMS Messaging – – – – – – – – – – – – – – 17</p><p>2.
- 1.3VoIP Signaling- – – – – – – – – – – – – – .18</p><p>2.
- 1.4IP Flow- – – – – – – – – – – – – – .19</p><p>
- 2.2Inbound Attacks- – – – – – – – – – – – – – .19</p><p>
- 2.3Injecting Uncertainty into Packet Traces- – – – – – – – – – – 19</p><p>2.
- 3.1Confusion- – – – – – – – – – – – – – – 19</p><p>2.
- 3.2Subject-Oriented cdma2000 Timestamps – – – – – – – – – – 20</p><p>2.
- 3.3Loss of cdam2000 Direction Information – – – – – – – – – – 20</p><p>
- 2.4In-band Signaling within Service Provider- – – – – – – – – – 20</p><p>
- 2.5Alternatives Methods to Secure the CALEA Architecture – – – – – – – 20</p><p>2.
- 5.1Passive Provisioning with DOW [method 1]- – – – – – – – – 21</p><p>2.
- 5.2CALEA Architecture with middleware Message Queue [method 2]- – – – – – 23</p><p>
- 2.6Chosen Solution: Split Huge File to Minimize Risk- – – – – – – – 24</p><p>
- 2.7Reasons for Chosen Solution over the Other Two Methods Designs- – – – – – 24</p><p><b>3 DESIGN- – – – – – – – – – – – – – – – 27</b></p><p><b>4 IMPLEMENTATION- – – – – – – – – – – – – – – .30</b></p><p>
- 4.1AF Simulator Setup- – – – – – – – – – – – – .31</p><p>
- 4.2DF Simulator Setup- – – – – – – – – – – – – .31</p><p>
- 4.3CF Simulator Setup- – – – – – – – – – – – – .32</p><p><b>5 TESTING AND ANALYSIS- – – – – – – – – – – – – – 34</b></p><p><b>6 CONCLUSION- – – – – – – – – – – – – – – – .41</b></p><p>Reference – – – – – – – – – – – – – – – – .42</p><p>Appendix A- – – – – – – – – – – – – – – – – 43</p><p>Appendix B – – – – – – – – – – – – – – – – – .48</p><p>Appendix C- – – – – – – – – – – – – – – – – 49</p> <br><p></p>
Project Abstract
<p> </p><p>Law Enforcement Agencies (LEA) around the world utilizes eavesdropping systems that are based on</p><p>the Communications Assistance for Law Enforcement Act (CALEA) architecture, which provides a</p><p>platform for transmitting and collecting these data for further analysis. Recent security analysis however</p><p>has revealed that CALEA is susceptible to Denial-of-Service (DoS) attacks, which could potentially</p><p>compromise the ability of the system to transmit, analyse and utilize the captured data in real time. The</p><p>primary reason for this is the limited transfer rate allocated for sending data obtained via eavesdropping.</p><p>The bandwidth can be easily overwhelmed by dummy messages if the transmission link is hijacked,</p><p>resulting in subsequent loss of real data being transmitted. This would be analogous to the SYN flood</p><p>attack observed in web servers.</p><p>This project proposes a solution to this issue, which involves splitting the original data to be transmitted</p><p>into smaller chunks prior to transmission. The motivation is to decrease the probability of packets</p><p>containing real data being lost when the bandwidth usage increases when a DOS attack is attempted.</p><p>Subsequently larger amount of real data arrives intact at the receiving end, which can then be gainfully</p><p>utilized. The process of distinguishing the fake from real messages could be achieved through some </p><p>appropriate pattern recognition and classification software, which however would be beyond the scope</p><p>of this project. The key activities in this project involve the design, implementation and test of the</p><p>performance aspects of the proposed solution to the DOS attack problem.</p><p>A brief overview of the CALEA architecture is provided, along with the various key modules that</p><p>comprise it. The current solution is proposed after an analysis of various alternatives. The primary</p><p>research methodology in this project concerns the design of the experimental tests for the proposed</p><p>solution, its implementation, execution, data gathering and subsequent analysis. The trial runs are</p><p>repeated for both wireless medium and wired medium in order to compare results. A limited transfer rate</p><p>link is used to simulate an overwhelmed link and the FTP protocol is used for the file transfer process. A</p><p>performance analysis is shown to indicate the amount of real data that would have been lost without the</p><p>use of the solution. A discussion about the strength and weakness of the solution is also provided, along</p><p>with avenues for future work. </p> <br><p></p>
Project Overview