Towards Secure SIP Signalling Service for VoIP applications

Size: px
Start display at page:

Download "Towards Secure SIP Signalling Service for VoIP applications"

Transcription

1 Ge Zhang Towards Secure SIP Signalling Service for VoIP applications Performance-related Attacks and Preventions Karlstad University Studies 2009:27

2 Ge Zhang. Towards Secure SIP Signalling Service for VoIP applications Performance-related Attacks and Preventions Licentiate thesis Karlstad University Studies 2009:27 ISBN ISSN c The author Distribution: Karlstad University Division for Faculty of Economy, Communication and IT Department of Department of Computer Science SE KARLSTAD SWEDEN Printed at: Universitetstryckeriet, Karlstad 2009

3 Know your enemy, know yourself and you can fight a hundred battles without disaster... All warfare is based on deception... The Art of War Sun Tzŭ

4

5 Towards Secure SIP Signalling Service for VoIP applications Performance-related Attacks and Preventions GE ZHANG Department of Computer Science, Karlstad University Abstract Current Voice over IP (VoIP) services are regarded less secure than the traditional public switched telephone network (PSTN). This is due to the fact that VoIP services are frequently deployed in an relatively open environment, so that VoIP infrastructures can be easily accessed by potential attackers. Furthermore, current VoIP services heavily rely on other public Internet infrastructures shared with other applications. Thus, the vulnerabilities of these Internet infrastructures can affect VoIP applications as well. Nevertheless, deployed in a closed environment with independent protocols, PSTN has never faced similar risks. The main goal of this licentiate thesis is the discussion of security issues of the Session Initiation Protocol (SIP), which serves as a signalling protocol for VoIP services. This work especially concentrates on the security risks of SIP related to performance. These risks can be exploited by attackers in two ways: either actively or passively. The throughput of a SIP proxy can be actively manipulated by attackers to reduce the availability of services. These attacks are defined as Denial of Service (DoS) attacks. On the other hand, attackers can also profile confidential information of services (e.g., the calling history) by passively observing the performance of a SIP proxy. This is defined as a timing attack. In this thesis, we carefully studied four concrete vulnerabilities existing in current SIP services, among which, three of them can lead to DoS attacks and one can be exploited by timing attacks. The results of our experiments demonstrate that these attacks can be launched easily in real applications. Moreover, this thesis discusses different countermeasure solutions for the attacks respectively. The defending solutions have all in common that they are influencing the performance, by either enhancing the performance of the victim during a DoS attack, or abating the performance to obscure the time characteristic for a timing attack. Finally, we carefully evaluated these solutions with theoretical analyses and concrete experiments. Keywords: Signalling attacks, Voice over IP, Session Initiation Protocol, network security, Denial of Service. i

6

7 Acknowledgments First of all, I would like to express my sincere gratitude to my supervisor, Prof. Simone Fischer-Hübner, for her advice, attention and encouragement during my research studies. I am also very grateful for the valuable research network shared by Prof. Fischer-Hübner. It is an honor to work under the direction of her. I believe that a nice work environment makes the greater part of a research experience and for this I would like to thank my colleagues in Computer Science Department at Karlstad University. Further, special appreciation is given to all members of the Privacy and Security Group (PRISEC). They are Prof. Simone Fischer-Hübner, Prof. Stefan Lindskog, Prof. Thijs J. Holleboom, Leonardo A. Martucci, Hans Hedbom, Reine Lundin and my co-advisor, Prof. Andreas J. Kassler. Also, thanks to the C-BIC project that funded part of my research work. I have had the good opportunities to work with several other research institutes before. My stay in Berlin at Fraunhofer FOKUS institute is a valuable experience because I started my first step of doing research work at there. My sincere thanks must go to Prof. Thomas Magedanz and Sven Ehlert for their offer and advice. My family have been always generous with their encouragement to me despite the long geographical distance between us. My deepest appreciation goes to my parents, Jinyi Zhang and Ming Qian. I am forever indebted to them for their endless love and support. Finally, I thank with love to my dear wife, Hui Xie. Without her love and understanding, it is impossible for me to accomplish this work. Karlstad, March 2009 Ge Zhang iii

8

9 List of Appended Papers This thesis is comprised of the following four peer-reviewed papers. References to the papers will be made using the Roman numbers associated with the papers such as Paper I. I. Ge Zhang, Sven Ehlert, Thomas Magedanz, and Dorgham Sisalem. Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding. In Proceedings of the 1 st international Conference on Principles, Systems and Applications of IP Telecommunications (IPTCOMM 2007). New York, NY, USA, July ACM Press. Part of this paper summarizes results reported in: Sven Ehlert, Ge Zhang, Dimitris Geneiatakis, Georgios Kambourakis, Tasos Dagiuklas, Ji rí Markl, and Dorgham Sisalem. Two layer Denial of Service prevention on SIP VoIP infrastructures. In Computer Communications, Elsevier, Vol. 31, Issue 10, June 2008, Pages II. Ge Zhang, Simone Fischer-Hübner, and Sven Ehlert. Blocking attacks on SIP VoIP proxies caused by external processing. In Special Issue on Secure Multimedia Services, Journal of Telecommunication Systems, Springer, to be published in III. Sven Ehlert, Ge Zhang, and Thomas Magedanz. Increasing SIP firewall performance by ruleset size limitation. In Proceedings of the IEEE 19 th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2008). Cannes, France, September IEEE Press. IV. Ge Zhang, Simone Fischer-Hübner, Leonardo A. Martucci, and Sven Ehlert. Revealing the calling history on SIP VoIP systems by timing attacks. In Proceedings of the 4 th International Conference on Availability, Reliability and Security (ARES 2009). Fukuoka, Japan, March IEEE Press. Some of the papers have been subjected to some minor editorial changes. Comments on my Participation For paper I, my major contributions include the testbed configuration, solution implementation, carrying out experiments and most of the written work of this paper. Sven Ehlert, Prof. Thomas Magedanz and Dr. Dorgham Sisalem provided this research topic with original ideas, revised my written material and supervised this work. Concerning paper II, Sven Ehlert proposed basic requirements of the VoIP firewall optimization. The detailed algorithm was a result of discussion between him and me. Further, I developed the proof-of-concept program and performed experiments to evaluate this algorithm. The first version of this paper was accomplished by me. Sven Ehlert also contributed his comments and revised this paper. This work was supervised by Prof. Magedanz as well. v

10 The main idea in Paper III, a timing attack aiming to disclose calling history of SIP domains, stems from the discussion from Prof. Simone Fischer-Hübner, Leonardo A. Martucci and me. In addition, I am responsible for design of the testbed, implementation of the prototypes and experiments. Finally, most parts of the written material was finished by me. Prof. Fischer-Hübner, Leonardo A. Martucci and Sven Ehlert contributed comments and suggestions. Regarding paper IV, I have contributed with ideas, implementations, experiments and most parts of the written material. Prof. Fischer-Hübner and Sven Ehlert offered their help on revising this paper. Other Papers Apart from the papers included in this thesis, I have also authored the following papers. 1. Ge Zhang, Feng Cheng, and Christoph Meinel. Towards secure mobile payment based on SIP. In Proceedings of the 15 th Annual IEEE international Conference and Workshop on the Engineering of Computer Based Systems (ECBS 2008). Belfast, Northern Ireland, UK, March 31 - April 04, IEEE Press. 2. Ge Zhang, Feng Cheng, and Christoph Meinel. SIMPA: A SIP-based mobile payment architecture. In Proceedings of the 7 th IEEE/ACIS international Conference on Computer and information Science (ICIS 2008). Portland, Oregon, USA, May IEEE Press. vi

11 CONTENTS Contents Abstract Acknowledgements List of Appended Papers i iii v Introductory Summary 1 1 Introduction 3 2 Background VoIP SIP Security requirements and mechanisms on SIP services Security requirements on SIP Classic attacks on SIP Security mechanisms in SIP-related RFC Research Issues Research questions Research methodology Related work 14 6 Contributions 16 7 Summary of Papers 17 8 Conclusions and Outlook 18 Paper I: Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding 25 1 Introduction Related Work Background Session Initiation Protocol Domain Names Service DNS Usage in SIP Infrastructures Scope of the Attack 31 vii

12 CONTENTS 4 Testbed Setup 33 5 DNS Attacks on SIP Proxies DNS and Synchronous SIP Servers DNS and Asynchronous SIP Servers Non-Blocking Cache Design The Principle of Cache Solution Implementation of Cache Solution Performance Evaluation of Cache Solution Cache Replacement Policies Evaluation Evaluation of the Cache Entry Numbers Conclusion and Future Work 47 Paper II: Blocking attacks on SIP VoIP proxies caused by external processing 51 1 Introduction 53 2 SIP-based VoIP 54 3 Related Work 56 4 Blocking Attacks 57 5 Two Attacking Examples Blocking Attack Using High-latency DNS Servers Blocking Attack Using High-latency Web Servers Preliminary Summary of Blocking Attacks Experiments Measurements of Latency in the Real World Test Bed Attack Tests Using a High-latency DNS Server Attack Tests Using a High-latency Web Server Defence Solutions Proxy-based Solutions Cache-based Solutions Solution Comparison Conclusion 80 Paper III: Increasing SIP firewall performance by ruleset size limitation 83 viii

13 CONTENTS 1 Introduction 85 2 Background Information Voice over IP with the Session Initiation Protocol Firewalls Problem Space and Scope 87 4 Firewall Ruleset Optimiser Algorithm Overview Algorithm Details Application Calculation with Real-Life Traffic Optimisation Related Works 97 7 Conclusion and Future Work 98 Paper IV: Revealing the calling history on SIP VoIP systems by timing attacks Introduction Voice over IP using SIP Timing Attack Threat model Attacking method Testbed Setup Testing and Testing Result Countermeasures Related Work Conclusion and future work 117 ix

14

15 Introductory Summary

16

17 1. Introduction 3 1 Introduction Voice has been transmitted over a long distance using the Public Switched Telephone Network (PSTN) for more than 100 years. However, with the rapid evolution of packetswitched network technology, consumers show substantial interests in transmitting voice over IP networks (VoIP) instead of PSTN in recent years. According to a marketing investigation in 2007 [1], there is already around 50% of all global telecommunication traffic is done over IP networks, and this will increase to 75% in a few years time. Another report [2] predicts that VoIP revenues are expected to double and to reach over $6bn by Sales of VoIP equipments are forecast to grow 25% a year over the same period. People are optimistic about the prospects of VoIP applications because the benefits of using VoIP, especially, low-cost and flexibility, are difficult to be achieved in PSTN [3]. Nevertheless, with existing weaknesses (e.g., security risks), it is unlikely for current VoIP to totally replace PSTN. Therefore, improving its security for VoIP is an important task and many research projects on VoIP security have been proposed [4 8]. Securing VoIP is not an easy task, as it needs efforts in several stages. One of the essential issues in VoIP security is protecting the signalling messages being exchanged between VoIP infrastructures. Signalling does not transfer voice packets, but is designed for establishing, controlling, modifying and terminating communications. The protection of signalling includes integrity and confidentiality of signalling messages as well as availability and confidentiality of signalling services [9]. Another core issue in VoIP security is protecting multimedia communications between endpoints, which is a separate topic from signalling security. It consists confidentiality, integrity and availability of multimedia communications. In this thesis, the scope of our research ONLY focuses on the security issues of SIP [10], a signalling protocol. The reasons that we are motivated to choose SIP security as our research field are represented as follows. Firstly, signalling plays a vital role in VoIP services. Threats posing in signalling services can lead to serious results (e.g., making the services unavailable [11], causing financial loss of the users [12] and disclosing the users private information [13]). Moreover, signalling also can help to establish a secure multimedia communication (e.g., voice) by assisting in the media key exchange [9]. It means that the security of multimedia communication depends on signalling as well. Secondly, SIP, regulated by the Internet Engineering Task Force (IETF) [14], has been selected as the signalling protocol in the Internet and next generation networks. It is also employed as a standard protocol for the IP Multimedia Subsystem (IMS) [15]. Last but not least, although a lot of security solutions and mechanisms were proposed for SIP recently, whether these solutions can be adopted by SIP service providers in the real world is questionable. However at least, there are a lot of open source software-based SIP components available for both SIP services and endpoints. Therefore, it has been feasible for us to implement the test environment to evaluate our ideas and hypothesis in practice. The objective of this thesis is to define and elaborate unexplored security risks in SIP

18 4 Introductory Summary networks, especially under the scenarios in which attackers can either actively manipulate or passively observe the performance of SIP proxies. We are also interested in finding out how easily these risks can be exploited by attackers in the real world, and in consequence, how high the risks are for SIP users. We furthermore aim at contributing several defending solutions to eliminate or minimize the impact caused by the risks. Finally, we would like to know which solution is the most practical and efficient. This licentiate thesis presents an introductory summary and a collection of four peerreviewed papers in the area of security in SIP signalling service that were either authored or co-authored by the writer of this thesis. The rest of the introductory summary is organized as follows. Section 2 presents the general background of current VoIP applications and SIP signalling protocol. Section 3 presents some general security considerations for SIP services. Further, Section 4 outlines the research questions of this thesis and the research methodologies that we applied. Related work to this research is outlined in Section 5, followed by a summary of our contributions in Section 6. Section 7 summarizes the contents of the four papers included in this thesis. Finally, Section 8 concludes the introductory summary with an outlook to future work in this direction. 2 Background The fundamental background of this thesis is represented in two parts: (1) the general concept of VoIP with its pros and cons; (2) SIP, a signalling protocol which is designed for VoIP applications. 2.1 VoIP VoIP is an innovative technology which enables its users to make calls through the existing packet-switched networks (e.g., the Internet) 1 instead of traditional PSTN networks. The concept of VoIP is based on the factor that packets running over an IP network can deliver different kinds of multimedia contents including text, pictures, audio and video. However, different to transferring packets for text and pictures, transferring audio packets poses a high requirements on the performance of networks. Suffered from performance issues (e.g., packet loss and jitter), the Internet in early stage cannot afford the VoIP applications. That is why although the concept of using computer networks to make cheap long-distance calls has been proposed for decades [16], commercial VoIP solutions were not widely accepted by users until the recent appearance of broad-bandwidth technologies. VoIP can be regarded as an alternative of PSTN to achieve the same function: making voice calls. Nevertheless, VoIP has its own advantages and disadvantages compared with PSTN. The advantages of VoIP can be summarized as follows: 1 VoIP can be deployed over the Internet, but the environment of VoIP is not limited only to the Internet.

19 2. Background 5 1. Low cost: The most distinctive advantages of VoIP is its low-cost. By allowing voice to be converted into packets and transported over existing packet-switched networks (e.g., Internet), the cost for building and operating telephony services is reduced considerably. Another reason for low-cost is due to the factor that VoIP terminals and servers can be software-based. Especially, there are a number of open source software products (e.g., kphone [17], kcall [18], X-Lite [19], SER [20], OpenSIPS [21], etc) developed for VoIP applications. Deploying these free software products on computers, instead of buying expensive PSTN equipment, saves money for both users and service providers. 2. More features: VoIP is based on data communication and the services are digital. Therefore it can provide more features than traditional PSTN services. For example, it is easy to integrate audio, video and applications together on VoIP platforms. Also, presence [22], a method to convey the ability and willingness of a user to communicate, has been already implemented in most commercial VoIP protocols. More features are still under development. However, as most PSTN infrastructures are implemented for specific purposes, it is difficult to realize flexible features in PSTN services. Still, there are several disadvantages when it comes to VoIP: 1. Security threats: VoIP infrastructures are deployed in an open network environment (e.g., the Internet) and sometimes, VoIP applications need support from external Internet infrastructures shared with other applications (e.g., DNS servers). Thus, it is easy for unauthorized users to access VoIP infrastructures over the Internet. Furthermore, the vulnerabilities of external Internet infrastructures can affect VoIP services as well. In comparison, within a closed network environment and independent infrastructures, the cost on intruding PSTN networks is higher than the cost on intruding VoIP networks. 2. Quality loss: There are many QoS issues experienced by VoIP that do not affect PSTN. Since PSTN infrastructures are independent and reserved for specific application, acceptable quality can be guaranteed for PSTN. Nevertheless, packet-switched networks (e.g., Internet) are designed for multiple purposes. Then the Internet traffic may surge from time to time. As a result, the QoS of VoIP cannot be assured, which leads to variable latencies and dropped packets occurring. As telephony services are time-sensitive, these quality problems become the most essential barrier for VoIP applications. This drawback will remain a major restraint until a successful QoS management mechanism can be available. Current standards for VoIP protocols and services are regulated by the Internet Engineering Task Force (IETF) [14]. There are three core protocols for VoIP: Session Initiation

20 6 Introductory Summary Protocol (SIP) [10], which is a signaling protocol aiming to establish or terminate a session between users; Session Description Protocol (SDP) [23], which is used to negotiate the types of media sessions that are going to be established; and also the Real-time Transport Protocol (RTP) [24], which is used to transmit media packets based on an established session between users. Readers please bear in mind that this thesis mostly focuses on the security and performance issues of SIP protocol, and not SDP or RTP protocols. Therefore, SIP will be generally introduced in the following section. 2.2 SIP SIP, developed by IETF, is a text-encoded protocol based on elements from the HTTP [25] and SMTP [26] protocols. The primary function of SIP is to establish or terminate a session between two or more endpoints, but it also contains other important functions such as notification for presence and short messaging services. Similar to users, SIP users are represented by means of Uniform Resource Identifier (URI) [27], a universal name with a pair of domain name and a user name registered for this domain, e.g., (sip:ge.zhang@kau.se). Most current SIP applications in the real world employ a client/server transaction model similar to HTTP. A SIP client generates SIP request messages and a SIP server responds by generating response messages. Six basic SIP request types are defined in RFC 3261 [10]: INVITE: Initiate a SIP transaction to setup a session. ACK: Acknowledgement of final response to INVITE. BYE: Terminate an undergoing session. CANCEL: Cancel an unfinished SIP transaction. REGISTER: Register a user to a SIP domain. OPTIONS: Query capabilities of SIP infrastructures. There are a lot of SIP response types, many of which are oriented from HTTP protocol. SIP response codes are divided into six classes, identified by the first digit of the code: 1xx: Provisional the request has been received but the processing is unfinished. 2xx: Success the request has been received and accepted. 3xx: Redirection the request should be delivered to another place. 4xx: Client error the request cannot be processed due to error in the request.

21 2. Background 7 Figure 1: An example of SIP INVITE request 5xx: Server error the request cannot be processed due to server s failure. 6xx: Global failure the request cannot be processed at any server. Both SIP requests and responses are following the message format with three elements: the first line, containing either a request method or a response code; headers, containing a list of message headers with values for SIP transaction; message payload, can be textbased content for different purpose (e.g., SDP payload). An example message for the SIP INVITE request is shown in Figure 2, indicating that a caller with URI sip:alice@kau.se wants to reach a callee sip:bob@iptel.org. Several message headers dedicated to routing purposes are explained as follows: To: indicates the URI of the message recipient. From: indicates the URI of the message originator. Via: indicates a list of all intermediate SIP hosts that this message has passed. Any host that forwards the message adds its own address to the Via field. It is used for routing purpose. Contact: indicates one or more SIP URIs of the originator by which the recipient can contact with the originator directly. They can be different from the one in the From header. Regarding the architecture, various network elements compose a SIP network, such as User Agents (UA), SIP servers and location servers. SIP UA: UA can be any device (e.g., computer, smart phone, etc) which connects to network to generate and receive SIP requests or responses.

22 8 Introductory Summary Figure 2: A general overview of SIP components and the working procedure SIP servers: There are three kinds of SIP servers including a SIP proxy, a redirect server and a register server. A SIP proxy forwards SIP requests and responses to UA or other servers. A redirect server receives a request and makes a redirection response message (3xx), indicating that this message should be delivered to another location. A registrar server receives REGISTER requests from SIP users and updates the users location information to location servers. Location servers: The location server is a database storing the users URIs linked with their uptodate IP addresses, presence, and other related information. The information is constantly updated or required by SIP servers using non-sip protocol. The procedure of SIP-based telephony calling setup is shown in Figure 1. There are two SIP users located in different domains in this scenario: Alice, a caller, is located in the domain kau.se and Bob, a callee, is located in iptel.org. Initially, Alice sends an INVITE request to one of the local proxies. This INVITE request indicates that she wants to talk with Bob at iptel.org. Then, the local proxy forwards this INVITE request to the remote proxy at iptel.org. The request is finally delivered to the UA of Bob. If Bob wants to accept the call, his UA will reply with a 200 OK response back through the proxies. After Alice has sent an ACK message to confirm the request, the signaling handshaking is accomplished. Thus, Alice and Bob will build a peer-to-peer media session in which they can talk with each other by means of exchanging voice packets. When Alice wants to tear down the conversation, her UA will send a BYE request to Bob, and Bob s UA will reply with a 200 OK response. Then the call is terminated. 3 Security requirements and mechanisms on SIP services Compared with the SS7 signalling protocol [28] used in PSTN network, SIP is applied in an open and insecure environment. Therefore, additional security enhancements for SIP

23 3. Security requirements and mechanisms on SIP services 9 are necessary. This section introduces basic security requirements and threats to SIP with its security mechanisms. 3.1 Security requirements on SIP The security requirements on SIP services are examined according to basic security components (confidentiality, integrity, availability) defined in [29]. Confidentiality: Confidentiality is the concealment of information or resources [29]. Confidentiality should be taken into account for both SIP messages and SIP services. When it comes to SIP messages, it requires that not only the SIP message payload (e.g., SDP content), but also related information in message headers (e.g., To and From headers) should be kept as a secret from unauthorized network intermediaries. Further, SIP service providers often wish to conceal their network configurations as well as stored information about users (e.g., calling history). Integrity: Integrity refers to the trustworthiness of data or resources, and it is usually phrased in terms of preventing improper or unauthorized changes [29]. There are two kinds of integrity: data integrity and origin integrity. Regarding SIP services, data integrity means that the content of SIP messages should not be modified by unauthorized intermediaries. Origin integrity means that the source of SIP messages should not be spoofed to be another one. Availability: Availability refers to the ability to use the information or resource as desired [29]. Considering the cost on infrastructures, it is unlikely for a SIP service provider to offer services with unlimited capacity. Similar to other online applications, SIP service providers deploy SIP servers by assuming a statistic model for the perspective usage. However, sophisticated attackers may manipulate their use to break the assumed statistic model on purpose. In this way, legal users may be unable to access the service which they should get. Availability aims at preventing that the statistical model is broken. 3.2 Classic attacks on SIP Classic attacks on SIP can be summarized as follows. Eavesdropping: Eavesdropping is a passive attack launched by network intermediaries to disclose the communication content of other users. It can be easily realized by using some packet capture tools (e.g., wireshark [30]). An attacker may eavesdrop signalling traffic for multiple purposes (e.g., getting credential of users).

24 10 Introductory Summary Figure 3: The HTTP Digest authentication adapted in SIP Replay: A replay attack refers to capturing one or more SIP messages and re-sending them again after a period of time. In consequence, it may enable unauthorized users to access SIP services by using identities or credentials of other users. A replay attack can also lead to financial loss of legal users, so called billing attack [12]. Message tampering: Message tampering indicates that an unauthorized intermediary alters relayed SIP messages during transmission. For example, given that Alice sends an INVITE request to call Bob, an intermediary can alter the first line and To header in the request to make Alice talk with another person instead of Bob. Identity spoofing: Spammers and attackers frequently use faked SIP identities in order to be untraceable. However, it is unlikely to deploy a global centralized accounting database for all SIP users from different domains. Thus, it is difficult for the callee s domain to authenticate the originator of a SIP message in an inter-domain context since the callee s domain may do not have the account information of the originator. In this way, spammers and attackers can easily send SIP messages with spoofed identities. Denial of Service: Denial of Service (DoS) aims at preventing legal users to access SIP services or at making the services temporarily unavailable. An attacker can mount DoS attacks on SIP services by depleting resources (e.g., CPU, memory and bandwidth) of corresponding SIP proxies [11]. As VoIP is time-sensitive, SIP services can be suffer more from DoS than other non-realtime services (e.g., ). 3.3 Security mechanisms in SIP-related RFC In RFC 3261 [10], RFC 3329 [31] and RFC 4474 [32], several security mechanisms are recommended to secure SIP services. These security mechanisms are summarized as follows: HTTP Digest authentication: HTTP Digest [33], a stateless, challenge-based mechanism, provides source authentication and anti-replay protection. It can be used for both proxy-to-user authentication and user-to-user authentication. An example of this mechanism is illustrated in Figure 3. The user first sends a INVITE request to a proxy. Then, the proxy responses with a 407 message containing a unique

25 3. Security requirements and mechanisms on SIP services 11 nonce (a random number). The user receives this message and generates a hash digest for the combination of the nonce and owned password. Thus, the user sends the INVITE request again including the generated hash digest. Since the secret knowledge (the nonce and user s password) is shared with the proxy, the hash digest can be re-generated by the proxy to authenticate the source of this request. It is difficult for an eavesdropper to capture the plain text of a password since only a hash digest is transmitted over the network. Furthermore, by hashing a password with a nonce, replay attack can be efficiently prevented. S/MIME: Both message integrity and confidentiality can be ensured by carrying S/MIME [34] bodies. A signature for part of the message will be generated and attached in order to ensure that the content is not modified during the transmission. Moreover, the message payload and some headers can be encrypted to protect against eavesdropping attacks. However, the integrity of some header fields, which are allowed to be modified by intermediaries (e.g., Via), cannot be protected by the signature. Similarly, the fields of some message headers for routing purpose (e.g., To, Via) must be keeping in plain text during transmission. TLS: Transport Layer Security (TLS) [35], working at the transportation layer, provides source authentication, message authentication and message confidentiality, based on a Public Key Infrastructure (PKI). There are three phrases to build a TLS connection between two end-points: First, two end-points negotiate for supported cryptographic algorithms. Second, two end-points exchange a symmetric key and authenticate each other. Finally, they communicate with each other using the symmetric key for encrypting messages. IPSec: IPSec [36] stands for IP Security, which is designed by IETF to provide security at the network layer using a collections of techniques (authentication header (AH), encryption security protocol (ESP) and internet key exchange (IKE)). AH provides cryptographic authentication to IP packets, while ESP offers security services including both authentication and confidentiality. IKE is employed for session key management. However, IPsec can only authenticate machines instead of SIP users. Inter-domain authentication: To prevent identity fraud problems, an inter-domain authentication has been proposed in RFC 4474 [32]. Its purpose is to authenticate the originator of an inter-domain SIP message. The method is shown in Figure 7. For each outgoing message to other domains, the SIP proxy in the caller s domain generates a hash digest for this message. The digest is signed by the caller s proxy with its private key. The generated signature is encoded in a new header field Identity added to the original SIP message. Furthermore, the SIP proxy attaches another new header field Identity-info, which contains the Uniform Resource Locator (URL) [37] where the certificate can be fetched from. Then, this SIP request is forwarded to the callee s domain. It is regulated that each certificate must be provided by its domain itself. That is, in a SIP message, the URL indicated in the Identity-info field and the

26 12 Introductory Summary Figure 4: The mechanism of inter-domain authentication for message source originator domain indicated in the From field should be matched. For each incoming message from other domains, the SIP proxy in the callee s domain first downloads the certificate according to the URL given in the Identity-info field. The public key extracted from the certificate is used to decrypt the signature contained in the Identity field. Then, a hash digest will be recomputed for the request. The result is used to be compared to the newly generated hash digest. The proxy will continue to process the message only if the two values are equal. This mechanism is recommended to be deployed in future SIP services to prevent SPAM [38]. 4 Research Issues In this section, three underlying research questions of this thesis are outlined. Corresponding methodologies applied to address these questions are listed as well. 4.1 Research questions Question 1: How can a potential attacker launch DoS attacks to actively decrease the performance of a SIP proxy by exploiting the vulnerabilities of VoIP deployment? This question is discussed in Paper I, II and III. These papers demonstrate three different methods which enable attackers to decrease the performance of a SIP proxy. These attacks have been explored both in theory and practice. The papers also address the serious consequences to which the vulnerabilities can lead. Question 2: How can an attacker passively observe the performance of a SIP proxy by a timing attack to profile confidential information of services (e.g., calling history)? This question is investigated in Paper IV, which introduces an attacking method to profile the calling history between two domains. This attacking method is a kind of

27 4. Research Issues 13 timing attacks in which attackers retrieve confidential information by observing and comparing the Round Trip Time (RTT) of their requests. The method in detail is discussed in Paper IV. Question 3: How can the consequences caused by these threats be minimized or prevented in practice? In this thesis, our goal is to help SIP service providers to offer SIP services in a more secure way. Therefore, it is necessary to provide practical solutions to eliminate the threats proposed in Question 1 and 2. To realize this goal, we design, discuss and evaluate solutions for each vulnerability in Paper I, II, III and IV respectively. 4.2 Research methodology The research conducted in this thesis follows the steps as suggested in [39]: ideas development, quantitative experiments and data analysis. And these steps are performed twice in each paper, once for evaluating the feasibility of the attacking methods and once for exploring effective countermeasure solutions. Below, we describe the research methodologies in detail to address the questions above. First research question: We investigated three unexplored vulnerabilities, which enable an attacker to manipulate the performance of a SIP proxy, to answer the first question. The three attacking methods are demonstrated in Paper I, II and III respectively. Firstly, we reviewed literatures including SIP specifications and other related papers (literature review). After discussion, we found several vulnerabilities that may enable an attacker to control the performance of a SIP proxy (hypothesis formulation). To validate our hypothesis, we adopted different designs to collect data. In paper I, we implemented an attacking tool with a testbed and performed experiments. The experiments are designed to compare the performance of a victim SIP proxy when it is under attack and without attack. We built the testbed for the experiments. The core of the testbed, a victim SIP proxy, is a real implementation connecting to the Internet. This method is defined in [40] as a measurement 1. Finally, we analyzed the measurement results and demonstrated the correlation between attacking and performance reducing (data analysis). In Paper II, we also followed the same research process in Paper I. In addition, we also employed inductive approach to propose a formalized model from two concrete attacking methods. According to [40], this method is defined as analytical modeling. We adopted both of them because using both measurement and analytical modeling is helpful to enhance the validation of results [40]. The vulnerability addressed in Paper III was found from the real SIP service running, then we collected the data measured from the SIP service providers directly. Second research question: In Paper IV, we firstly reviewed literatures including RFC 4474 [32] and papers about the timing attack [41, 42] (literature review). Then, we found 1 According to [40], there are mainly three evaluation techniques: Analytical modeling, simulation and measurement.

28 14 Introductory Summary out a vulnerability which can be used to mount the timing attack in SIP environment as well (hypothesis formulation). We proposed a mathematical model describing this attack (analytical modeling). Furthermore, we built a testbed in the laboratory environment and performed a measurement to collect data. Finally, we analyzed the measurement results and made a conclusion (data analysis). Third research question: We applied evaluation research method [39] for this question. Firstly, we enumerated possible defending solutions for the aforementioned threats. Secondly, we analyzed advantages and disadvantages of each solution theoretically. Then, we eliminated the solutions which were obviously inefficient or might cause further problems. Thirdly, the prototypes of the remaining solutions were developed and we deployed these solutions in the test environments. With these solution prototypes, we did measurements in Paper I, II and IV to evaluate their effectiveness. However, due to some constrains (e.g., to simulate attackers using different IP addresses), we only applied analytical modeling in Paper III to evaluate the solution at this moment. Finally, we compared these solutions based on the evaluation results. For legal and ethical considerations, we built our own SIP services as the attacking target instead of attacking the ones in the real world during all the experiments. Therefore, the damage and effect caused by attacks could be confined only in our laboratory environment. However, the SIP services built by us are based on the real implementations. In this way, our tests still have a high accuracy. 5 Related work There are many issues which can affect the performance of a SIP network. Nahum et al. [43] published their measurements on the throughput of a SIP proxy under different configurations (e.g., stateful or stateless, using TCP or UDP, with or without authentication). The result demonstrates that the throughput can be reduced more than 94% from the best case (stateless, using UDP, without authentication) to the worst case (stateful, using TCP, with authentication). Their result also shows that the request time increases with the raising of the calling rate on a SIP proxy. Kuthan [44] and Cortes et al. [45] investigated the performance of SIP proxies by introducing more variables. Kuthan proposed that identities parsing, memory management and thread contention are main factors impacting SIP proxy performance. Cortes et al. found that string handing and synchronous DNS requests also impact the performance of SIP proxies. Some research works have been done aiming to evaluate the performance impact of deploying security mechanism on SIP networks. Rebahi et al. [46] did a performance analysis of inter-domain authentication mechanism in SIP. They argued that RSA, the default cryptographic algorithm recommended in RFC 4474, brings too much overload to SIP proxies. Instead, their testing result shows that using Elliptic Curve algorithm can achieve a better performance. Similarly, Ranganathan et al. [47] investigated the performance overhead of deploying IPSec in SIP networks based

29 5. Related work 15 on simulation. They found that the most predominant effect on VoIP network performance is caused by the dynamic public key exchanging. Furthermore, Salsano et al. [48] explored the performance overhead by introducing HTTP digest authentication and TLS in SIP services (The performance can be decreased by around 30% by introducing authentication and TLS). In summary, their measure results revealed that the performance of a SIP proxy can be reduced considerably depending on different security parameters. However, their works are focused on performance only, and not on security. For instance, their work did not represent how a potential attacker can take advantage of the parameters to launch DoS attacks on SIP servers. Differently, our work aims to find the correlation between performance and security of SIP services. Furthermore, our work demonstrates how an attacker can exploit the performance overhead on SIP proxies to mount attacks in detail. Some research work of investigating DoS attacks on SIP VoIP are summarized in this paragraph. Sisalem et al. [11] investigated the issues of DoS attacks targeting SIP infrastructures. They developed a taxonomy of attacks by different exploitable resources, including CPU, memory and bandwidth, to reduce the performance of a victim SIP proxy. A stateful SIP proxy has to consume memory resources to keep the transaction states of unfinished SIP transactions. Therefore, stateful SIP proxies are especially vulnerable to INVITE flooding attack, in which an attacker floods SIP proxies with only INVITE messages to create a large number of broken transactions. Sengar et al. [49] proposed a machine learning method to distinguish legal against INVITE flooding attacks. Based on this method, they firstly characterized legal SIP traffic behavior by summarizing the normalize frequency of INVITE, 200 OK, ACK and BYE messages. Based on this benchmark, they can later detect the attacks by the abnormal frequency of the messages. Moreover, [50 52] proposed specification-based detection methods using SIP state machine models to counter INVITE flooding attacks. Conner et al. [53] proposed a ringing-based DoS attack to consume memory resources of stateful SIP proxies. Different to INVITE flooding, this attack exploits the potential long time 180 Ringing state. They also designed an algorithm to optimize the system. Our work is similar to theirs. However, we investigated the different DoS attacks on SIP proxies. We focus on the threats to SIP proxies caused by external infrastructures (e.g., DNS server, HTTP server, and firewall). Moreover, we proposed our countermeasure solutions that aim at enhancing the performance of a SIP proxy, and not at detecting the attacker. It means that our solutions are based on prevention, instead of detection. One of the benefits of prevention is that prevention can minimize the attacking impacts during the attacks. Therefore, the damage caused by attacks has been eliminated from the beginning, whereas, in most cases, detection works only after the damage actually happens. It is too late as the damage already occurs. To the best of our knowledge, the previous work on VoIP timing attacks, which enable attackers to disclose confidential information by observing the performance of services, is only proposed by Wang [54] and Chen [55] so far. Their papers proposed a method to reveal the identity of two parties of a specified communication. The attacker actively adds timing characteristics into a VoIP flow by altering the time intervals between voice

30 16 Introductory Summary packets and observing the characteristics on the other side of the communication. In this way, the attacker can profile who has called whom. In contrast, the timing attack proposed in our paper is much easier to be realized. There is no need for an attacker to manipulate the timing characteristic of voice packets. Instead, the attackers can just simply send SIP signalling requests and observe the response time of them. Moreover, we also addressed a countermeasure solution to eliminate the timing characteristic based on response delaying. 6 Contributions As VoIP is an emerging Internet application, security evaluation and enhancement of VoIP are necessary before it should be widely deployed in the real world. In contrast to previous work, we investigated some security risks related to the performance of SIP VoIP which have not been studied before. Furthermore, we found that the performance issues affect not only the availability, but also the confidentiality of SIP services. We also proposed novel countermeasure solutions. Below follows a summary of the main contributions of this thesis: We have investigated several threats in which an attacker can arbitrary affect the performance of a SIP proxy. Firstly, a sophisticated attacker can take advantage of the communication latency between a SIP proxy and other external infrastructures (e.g., DNS servers, Web servers) to decrease the throughput of the proxy (in Paper I and II). We named this type of attacks as blocking attacks and a formalized model of such blocking attacks was given in our work (in Paper II). Secondly, firewalls, which are generally deployed in front of SIP proxies, also have the possibility to be exploited to decrease the performance of SIP services (in Paper III). These threats on SIP have not been studied before. We have identified and analyzed a timing attack aiming at extracting the calling history between domains. An attacker can send to a victim proxy spoofed SIP requests and observe the Round Trip Time (RTT) between the request and its response. With caches widely deployed, the RTTs for recently contacted domain should be relatively lower. Thus, the calling history of a domain can be profiled by a comparison of RTTs. We named this a SIP timing attack in Paper IV, which has not been studied before. We proposed and discussed different countermeasure solutions for each vulnerability in Paper I, II, III and IV. To efficiently minimize the impact of attacks, our solutions are mostly based on prevention, instead of detection. The defending solutions prevent the threats by influencing the performance of a victim SIP proxy, either by enhancing the performance of the proxy during a DoS attack, or by abating the performance to obscure the time characteristic for a timing attack. The solutions are first compared with each other in a theoretical way. We also implemented prototypes of each solution and evaluated them in the testbeds.

31 7. Summary of Papers 17 7 Summary of Papers This section contains short summaries of the papers included in this thesis. Paper I Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding A simple yet effective DoS attack on SIP servers is to flood the server with requests including hard-to-resolve domain names. In this paper, we evaluate different possibilities to mitigate these effects and show that over-provisioning is not sufficient to handle such attacks. As a more effective approach we present a solution called unblocking cache. Based on various measurements conducted over the Internet we investigate the efficiency of the unblocking cache and compare its performance with different cache replacement policies applied. Paper II Blocking attacks on SIP VoIP proxies caused by external processing As VoIP applications become increasingly popular, they are more and more facing security challenges that have not been present in the traditional PSTN. One of the reasons is that VoIP applications rely heavily on external Internet-based infrastructures (e.g., DNS server, web server), so that vulnerabilities of these external infrastructures have an impact on the security of VoIP systems as well. This article presents a Denial of Service (DoS) attack on VoIP systems by exploiting long response times of external infrastructures. This attack can lead the whole VoIP system in a blocked state thus reducing the availability of its provided signalling services. The results of our experiments prove the feasibility of blocking attacks. Finally, we also discuss several defending methods and present an improved protection mechanism against blocking attacks. Paper III Increasing SIP firewall performance by ruleset size limitation To protect SIP communication networks from attacks, especially flooding attacks like DoS or message spam, Intrusion Detection Systems (IDS) are deployed at the ingress point of the network to filter potential malicious traffic. A key issue of IDS performance is the operation of its firewall to block malicious user requests. Depending on the complexity of the firewall ruleset, filtering performance of the IDS can decrease considerably during high-load flooding situations. In this paper we propose a scheme to increase IDS firewall performance by merging several similar rules into more general ones and ignoring lesser relevant rules to limit the number of firewall rules. We formalize a mathematical model to

32 18 Introductory Summary compute new firewall rules and show exemplary with traffic from SIP VoIP communication networks how the calculation can be performed. If applied to a VoIP IDS, the scheme can increase firewall throughput considerably, while retaining most of its effectiveness. Paper IV Revealing the calling history of SIP VoIP systems by timing attacks To provide high-level security assurance to SIP VoIP services, an inter-domain authentication mechanism is defined in RFC However, this mechanism introduces another vulnerability: a timing attack which can be used for effectively revealing the calling history of a group of VoIP users. The idea here is to exploit the certificate cache mechanisms supported by SIP VoIP infrastructures, in which the certificate from a caller s domain will be cached by the callee s proxy to accelerate subsequent requests. Therefore, SIP processing time varies depending whether the two domains had been into contact beforehand or not. The attacker can thus profile the calling history of a SIP domain by sending probing requests and observing the time required for processing. The result of our experiments demonstrates that this attack can be easily launched. We also discuss countermeasures to prevent such attacks. 8 Conclusions and Outlook In this thesis, we have elaborated some security risks for SIP services, particularly, raised by the performance of SIP proxies. Some of the main conclusions of this thesis are: Achieving security in VoIP is much more difficult than in traditional PSTN. VoIP infrastructures are deployed in a relatively open environment (e.g., the Internet). It is easy for potential attackers to access these infrastructures for launching attacks. In contrast, PSTN, a closed network using independent communication protocols, requires more cost for attackers to access. Moreover, since VoIP services heavily rely on assistance from external servers (e.g., DNS server, web server), the communication between VoIP servers and these external servers can be exploited to impact the confidentiality and availability of VoIP users. Such risks have never been reported in PSTN since it does not employs shared infrastructures. Cache-based solution for VoIP is a two-edged weapon. It is obvious that caching external information (DNS mapping, certificates) is helpful to enhance the performance of SIP services. In this way, solutions based on cache are designed to defend against Denial of Service attacks. Unfortunately, however, the performance unbalance caused by using caches can also be exploited by potential attackers to launch timing attacks to impact the confidentiality of services.

33 REFERENCES 19 Security products for VoIP should be designed taking efficiency into account. In contrast to other services (e.g., , web), VoIP is time-sensitive. Therefore, complicated and time consuming security mechanisms are not suitable to apply for VoIP. If a designer fails to consider efficiency, attackers can easily manipulate the performance of SIP services to lauch a Denial of Service attack. We have contributed with several countermeasures for the threats that had been explored. One of our future work will be the integration of these separated solutions into a single product. The challenge is that some solutions may conflict with others. For example, a SIP proxy equipped with a cache can achieve a better performance, but the cache may leak secret information. The problem of how to handle this paradox should be solved before integrating these solutions. Moreover, the solutions we investigated in this thesis are performance related, that is, the solutions for defending against attacks either by enhancing the performance of SIP proxies (for Denial of Service attack), or by reducing the performance of SIP proxies (for timing attack). These performance related solutions are however not capable to trace back the attackers. In the future work, we will also explore other defending alternatives, which enable SIP service providers to trace back the attacking source based on previous research in Intrusion Detection System (IDS). References [1] 2007 Global NGN IP VoIP - Analyses Statistics and Forecasts. marketresearch.com/product/display.asp?productid= &g=1, visited at 16th- Feb [2] IP phone revenues forecast to reach $6bn by /29/ip-phone-revenues-forecast-to-reach-6bn-by-2012/, visited at 16th-Feb [3] U. Varshney, A. Snow, M. McGivern, and C. Howard. Voice over IP. Commun. ACM, 45(1):89 96, [4] D. Butcher, X. Li, and J. Guo. Security challenge and defense in VoIP infrastructures. IEEE Transactions on Systems, Man, and Cybernetics, Part C: Applications and Reviews, 37(6): , [5] T.J. Walsh and D.R. Kuhn. Challenges in securing Voice over IP. Security & Privacy, IEEE, 3(3):44 49, [6] S. M. Bellovin, M. Blaze, and S. Landau. The real national-security needs for VoIP. Commun. ACM, 48(11):120, [7] D. C. Sicker and T. Lookabaugh. VoIP security: Not an afterthought. Queue, 2(6):56 64, 2004.

34 20 Introductory Summary [8] E. A. Blake. Network security: VoIP security on data network a guide. In InfoSecCD 07: Proceedings of the 4th annual conference on Information security curriculum development, pages 1 7, New York, NY, USA, ACM. [9] H. Sinnreich. Internet communications using SIP. Wiley, [10] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol, RFC [11] D. Sisalem, J. Kuthan, and S. Ehlert. Denial of service attacks targeting a SIP VoIP infrastructure: attack scenarios and prevention mechanisms. IEEE Network, 20(5):26 31, [12] R. Zhang, X. Wang, X. Yang, and X. Jiang. Billing attacks on SIP-based VoIP systems. In WOOT 07: Proceedings of the first USENIX workshop on Offensive Technologies, pages 1 8, Berkeley, CA, USA, USENIX Association. [13] C. Shen and H. Schulzrinne. A VoIP privacy mechanism and its application in VoIP peering for voice service provider topology and identity hiding. ArXiv e-prints, July [14] IETF. visited at 16th-Feb [15] G. Camarillo and M.A. García-Martín. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the cellular worlds ebook. John Wiley & Sons, [16] W. Remmele. Voice over IP: Potential - status - trends. In Interaktion im Web - Innovative Kommunikationsformen, Fachtagung und Kongreßdes German Chapter of the ACM, der Gesellschaft für Informatik (GI) sowie Fachbereich Mathematik und Informatik der Philipps-Universität Marburg/Lahn am, pages Teubner, [17] Kphone. visited at 16th-Feb [18] Kcall. visited at 16th-Feb [19] X-Lite. visited at 16th-Feb [20] SIP Express Router. visited at 16th-Sep [21] OpenSIPS. visited at 16th-Feb [22] J. Rosenberg. A presence event package for the Session Initiation Protocol (SIP), RFC [23] M. Handley and V. Jacobson. SDP: Session Description Protocol, RFC [24] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson. RTP: A transport protocol for real-time applications, RFC 3550.

35 REFERENCES 21 [25] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners- Lee. Hypertext Transfer Protocol HTTP/1.1, RFC [26] J. B. Postel. Simple Mail Transfer Protocol (SMTP), RFC 821. [27] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform Resource Identifier (URI): Generic syntax, RFC [28] D. Lee and J. Hewitt. Signalling System No. 7 (SS7/C7): Protocol, architecture, and services. Cisco Press, [29] M. Bishop. Introduction to computer security. Addison-Wesley, [30] Wireshark. visited at 16th-Feb [31] J. Arkko, V. Torvinen, G. Camarillo, A. Niemi, and T. Haukka. Security mechanism agreement for the Session Initiation Protocol (SIP), RFC [32] J. Peterson and C. Jennings. Enhancements for authenticated identity management in the Session Initiation Protocol (SIP), RFC [33] J. Franks, P. Hallam-Baker, J. Hostetler, S. Lawrence, P. Leach, A. Luotonen, and L. Stewart. HTTP authentication: Basic and digest access authentication, RFC [34] B. Ramsdell. Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1 message specification, RFC [35] T. Dierks and E. Rescorla. The Transport Layer Security (TLS) protocol version 1.2, RFC [36] S. Kent and R. Atkinson. Security architecture for the Internet Protocol, RFC [37] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform Resource Locators (URL), RFC [38] J. Rosenberg and C. Jennings. The Session Initiation Protocol (SIP) and Spam, RFC [39] C. Robson. Real world research. Blackwell Publishing, [40] R. Jain. The art of computer systems performance analysis: Techniques for experimental design, measurement, simulation, and modeling. Wiley- Interscience, [41] A. Bortz and D. Boneh. Exposing private information by timing web applications. In WWW 07: Proceedings of the 16th international conference on World Wide Web, pages , New York, NY, USA, ACM.

36 22 Introductory Summary [42] E. W. Felten and M. A. Schneider. Timing attacks on web privacy. In CCS 00: Proceedings of the 7th ACM conference on Computer and communications security, pages 25 32, New York, NY, USA, ACM. [43] E.M. Nahum, J. Tracey, and C.P. Wright. Evaluating SIP server performance. In SIG- METRICS 07: Proceedings of the 2007 ACM SIGMETRICS international conference on Measurement and modeling of computer systems, pages , New York, NY, USA, ACM. [44] J. Kuthan. Accelerating SIP, Documentation/Papers/SIP/Presentation/kuthan-Server.pdf, visited at 16th-Sep [45] M. Cortes, J. R. Ensor, and J. O. Esteban. On SIP performance. Bell Labs Technical Journal, Special Issue: Session Initiation Protocol, 9(3): , [46] Y. Rebahi, J.J. Pallares, T. M. Nguyen, S. Ehlert, G. Kovacs, and D. Sisalem. Performance analysis of identity management in the Session Initiation Protocol (SIP). In IEEE/ACS International Conference on Computer Systems and Applications, pages IEEE, [47] M. K. Ranganathan and L. Kilmartin. Performance analysis of secure session initiation protocol based VoIP networks. Computer Communications, 26(6), [48] S. Salsano, L. Veltri, and D. Papalilo. SIP security issues: The SIP authentication procedure and its processing load. IEEE Network, 16:38 44, [49] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. Fast detection of denial of service attacks on IP telephone. In 14th IEEE International Workshop on Quality of Service, New Haven, USA, June IEEE. [50] E. Y. Chen. Detecting DoS attacks on SIP system. In 1st IEEE Workshop on VoIP Management and Security, Vancouver, Canada, April IEEE. [51] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. VoIP intrusion detection through Interacting protocol state machines. In DSN 06: the International Conference on Dependable Systems and Networks, pages , Washington, USA, June IEEE Computer Society. [52] S. Ehlert, C. Wang, T. Magedanz, and D. Sisalem. Specification-based denial-ofservice detection for SIP Voice-over-IP networks. In 3rd International Conference on Internet Monitoring and Protection, Bucharest, Hungary, July IEEE. [53] W. Conner and K. Nahrstedt. Protecting SIP proxy servers from ringing-based denialof-service attacks. In the Tenth IEEE International Symposium on Multimedia (ISM), Berkeley, USA, December IEEE.

37 REFERENCES 23 [54] X. Wang, S. Chen, and S. Jajodia. Tracking anonymous peer-to-peer VoIP calls on the Internet. In CCS 05: Proceedings of the 12th ACM conference on Computer and communications security, pages 81 91, New York, NY, USA, ACM. [55] S. Chen, X. Wang, and S. Jajodia. On the anonymity and traceability of peer-to-peer VoIP calls. IEEE Network, 20(5):32 37, 2006.

38

39 Paper I Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding Reprinted from Proceedings of the 1 st international Conference on Principles, Systems and Applications of IP Telecommunications (IPTCOMM 2007), ACM Press New York, NY, USA, July 2007

40

41 Denial of Service Attack and Prevention on SIP VoIP Infrastructures Using DNS Flooding Ge Zhang, Sven Ehlert, Thomas Magedanz and Dorgham Sisalem {sven.ehlert, Abstract A simple yet effective Denial of Service (DoS) attack on SIP servers is to flood the server with requests addressed at hard-to-resolve domain names. In this paper we evaluate different possibilities to mitigate these effects and show that over-provisioning is not sufficient to handle such attacks. As a more effective approach we present a defending solution based on the usage of a non-blocking DNS cache. By various measurements conducted over the Internet, we investigate the efficiency of the cache solution and compare its performance with different caching replacement policies applied. 1 Introduction Denial of Service (DoS) attacks [1] aim at denying or degrading a legitimate user s access to a service or network resource, or at bringing down the servers offering such services. According to a 2004 CSI/FBI survey report 17% of respondents detected DoS attacks directed against them, with the respondents indicating that DoS was the most costly cyber attack for them, even before theft of proprietary information [2]. Security threats are considered minimal in current public switched telephony system (PSTN). This is achieved by using a closed networking environment dedicated to a single application (namely voice). In an open environment such as the Internet, mounting an attack on a telephony server is, however, much simpler. This is due to the fact that VoIP services are based on standardized and open technologies (i.e. SIP or H.323) using servers reachable through the Internet, implemented in software and provided often over general purpose computing hardware [3]. Hence, similar to any other Internet-based service, a special security concern is flooding with malicious or useless messages which can waste a considerable amount of resources of the SIP server. That is, instead of generating a multitude of costly voice calls as would be the case with PSTN, an attacker can easily send thousands of VoIP invitations. These attacks are simple to mount and with flat rate Internet access are inexpensive for the attacker.

42 28 Several possibilities exist for an attacker to cause a Denial of Service in a VoIP infrastructure [4]. Besides launching brute force attacks by generating a large number of useless VoIP calls, attackers can use certain features of the used VoIP protocol to incur higher loads at the servers. Further, the VoIP infrastructure can be corrupted by launching DoS attacks on components used by the protocols and layers on top of which the VoIP service is based such as routing protocols or TCP. In this paper we investigate a special DoS attack that is launched by utilizing the Domain Name Service (DNS), on which SIP heavily depends on, which we call a SIP DNS attack. We show that this attack is easy to launch and slows down message processing by a fair amount. We evaluate possibilities to mitigate effects of this attack and show that simply over-provisioning is not sufficient to counter the effects. We present a defending solution based on a non-blocking cache design and give results gained from testing with actual SIP providers. Within our defending solution we evaluate different caching strategies and show that the Least-Frequently-Used algorithm gives best results to mitigate the effects of this attack. This paper is organized as follows. In Sec. 2 we present an overview of the SIP signalling protocol and the special usage of DNS within SIP. In Sec. 3 we describe in detail the SIP DNS attack and demonstrate its effectiveness. In Sec. 4 we present our test bed, while in Sec. 5, we provide currently available solutions which can be deployed to counter this attack, and give an analysis of their feasibility and limitation. We outline our own solution and evaluate it based on our test bed in Sec. 6. Finally we summarize our work and suggest further steps in this research direction. 1.1 Related Work With the increased popularity of VoIP services, there has also been a considerable increase in the research work dedicated towards VoIP security. The research activities can be roughly divided in threat classification and threat detection. On the threat classification side, a number of papers [4] [5] and books [6] describe general attack scenarios on VoIP infrastructures and measures to secure these infrastructures. In [4] the authors describe a number of SIP specific attack possibilities. Both [4] and [5] describe the SIP DNS attack discussed in this paper but do not propose a solution for protecting SIP servers. On the DoS detection side, Geneiatakis et al. [7] propose a framework to defend against malformed SIP messages using a signature-based technique and dropping malformed messages. Chen [8] proposes a concept for detecting DoS Attacks on SIP systems using a SIP state machine model. The system is designed to detect unauthorized invalid message flooding. Sengar et al. [9] [10] devised a DoS detection mechanism based on statistical anomaly detection. Another online detection mechanism based on a Bayesian Model for SIP is proposed by Nassar et al. [11]. The system is able to detect different kinds of threats

43 2. Background 29 Figure 1: SIP Architecture Schematic Overview towards VoIP applications besides DoS, including SPIT and Password cracking. Attacks on the DNS system are not only applicable to VoIP infrastructures. A CERT report published in April 2000 [12] describes a DNS flooding attack based on bandwidth amplification targeted at DNS servers. Since recursive information may be attached to DNS replies, the packet size of DNS replies is usually much larger than that of DNS queries. Therefore, if DNS servers are flooded by queries containing a spoofed source, a large number of amplified DNS replies could be generated to exhaust the bandwidth of the spoofed victim host. Guo et al. [13] propose a mitigation method based on spoof detection. The method detects spoofed requests which cannot present a valid cookie. However, the DNS attack described in our work varies, as the attack is based on high DNS response times, not bandwidth amplification. 2 Background 2.1 Session Initiation Protocol The Session Initiation Protocol (SIP) [14] is ever more establishing itself as the standard for VoIP services in the Internet and next generation networks. A basic SIP infrastructure consists of several components (see Figure 1), including User Agents (UA) that generate or terminate SIP requests, Registrars, that bind the user s SIP address to a specific IP address and Proxies that forward requests in the SIP network. SIP is a text based protocol designed to establish or terminate a session between two partners. The message format is similar to the HTTP protocol [15], with message headers and corresponding values, e.g. From: user@sip.org to denote the sender of a message. The destination of a SIP messages (Request-URI) is provided in the first line of the message, the request line. Additionally, several other message headers such as Via, Route or To are dedicated to routing purposes in the network.

44 30 SIP is also the basic protocol of the next generation IP Multimedia Subsystem (IMS) [16]. 2.2 Domain Names Service The Domain Name Service (DNS) is the basis for most current internet services available today, including web and . It is a completely globally distributed and managed database, providing an essential service for Internet applications and users i.e. name resolution [17] [18], which is the mapping from human readable textual domain names (e.g. to a numerical IP address (e.g ). Whenever a user requests a domain resolve, there are generally two cases to distinguish: The DNS server knows the name mapping. The name server might know the mapping because it is the authoritative name server for this domain. As such, all mappings for the domain are preconfigured for this domain server. The server might also know the name because it has resolved this address previously. Generally, in this case the mapping is still stored in the server s internal cache. The DNS server does not know the name mapping. In this case the server will issue a recursive request to other name servers that might be able to provide an answer. The server will eventually receive a response, either containing the valid mapping or an error message that no mapping is possible. In the former case, the mapping will be stored in the server s internal cache for a limited period of time. The name server can also set a time limit for the query. If no answer is received within this limit, the address is considered unresolvable. In Figure 2, an example is given where an end user issues a DNS request of sip.iptel.org. The name server will execute a series of recursive requests until finding the authoritative server of this domain (iptel.org). Finally, the authoritative name server will reply with the IP address of sip.iptel.org. 2.3 DNS Usage in SIP Infrastructures The Domain Name Service plays a key role in every SIP network at three following aspects [19]. Many of the header fields in a SIP message contain Fully Qualified Domain Names (FQDN) that need to be resolved for further processing from a SIP entity. These headers include for example, Contact, Request-URI, Via and Route headers. To interconnect the Public Switched Telephone Network (PSTN) with a SIP network, ENUM telephone number mapping [20] [21] is used. In short, this allows the mapping of a PSTN telephone number (e.g ) to a valid SIP address.

45 3. Scope of the Attack 31 Figure 2: A procedure of DNS recursive request SIP can utilize different transport level protocols (e.g. UDP or TLS). To find its right contact server in regard to the used transport layer protocol, a SIP entity will issue a DNS SRV [22] request for the domain of the regarding SIP URI. The response will contain one or more destination hosts that provide the required service. In short, a SIP entity might query the DNS subsystem up to three times (ENUM mapping, server locations and address resolution) before it can actually process and forward a message. 3 Scope of the Attack The goal of a DoS attack is to render a SIP server inoperable for as long as possible. While the kind of attack we describe here can be launched at any kind of SIP entity (user agent, proxy, registrar, and redirect proxy), it is most effective against proxies or registrars/redirectors. In the following we will refer to these possible targets as SIP servers. While all kinds of SIP servers are affected by DNS attacks to some degree, such attacks are especially fatal for P-CSCFs in IMS networks and so called outbound proxies. In the context of IMS networks, a P-CSCF is responsible for receiving traffic from roaming users and forwarding it to the home domain of the users. While outbound proxies provide a similar functionality they are mainly used for NAT traversal reasons [14]. Whenever a SIP server encounters a fully qualified URI in a header field necessary for routing (e.g. Via or Route field), it issues a query to the local name server to receive a

46 32 Figure 3: Example SIP Message with hard-to-resolve URIs valid address mapping. On average it takes 1.3 DNS queries to receive an answer with the mean resolution latency less than 100 ms [23]. However, due to configuration errors, these numbers can be considerably higher [24]. The SIP DNS attack targets this relatively high requesting time. It is possible to disturb server operation with specially crafted SIP messages containing URIs that will cause an even higher processing time at the DNS server by using a URI in a routing header (Via, Route and To headers or in the Request-URI) of which the attacker is sure that its mapping will not be in the cache of a name server or will trigger a request to an authoritative name server that has a common low response time, e.g. because of low bandwidth connection. The former case is easy to generate by adding random host names to the left side of a address domain. The latter case can be discovered by an attacker by querying different name servers and measuring the response time. We define the domain names with high response time as hard-to-resolve domain names in this paper. An example for such a crafted SIP message see Figure 3. Such a message is a well formatted message that complies with the SIP standard in every respect and as such cannot easily be filtered out by a SIP server or an Intrusion Detection System [7]. Issuing SIP queries with a variation of such URI s will stop operation at a SIP server - depending on implementation and configuration - for a considerable time, as the SIP server can only continue its operation after having received an answer from the DNS server. A DNS proxy searches for a limited time for a name mapping. When using BIND DNS server [25] this value of the time out is set by default to 5 seconds. If it doesn t receive any answer from the BIND DNS server within the timeout period, a negative reply is generated. The whole processing of is shown in Figure 4. During the name resolve request, some of the SIP server resources will be blocked. Depending on the server s architecture this could be either memory (in form of state information) or CPU time (in form of a stopping process).

47 4. Testbed Setup 33 Figure 4: Attacking Scenario by blocking SIP proxy with messages containing hard-toresolve domain names with a default BIND DNS setup 4 Testbed Setup Within our testbed we show the effectiveness of the attack and evaluate countermeasures against it. The testbed consists of five main components. A SIP proxy as the main target of the attack. In the test scenario the attacked server acts as an outbound SIP proxy. Hence, all messages to or from a caller have to go though this proxy. We have used the SIP Express Router (SER) [26] for this task. SER is a SIP server which can act as SIP registrar, proxy or redirect server and is widely used by VoIP providers. A local DNS server. The SIP proxy is configured to contact this server for DNS requests. A self-implemented attack tool generating SIP messages containing hard-to-resolve domain names. This tool can continuously send SIP messages with different hard to resolve domain names to the proxy. User Agents (UA) representing legal users that register themselves on remote SIP servers. The UAs are realized using the SIPp message generating tool [27]. SIPp is a SIP protocol traffic generation tool and can send and reply to arbitrary SIP messages, such as INVITE, REGISTER in a specified time interval and with defined reply codes. We use SIPp to simulate regular SIP REGISTER traffic, consisting of REGISTER requests with different kinds of responses from remote servers. External SIP providers. We have chosen 100 different SIP providers from all over the world, mostly located in Europe and North America. The User Agents will be registered there. Every external SIP provider is located at a different domain.

48 34 Figure 5: Testbed architecture The testbed (Proxy, User Agent, and Attack tool) was established on a Pentium D double processor machines with 1 GB RAM running on Linux Operating System, equipped with 100 Mbps Internet access. The logical structure of test bed is shown in Figure 5. We have simulated the scenario with the following steps. The outbound SIP proxy can be configured to have different parallel processing queues n, with 2 n 64. We have configured our UA to send continuously REGISTER messages from our local network to external SIP proxies. The external SIP register address are given to the UA in textual representation, as such our proxy has to resolve the domain before it can forward any request. The attacking tool is configured to send crafted messages containing hard-to-resolve domain names to the local outgoing SIP proxy. It is configurable by the attacking interval i (in seconds) between two attacking messages. To measure the proxy performance, we send out 5000 register messages from the attack tool and count the number of responses (r) the local proxy can process. If we can get any kind of response from a remote SIP server, it means this message has successfully been processed by the proxy. Ideally, all 5000 messages can be processed at the local SIP server. 50 INVITE messages to different external SIP servers which are randomly chosen will be sent in 1 second and every outgoing message from the UA is routed through the local SIP proxy. Table 1 shows the variables of the experiment.

49 5. DNS Attacks on SIP Proxies 35 Table 1: Experiment Variables Variable description Variable symbol Parallel processing queues of the proxy under attack. n Time interval between two attacking messages sent from i the attacking tool to the local proxy. Number of reply messages received by the UA r All measurements reported in the paper are the average value of 10 runs of the tests. 5 DNS Attacks on SIP Proxies Commonly, the general rule of alleviating the impact from a DoS attack is to trace the source of the attack and block the traffic from it as close to the source as possible. However, it is difficult to apply this method on SIP network since the SIP protocol runs at the application layer [3], thus, back tracing will be very costly in this case. Instead, we focus on the DNS operation. The basic options for using DNS in a SIP proxy are either synchronous or asynchronous usage: Synchronous DNS implementation: In this case the SIP proxy sends a DNS request and waits for an answer. While waiting the process that has issued the request would be blocked and would not be able to process new requests. Asynchronous DNS implementation: In this case the SIP proxy would issue a DNS request and continue processing new requests. Once the reply to the DNS request arrives or a timeout expires the proxy would be notified. 5.1 DNS and Synchronous SIP Servers With a synchronous design, a SIP proxy would block in between sending the DNS request and receiving a reply to it. To reduce blocking effects, synchronous SIP proxies use parallel message processing by using multiple processes or threads with each process or thread responsible for processing one message synchronously. Such a design is depicted in Figure 6. Here a core part only acts as a message scheduler distributing incoming messages between the processes. Each process is then responsible for parsing the message, initiating any DNS requests or requesting the execution of an application and finally forwarding the message. State information can be shared among the processes using some form of shared memory.

50 36 Figure 6: Parallel process design of the SIP proxy To evaluate the performance of parallel processing under an attack, we perform an experiment based on our test bed with different parallel processing queues n and different attack intervals i. The result is shown in Figure 7. With few parallel processing queues (n < 8) less than 20% of all potential messages can be processed, even with only one attack message per second. 64 processing queues are needed to adequately cope with the same attack speed of one malicious message per second. However, decreasing the attacking interval down to seconds (1000 attack message per second), even 64 parallel processing queues are completely starved. Generating 1000 messages per second is easily achieved with a DDoS attack, where an attacker controls hundreds of slave machines [1]. For example, Hussain et al. demonstrated an attack scenario with 100,000 malicious messages per second [28]. With that setup, even a proxy with 64 or more processing queues would be totally blocked. On the other side, configuring even more parallel processes cost more memory and CPU resources, possibly leading to system overload and hence another type of DoS.

51 5. DNS Attacks on SIP Proxies n=2 n=4 n=8 n=16 n=32 n=64 number of messages replied attacking intervals (s) Figure 7: Processing performance of the local proxy for different processing queues n and varying attacking intervals i 5.2 DNS and Asynchronous SIP Servers Another option to design SIP servers is to use asynchronous processing. That is, after issuing a DNS request the server would not wait until an answer for the request was received but would queue the request in an event queue, save the data of the transaction, set the current operation on hold and move to processing the next request. When a reply for the request arrives the main process is notified and the waiting transaction is scheduled for continuation, thus eliminating a DNS blocking scenario. The procedure is shown as Figure 8. However, since the states of all unfinished domain name resolving requests need to be saved, the implementation complexity and memory requirements increase considerably. The server must support effective state suspend and resume capabilities, as each new DNS requests requires to completely storing the actual state into memory, and returning this state upon DNS resolve notification. We have found out that a SIP attack launched at a SIP proxy running on a machine with 8GB of RAM all memory can be depleted in about 30 seconds, resulting in a complete lock-down of the machine [29].

52 38 Figure 8: Procedure of asynchronous scaling design 6 Non-Blocking Cache Design From the results presented in the previous section it is obvious that neither synchronous nor asynchronous processing is sufficient to withstand a DNS attack. The source of the described attack is the usage of fully qualified domain name addresses (FQDN) in SIP messages. Hence, FQDN should not be used unless necessary. To reduce the need to resolve DNS names in Via headers, RFC 3261 [14] suggests that each proxy that receives a request adds a Received parameter to the Via entry of the request with the numeric IP address of the sending entity, thus eliminating the need to resolve this URI after receiving a reply. However, the effectiveness of this mechanism is rather limited to reducing the usage of DNS when routing replies and can not be used for other SIP headers such as the Request- URI or Route headers. Another approach for mitigating the effects of a DNS attack is to reduce the timeout value of DNS. While this would surely delay the collapse of the server it will not hinder it. In the following we describe a scheme that is based on caching the results of successful DNS queries. This scheme is implemented for a synchronous working server. The choice of the synchronous servers stems mainly to the higher vulnerability of such servers to DNS attacks and hence the higher need for effective prevention mechanisms.

53 6. Non-Blocking Cache Design The Principle of Cache Solution With the cache solution we aim at minimizing the time spent by a SIP server waiting for a DNS reply. With this in mind, the SIP server is extended with a DNS cache. Whenever the SIP server requires the resolution of a DNS name it first checks if the name already exists in the DNS cache. If yes then it uses the caches information otherwise it issues a DNS request and caches the DNS reply with its TTL (Time to Live). According to the SIP environment, only successfully resolved A and SRV records will be cached. The records will remain in cache until their TTL expire or the capacity of cache is exceeded. While different operating systems already provide DNS caches, they lack dedicated features for optimal usage in a SIP network. As described, a SIP entity uses additional DNS records to locate other proxies, including NAPTR / SRV records [19], while a general operation system DNS cache does not consider such records for caching. Furthermore, a dedicated SIP DNS cache might need a different replacement policy than a general usage cache. To ensure that a SIP server continues functioning even under a DNS attack, we define a blocking threshold. This threshold represents a certain parameter in the SIP server. Once the value of this parameter is above the blocking threshold, the SIP server stops issuing new DNS requests and relies solely on the content of the DNS cache for resolving DNS names. Hence, in this case, the SIP server will only be able to serve requests that contain already known DNS names. While this presents a limitation on the server s performance, it does ensure that under a DNS attack, the SIP server will continue to serve running sessions and new sessions destined to popular VoIP providers which are very likely to be cached. This threshold can be defined as follows: Assume a SIP proxy S processing messages in a synchronous manner, with n parallel processes as described in section 5.1. We define: 1, Process queue q is waiting for a DNS response at time t, S q (t) = 0, Otherwise (1) We also define H as an indicator how many processes are concurrently resolving a domain name in time t, with H = n S q (t) (2) q=1 Hence the proxy will absolutely be blocked when H = n. To guarantee non blocking proxy operation, the following relation has to be met: H < n at any time t. To achieve this we define a minimum operation threshold m, where m is reasonably small and m < n. While H < R, where R = n m, the SIP server will function normally and issue a DNS request for each hard-to-resolve DNS name. Further, the SIP server will cache the results

54 40 of successful DNS queries. Whenever H R, the proxy is informed that further DNS resolve request will have a high possibility to cause a DoS due to proxy blocking. As a consequence, the proxy will not try to resolve any domain names that are not included in the cache. Instead, the proxy assumes these addresses to be hard-to-resolve, and continues its operation. As soon as H < R, the proxy will again perform DNS lookups. For the case of a SIP server designed to process messages in an asynchronous manner (see Sec. 5.2), the blocking threshold (R) could represent a percentage of the memory used by the server. Hence, once the percentage of the memory used by the server (H) exceeds a certain percentage of the overall available memory (R) to the server, the same behavior as described above will be used. Combining the blocking threshold with a dedicated SIP DNS cache will effectively counter DNS attacks while keeping negative side effects on regular users to a minimum: As long as H < R there should be no visible effect on regular users. In case of an ongoing attack, many regular users won t be affected: Current connections will be kept, REGISTER updates are executed without delay. Also, often new requests could still be served as long as the destination address is available in the cache. Only requests to destinations not currently in the cache will be dropped. These requests can not be handled at the moment. As a result, this solution allows reduced operability under attack conditions. The amount of negative side effects on regular users mainly depends on the implementation of the caching replacement policy. 6.2 Implementation of Cache Solution To test the feasibility of such a design, we have implemented a prototype which operates with SER. The extensions to the SER support: An emergency process, which will only look up DNS records internally instead of forwarding requests to external DNS servers whenever H n 1. In a pretest, we found that m didn t affect the performance of the cache. Therefore, in the experiment, we set m constantly to 1. See from Figure 9, the cache could handle n request in the same time while mostly, only n 1 requests could be forwarded to an external DNS server. Caching both regular DNS entries (DNS A records) and DNS SRV records.

55 6. Non-Blocking Cache Design 41 Figure 9: An overview of the Cache solution Different cache replacement policies such as first in first out (FIFO), least recently used (LRU), least frequently used (LFU) and Time Cost (TC) to replace old records [30] [31] which we will examine further on. 6.3 Performance Evaluation of Cache Solution In order to verify the efficiency of the cache solution, we ve run several endurance tests. In these tests 10,000 SIP REGISTER messages were sent over a period of 140 seconds. Readers please bear in mind that all these messages contained hard-to-resolve domain names and the sending rate in this scenario is 100 messages/s. We measured the number of messages the proxy could process during this test. In the optimum case, all 10,000 messages should be handled by the proxy. In case of an attack however, the proxy will not be able to process all messages within time without dropping some. Figure 10 shows the number of replied messages over time at the SIP proxy (n=2, 4, 16, 32, 64, 128, 256) without a DNS cache, and also with the cache applied (n=2 only). Every test case was run for about 120 seconds. To make the figures more clear, we set that one point indicates 1 replied message in Figure 10(a) and one point indicates 10 replied messages in Figure 10(b). Looking at Figure 10, we can see that overall performance depends on the number of available processes for the uncached setup; with n = 256 showing the best results with about 4300 of the 10,000 messages processed. This value goes down to 50 successfully processed messages with n = 2. Hence, even with 256 processes, the performance of the proxy is still very limited in case of an attack. After deploying our cache solution the proxy answers nearly all 10,000 requests. We further found out that the result is independent of the number of activated processing queues n. Furthermore, we can also see from the picture that without deploying the cache, the SIP server would stop working for several seconds during the test run, e.g. at 90s < t < 110s with n = 16. During this time the proxy is blocked completely, as all 16 queues are waiting for a response from the DNS server. When the cache solution is used, the SIP server is still

56 n=2 n=4 n=16 n= number of replied messages elapsed time (s) (a) n = 2, 4, 16, 32, one point indicates 1 replied message n=64 n=128 n=256 n=2, with cache 8000 number of replied messages elapsed time (s) (b) n = 2 (with cache), 64, 128, 256, one point indicates 10 replied messages Figure 10: Message processing capabilities. The more parallel queues n are configured, the more messages can be processed during an attack. With the DNS cache implementation nearly all messages can be processed independently of n.

57 6. Non-Blocking Cache Design 43 Table 2: Different Caching replacement policies Name Primary key First In First Out (FIFO) Entry time of object in cache Least Recently Used (LRU) Time since last access Least Frequently Used (LFU) Frequency of access Time Cost (TC) Time consuming for request functioning and can continue serving running sessions as well as new sessions destined to cached destination. 6.4 Cache Replacement Policies Evaluation The efficiency of a cache is usually measured by its hit rate. A high hit rate indicates that the cache contains a high percentage of the entries the SIP server is trying to resolve. The hit rate is mainly influenced by the number of entries in the cache. The higher this number, the lower the probability of a cache miss and the higher the hit rate. However, the size of the cache will have to be limited. Otherwise, an attacker might deplete the system s memory by issuing a large number of DNS requests and hence continuously increasing the size of the cache. Once the cache is filled some existing cache entry will have to be deleted whenever a new entry is to be added. Within our solution we only employed positive cache to cache the names with successful results. If we also employed negative cache to cache failed results, this could lead to a direct DoS situation on the cache with the described attack, as the cache would endlessly be flooded by hard-to-resolve entries. We consider four cache update policies; First In First Out (FIFO), Least Recently Used (LRU), Least Frequently Used (LFU) are well-known cache replacement strategies for paging and web scenarios [30] [31]. Considering that the time cost of looking up different domain names maybe different, we consider also a Time Cost (TC) strategy (see Table 2). Generally, all replacement strategies are applied on a queue of cache entries. The newest record is inserted into the head of the cache queue, while entries are deleted from the tail of the cache queue when the size of the cache storage is exceeded. For the FIFO policy, except for newest and oldest entities, all records will be moved towards the tail by one when a new record enters the queue. LRU policy is similar to FIFO, with the difference that whenever one record within the cache is accessed, it will be moved directly to the head of the queue.

58 44 With LFU policy the DNS records are arranged by the frequency of their usage of DNS records. The higher the frequency, the closer are the entries located toward the head of the queue. With TC policy the queue is ordered by the time cost of the DNS lookup time of an entry. The goal is to keep entry with a higher lookup time available in the cache. The higher the lookup time cost of en entry, the closer it is to the head of the queue. We repeated the experiment from Sec. 5.1 with these four caching strategies twice, one time with n = 4 parallel processing queues at the proxy and then again with n = 32. With a test run we have found out that within our experiment we will need e = 270 entries in our DNS cache to hold all domain names of the 100 contacted SIP proxies. The reason for this higher number is that sometimes root name servers have to be contacted first before the actual proxy name can be resolved. (e.g. ns2.mydyndns.org will be contacted automatically before looking up iptel.org). Cache replacement strategies can only be tested if the number of possible entries is lower than the total number looked up in the experiment. While 270 entries for our test bed will require only a small memory overhead, in a real-life scenario the size have to be considerably higher. To compare the effectiveness of the replacement strategies we arbitrarily set the entry number of our cache (e) to 80 which is reasonably lower than the possible 270 entries. The result can be seen in Figure 11. Figure 11(a) shows the performance of the different caching strategies for n = 4 in case of an attack. We can see clearly that DNS caching with any caching strategy yields better performance than without DNS caching. The improvements vary depending on the attack interval and the used replacement policy, with Least Frequently Used (LFU) algorithm giving best results, which confirms to other performance tests with different setups [32]. The figure shows for LFU from 17% successful responses out of 5000 (at i=0.1 s) up to 61% successful responses (i=1 s). In comparison, figures for the uncached experiment are from 0.4% (i=0.1 s) up to 6% (i=1 s). In Figure 11(b), showing n = 32, we can see a different result. Especially from attacking interval i 0.5 s, the performance of all four algorithms are generally equal. This seems to be due to the increased processing capabilities of the proxy with n = 32, as also in the uncached experiment we see a clear increase in successful resolve requests. In this case, the attack simply does not consist of enough messages to slow down the proxy. However, with increased attack speed again LFU shows best results. We measure 44% successful responses (i=0.1 s) up to nearly 100% successful responses (i = 1 s), in comparison to 6% (i = 0.1 s) / 60% (i = 1 s) for the uncached experiment. Furthermore, we have further increased the attacking speed to 0.02s, which totally blocks the proxy without cache (0% successful responses). In contrast, with the assistance of the LFU cache the proxy still manages to process 1936 (38%) messages.

59 6. Non-Blocking Cache Design "No cache" "FIFO" "LRU" "LFU" "Time cost" number of replied messages attacking intervals (s) (a) proxy with 4 parallel processes "No cache" "FIFO" "LRU" "LFU" "Time cost" number of replied messages attacking intervals (s) (b) proxy with 32 parallel processes Figure 11: Performance of SIP proxies equipped with different cache replacement policies and number of parallel processes when the proxies are under attack

60 with cache (LFU) without cache 4000 number of replied messages number of cache entries Figure 12: Performance of proxy with different number of cache entries under attack 6.5 Evaluation of the Cache Entry Numbers In the last experiment, we survey the relationship of caching performance in relation to caching entries e. As we mentioned before, the number of cache entries is limited while the amount of the domain names in the real world is almost unlimited so that it an attempt to accommodate all possible domain names in the world will lead to a out-of-memory lockdown. To investigate how the number of cache entries will affect the performance of caches, we set n = 4 and the attacking interval i = 0.5 s, and evaluate with different number of cache entry based on the test bed. The result is shown in Figure 12. From Figure 12, we can see that when even if there were only 5 entries in the cache (minimum value measured in the experiment), the proxy still processes more messages than without a cache. The more cache entries there are, the better the performance of the proxy. When the number of cache entries is less than 150, the number of replied messages grows sharply with the increasing of cache entries while the growth becomes negligible when the number of cache entries is among 150 and 270. Finally, the curve reaches a steady state when the cache owns more than 270 entries, which matches the 270 different domain names involve in the test. Furthermore, we also set cache entries number to 500, 600 until 2000, however, no difference to e = 270 have been detected.

61 REFERENCES 47 7 Conclusion and Future Work Denial of Service attacks can limit SIP server operation to a large amount. In this paper we have evaluated attacks on SIP servers that utilize hard-to-resolve DNS names in SIP messages. Such attacks might be interesting for malicious users, as such SIP messages can easily be crafted and already a low amount of such message can reduce server operation by far. Our tests also show that over-provisioning the servers with massive parallel operation and asynchronous DNS lookup capabilities as well as reducing the usage of DNS names in the SIP messages can not successfully counter such attacks. That is while such measures can improve the performance under attack a severe attack will also manage to block the server at some point. By combining DNS caching with a blocking threshold after which no new DNS requests are issues, we have shown that a SIP server can continue working even under a heavy attack. This threshold can be either the percentage of blocked process in a SIP server designed to process messages in a synchronous manner. For servers processing messages in an asynchronous manner this threshold could represent the percentage of used memory. Finally, in case the used cache can not accommodate all possible DNS names, our experiments suggest that using a least frequently used replacement strategy for the cache has resulted in the highest hit rate. In the future we plan to evaluate how the cache solution works when this attack is combined with another common DNS related attack, called DNS cache poisoning [33]. Also, figures from a higher sized network than the 100 proxies used in this experiment could lead to more accurate predictions regarding real-life traffic. We plan to use virtualization techniques to acquire such figures. References [1] J. Mirkovic, S. Dietrich, D. Dittrich, and P. Reiher. Internet Denial of Service: Attack and Defense Mechanisms. Prentice Hall, United States, [2] L. Gordon, M. Loeb, W. Lucyshyn, and R. Richardson. CSI/FBI Computer Crime and Security Survey. Computer Security Institute, [3] F. Cao and S. Malik. Security analysis and solutions for deploying IP telephony in the critical infrastructure. In Workshop of the 1st International Conference on Security and Privacy for Emerging Areas in Communication Networks. IEEE, September [4] D. Sisalem, J. Kuthan, and S. Ehlert. Denial of service attacks targeting a SIP VoIP infrastructure: attack scenarios and prevention mechanisms. IEEE Network, 20(5):26 31, 2006.

62 48 [5] D. R. Kuhn, T. J.Walsh, and S. Fries. Security considerations for Voice over IP systems. In Recommendations of the National Insititute of Standards and Technology, January [6] A. Johnston and D. Piscitello. Understanding Voice over IP Security. Artech House Publishers, June [7] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, C. Lambrinoudakis, S. Gritzalis, S. Ehlert, and D. Sisalem. Survey of security vulnerabilities in session initiation protocol. Communications Surveys & Tutorials, IEEE, 8(3):68 81, [8] E. Y. Chen. Detecting DoS Attacks on SIP System. In 1st IEEE Workshop on VoIP Management and Security, Vancouver, Canada, April IEEE. [9] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. Fast detection of denial of service attacks on IP telephone. In 14th IEEE International Workshop on Quality of Service, New Haven, USA, June IEEE. [10] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. VoIP intrusion detection through interacting protocol state machines. In DSN 06: the International Conference on Dependable Systems and Networks, June. [11] M. Nassar, R. State, and O. Festor. Intrusion detection mechanisms for VoIP applications. CoRR, abs/cs/ , [12] CERT. Denial of Service Attacks using Nameservers, notes/in html, visited at 16th-Sep [13] F. Guo, J. Chen, and T. Chiueh. Spoof detection for preventing DoS attacks against DNS servers. In ICDCS 06: Proceedings of the 26th IEEE International Conference on Distributed Computing Systems, page 37, Washington, DC, USA, IEEE Computer Society. [14] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session Initiation Protocol, RFC [15] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners- Lee. Hypertext transfer protocol HTTP/1.1, RFC [16] G. Camarillo and M. A. García-Martín. The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds ebook. John Wiley & Sons, [17] P. V. Mockapetris. Domain names - conceptes and facilities, RFC [18] P. V. Mockapetris. Domain names - implementation and specification, RFC 1035.

63 REFERENCES 49 [19] J. Rosenberg and H. Schulzrinne. Session Initiation Protocol (SIP): locating SIP servers, RFC [20] J. Peterson, H. Liu, J. Yu, and B. Campbell. Using E.164 numbers with the Session Initiation Protocol (SIP), RFC3824. [21] P. Faltstrom and M. Mealling. The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM), RFC [22] A. Gulbrandsen, P. Vixie, and L. Esibov. A DNS RR for specifying the location of services (DNS SRV), RFC2782. [23] J. Jung, M. Sit, H. Balakrishnan, and R. Morris. DNS performance and the effectiveness of caching. IEEE/ACM Trans. Netw., 10(5): , [24] V. Pappas, Z. Xu, S. Lu, D. Massey, A. Terzis, and L. Zhang. Impact of configuration errors on DNS robustness. In SIGCOMM 04: Proceedings of the 2004 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM. [25] C. Liu and P. Albitz. DNS and BIND. O Reilly, [26] SIP Express Router (SER). visited at 16th-Sep [27] SIPp. visited at 16th-Sep [28] A. Hussain, J. Heidemann, and C. Papadopoulos. A framework for classifying denial of service attacks. In SIGCOMM 03: Proceedings of the 2003 conference on Applications, technologies, architectures, and protocols for computer communications, pages , New York, NY, USA, ACM. [29] Technical Report SNOCER-D2.2:. General reliability and security framework for voip infrastructures. [30] A. Silberschatz, P. B. Galvin, and G. Gagne. Operating system concepts. John Wiley & Sons, [31] C. C. Aggarwal, J. L. Wolf, and P. S. Yu. Caching on the world wide web. IEEE transaction on Knowledge and Data Engineering, 11(1):95 107, [32] U. Chejara, H. K. Chai,, and H. Cho. Performance comparison of different cachepeplacement policies for video distribution in CDN. In 7th IEEE International Conference on High Speed Networks and Multimedia Communications. IEEE, [33] J. Stewart, DNS cache poisoning - the next generation, Technical report, http: // visited at 4th-Nov-2008.

64

65 Paper II Blocking attacks on SIP VoIP proxies caused by external processing To be published Special Issue on Secure Multimedia Services of Journal of Telecommunication Systems Springer, 2009

66

67 Blocking attacks on SIP VoIP proxies caused by external processing Ge Zhang, Simone Fischer-Hübner, and Sven Ehlert {ge.zhang, Abstract As Voice over IP (VoIP) applications become increasingly popular, they are more and more facing security challenges that have not been present in the traditional Public Switched Telephone Network (PSTN). One of the reasons is that VoIP applications rely heavily on external Internet-based infrastructures (e.g., DNS server, web server), so that vulnerabilities of these external infrastructures have an impact on the security of VoIP systems as well. This article presents a Denial of Service (DoS) attack on VoIP systems by exploiting long response times of external infrastructures. This attack can lead the whole VoIP system in a blocked state thus reducing the availability of its provided signalling services. The results of our experiments prove the feasibility of blocking attacks. Finally, we also discuss several defending methods and present an improved protection mechanism against blocking attacks. 1 Introduction The emergence of VoIP has offered numerous features for both end users and providers alike, such as low cost, flexible services, simplified configuration, etc. These advantages are difficult to realize in traditional PSTN. However, as a closed network environment, PSTN provides high security, and particularly availability and reliability. That is why an extremely low number of attacks on PSTN have been reported until now. In contrast to PSTN, VoIP is more vulnerable due to two main reasons: Firstly, contrary to PSTN, VoIP is based on an open network environment, the Internet. Thus, a VoIP infrastructure can be easily accessed by attackers with automation tools. Secondly, current VoIP applications rely heavily on external Internet-based infrastructures (e.g., DNS server, web server). As a result, vulnerability of these external infrastructures also affect VoIP systems. The main security threats against VoIP systems are summarized in [1] [2]. The Session Initiation Protocol (SIP) [3] is designed as a signalling protocol standard for VoIP services running on the Internet and 3G Realms. In this article, we present a kind of DoS attack targeting SIP-based VoIP infrastructures using crafted SIP messages, which we call a blocking attack. Since VoIP systems require support from external hosts on the

68 54 Internet (e.g., recursive domain-name resolving, downloading certificates, etc), communication with external hosts may increase the latency of SIP services. The latency varies primarily according to hardware and network conditions of external hosts. Better hardware and network conditions of external hosts yield to lower latency. Unfortunately, this is beyond the control of VoIP systems. Actually, there are many hosts on the Internet with poor hardware or network conditions. In this article, we call them high-latency hosts. An attacker can craft special messages for a blocking attack in order to make a victim SIP proxy to interact with these high-latency hosts. Then, the victim proxy has to spend additional time on these attacking messages and thus cannot handle messages from legal users. The results of our experiments show that blocking attacks can be easily launched against SIP proxies by using external DNS servers or web servers. We also discuss several defending solutions and propose an improved solution based on a priority mechanism. This article builds on previous work published in [4]. Here, we innovate in three new directions: Firstly, we show a new method of blocking attacks by using certificate downloading besides domain name resolving. Secondly, a formalized model is given to analyze the blocking attacks in detail. Finally, we present an improved solution, called priority mechanism, for attack mitigation. The rest of this article is organized as follows. In Section 2 we give a short introduction to VoIP using SIP. Section 3 presents related work. Then, we analyze the attacking method in Section 4. We propose our testbed and experiments in Section 5. Several countermeasure solutions are discussed in Section 6. Finally, Section 7 provides conclusions for this article. 2 SIP-based VoIP SIP works as a signaling protocol at the application layer of the TCP/IP model aiming for establishing or tearing down media sessions between two parties. A basic SIP infrastructure consists of User-Agents (UAs) and several SIP servers, such as registrar servers, proxy servers (called proxy or proxies in the remainder of this article), etc. UAs are the users equipments which generate, receive and response SIP messages. Registrar servers enable users to login to corresponding domains. Proxies forward SIP messages within SIP networks. The general SIP-based telephony calling setup is shown in Figure 1. There are two SIP users located in different domains in this scenario: Alice, a caller, is located in the domain kau.se and Bob, a callee, is located in iptel.org. Initially, Alice sends an INVITE message to one of the local proxies. This INVITE message indicates that she wants to talk to Bob at iptel.org. Then, the local proxy forwards this INVITE message to the remote proxy at iptel.org. The request is finally delivered to the UA of Bob. If Bob wants to accept the call, his UA will reply with a 200 OK message back through the proxies. After Alice has sent an ACK message to confirm the request, the signaling handshaking is accomplished. Thus, Alice and Bob will build a peer-to-peer media session in which they can exchange voice

69 2. SIP-based VoIP 55 Figure 1: A general overview of SIP components and the working procedure Figure 2: An example of SIP INVITE request packets. When Alice wants to tear down the conversation, her UA will send a BYE message to Bob, and Bob s UA will reply with a 200 OK message. Then the call is terminated. An example of a SIP INVITE message is shown in Figure 2. The format of SIP messages is similar to HTTP [5], with message headers and corresponding values. The destination of a SIP message (SIP identity of the callee) is provided in the first line of the message. The remaining SIP message headers in Figure 2 are explained as follows. To : indicates the SIP identity of the callee. From : indicates the SIP identity of the caller. Call-ID : unique identifier for each call. It is used to indicate a SIP transaction. Contact : indicates the actual location where the sender can be reached. The value can be different from the from field. Content-Type : indicates which kind of payload is included in this message.

70 56 In this example, the INVITE message contains a message body using the Session Description Protocol (SDP) [6] as the payload. This SDP message body is used to negotiate the media type and format of the proposed session. SIP applications are time-sensitive. Users probably will give up their calling requests if their calls take a long time to be built up. As defined in [3], after sending a message, a UA will wait for its response. However, if no response is received during a certain time interval, the UA will retransmit the message. The retransmission could be done up to 7 times until a timeout occurres and if still no response for the message is received, the UA will consider the message as failed and give up waiting for its response. The default timeout for each SIP message is 32 seconds, that is, after sending a SIP message, a UA should receive its response within 32 seconds. Thus, if the SIP proxy is busy and cannot generate the response to users in time, the users cannot successfully place calls. This real-time requirement poses a great challenges for SIP services and makes SIP services vulnerable to DoS attacks. 3 Related Work The objective of DoS attacks is to reduce the availability of services as long as possible. The motive of attackers could be fun or profit. Some recent research has focused on DoS attacks on SIP VoIP infrastructures. Sisalem et al. [7] investigated the issues of DoS attacks targeting SIP infrastructures. They developed a taxonomy of attacks by different exploitable resources: CPU, memory and bandwidth. They also mentioned the blocking attack against SIP proxies using highlatency DNS servers, but no experiments were performed. A stateful SIP proxy has to consume memory resources to keep the transaction states of unfinished SIP transactions. Therefore, stateful SIP proxies are especially vulnerable to IN- VITE flooding attack, in which an attacker floods SIP proxies with only INVITE messages to create a large number of broken transactions. Sengar et al. [8] proposed a machine learning method to distinguish legal against INVITE flooding attacks. Based on this method, they firstly characterize legal SIP traffic behavior by summarizing the normalize frequency of INVITE, 200 OK, ACK and BYE messages. Compared with the normalized samples, the attacking traffic behavior can be easily detected by an algorithm called Hellinger distance. Moreover, [9 11] propose specification-based detection methods using SIP state machine models to counter INVITE flooding attacks. Conner et al. [12] proposed a ringing-based DoS attack to consume memory resources of stateful SIP proxies. Different to INVITE flooding, this attack exploits the potential long time 180 Ringing state. They also designed an algorithm to optimize the system. Geneiatakis et al. [13] introduced a mechanism to detect malformed SIP messages. Malformed messages are non-standard SIP messages, which are skillfully generated by attackers in order to exploit the implementation flaw of SIP infrastructures. Malformed

71 4. Blocking Attacks 57 Figure 3: The procedure of proxy working: the proxy has to contact with other hosts for external processing. message may drive the services to various unstable states and consequently cause DoS. The detection of malformed messages is based on a message signature, which is defined by using regular expressions according to the SIP grammar. Their tests prove that the overall processing overhead caused by this detection is insignificant. The blocking attack we present in this article is a kind of Denial of Service attacks. However, blocking attacks are not targeted to create unfinished transaction states as discussed in related works. The blocking attacks that we discuss are effective on both stateful and stateless proxies. Furthermore, the attacking messages are well-formed. Thus, current protection mechanisms are not effective as a countermeasure against such blocking attacks as described in this article. In our previous work [4], we represented a blocking attack on SIP VoIP infrastructures by exploiting high-latency DNS servers. We also implemented an unblocking cache mechanism to defend against such an attack. Continuing, this article addresses aspects of the blocking attacks. We formalize and analyze why the vulnerability can cause a Denial-of- Service in detail and propose a new type of blocking attack using high latency web servers. Besides, we perform our experiments with new parameters. Finally, we discuss the problems of the previous designed solutions and propose the priority mechanism as an improved protection mechanism. 4 Blocking Attacks Blocking attacks introduced in this article is a kind of DoS attack targeting SIP proxies. As explained above and illustrated in Figure 1, SIP proxies play a very important role in SIP networks. Thus, the VoIP services cannot be provided any longer if SIP proxies stop operating due to attacks. To analyze how such a blocking attack works, we illustrate a basic working flow of SIP

72 58 proxies in Figure 3 2. When a SIP proxy receives a SIP message, it will insert this message into a message buffer. Next, the buffered messages will be distributed to the parallel working processes (In practice, a SIP proxy can be configured with parallel working processes to enhance its performance. Each working process is then responsible for one messages synchronously.) We classify the steps of each processing into two categories, named internal processing and external processing, respectively. Internal processing : Internal processing consists of the processing steps that are only performed directly within the local proxy (e.g., message parsing, computing for verification, etc). The time consumption for internal processing mostly depends on the computational capability of the proxy itself. Thus, the time consumption for internal processing is predictable. External processing : External processing consists of the processing steps that do not take place locally, but also remotely (e.g., contact with a DNS server to issue a domain name request, or download a certificate from a web server to verify a SIP message). The purpose of external processing is to get Related External Information (REI) (e.g., DNS mapping of the destination domain or a certificate of the sender s domain) for message processing. Since the SIP proxy has to communicate with external hosts (DNS server, web server) over the Internet, the time consumption for external processing depends not only on the capability of the local proxy, but also on the hardware and network conditions of the remote hosts. As a consequence, the time consumption for external processing is unpredictable. Furthermore, the SIP proxy will contact the external hosts according to the information contained in SIP messages. Therefore, the SIP users who generate SIP messages can specify which external hosts a SIP proxy should contact. Blocking attacks addressed in this article exploit external processing. The vulnerability is based on two aspects. Firstly, SIP users have the ability to select which external hosts that the SIP proxy should contact. Secondly, the time consumption for SIP proxies needed to communicate with external hosts is unpredictable. Thus, an attacker can perform a series of pretests to collect a list of external hosts which could be time consuming to communicate with, defined as high-latency hosts. The measurements in [14] show that the connection latency on the Internet strongly depends on the physical distances between the hosts. The attacker can easily find high-latency hosts which are in a remote location. Then, the attacker can craft attacking messages and send them to a victim SIP proxy. The attacking messages require a victim proxy to contact these high-latency hosts for external processing. As a result, the proxy spends a long time on the attacking messages so that it cannot handle the legal messages in due time. To explain this problem better, we formalize the processing model as follows. The purpose of this model is two-fold: Firstly, it illustrates the parameters which influence the 2 However, the actual order of the internal and external processing depends on the concrete implementation of the proxy. The order of the internal and external processing is irrelevant for our topic.

73 4. Blocking Attacks 59 throughput of a proxy and allows us to discuss how far these parameters can be controlled by an attacker. Secondly, this model also demonstrates how perspective countermeasures can be influenced by these parameters. We assume that a SIP proxy receives a batch of SIP messages during a period of time T with a constant rate R. The proxy is equipped with n parallel working processes. Each process can work independently. The average processing time needed for each message of this batch on each parallel process is assumed to be t. Then, the processing capability of this SIP proxy during time T is at most C if all the parallel working processes are fully working during time T. C = n t (1) Further, we separate t as t = t e + t i. We define that t e is the average time on external processing. t i is the average time on internal processing. Thus, the processing capability (C) becomes C = Then, the size of the message buffer changes at a rate S is n t e + t i (2) S = R C (3) We know that if S > 0, more and more message will be kept waiting in the waiting queue. Therefore, the size of the message buffer increases as long as S > 0, which could lead to two results. Firstly, the memory resources of the proxy will be depleted if there is no maximum limitation on the size of message buffer. Also the messages in the buffer have to be waiting for a longer time to get processed. Secondly, if there is a maximum limitation on the size of buffer, then the proxy will refuse to accept new SIP messages as long as the limitation is reached. Thus, any of these two alternatives result in a Denial of Service on the proxy. Hence, for system stability, we assume that overall S should be less or equal than 0: S = R C 0. Thus, R n t e + t i 0 (4) From the model, the stability of SIP proxy depends on four parameters: R, t e, t i and n. Attackers can easily control the first three parameters. As long as an attacker can increase one or more of the three parameters, the steady-state of the proxy might be broken and a Denial of Service might happen. For example, attackers can flood the victim proxy with thousands of messages to increase R. However, a flooding attack can be easily detected e.g., by an Intrusion Detection System (IDS). It is abnormal and suspicious if a user constantly tries to setup a large number of calls in a given time interval. As an alternative, attackers

74 60 also can send malformed SIP messages to the victim proxy. Then, the proxy needs to perform additional grammar checking so that t i increases. Nevertheless, the caused delay time on t i is relatively small [13]. Compared with the other two parameters, t e can be more easily controlled by attackers. As we introduced before, t e partly depends on the conditions of external hosts and can be out of control of the SIP proxy. The attackers can find some high-latency hosts on the Internet and craft SIP messages (attacking messages) so that the victim SIP proxy will contact them. The consequences are as follows. 1. Firstly, the working processes have to spend much time on these attacking messages when they perform external processing to contact high-latency hosts. Hence, the increase of t e reduces the capability of the proxy. 2. Secondly, as it takes long time for working processes to handle attacking messages, the messages in the message buffer have to be waiting for a long time to get processed. As we mentioned in Section 2, after sending a message, a UA will only wait for its response until the timeout (32 seconds in default). In this way, even if these messages can be processed eventually, they probably are already expired. 3. Finally, considering the retransmission mechanism in SIP, a UA will resend the message up to 7 times if its response is not received within a given time period. Therefore, R increases as well resulting in a heavy load on the proxy. However, these retransmitted messages are from legal users and formed in a legal way. For blocking attacks there is no need to flood the victim proxy and all attacking messages are well-formed. Since messages originated from legal users can sometimes cause a large t e as well, it is difficult to distinguish between legal and illegal messages by simply observing t e. We explain how attackers can craft attacking messages to control t e in the next section. Certainly, the system administrator can increase n to fork more parallel working processes so that the proxy can handle more messages synchronously. However, each forked process consumes system resources. Too many processes can lead to the proxy being unstable. 5 Two Attacking Examples In this section, we describe how attackers can craft attacking messages with high t e to perform a DoS attack. We show two concrete examples. One takes advantages of external processing with DNS servers, and another exploits external processing with web servers.

75 5. Two Attacking Examples 61 Figure 4: Procedure of recursive DNS requests 5.1 Blocking Attack Using High-latency DNS Servers DNS Usage in SIP The Domain Name Service (DNS) [15] is one of the fundamental infrastructures for most current Internet applications available today, including web and services. It is a globally distributed database, providing an essential domain name mapping service for Internet users. Also, the DNS plays a key role in SIP networks for the following reasons. 1. Similarly to the addressing scheme, SIP VoIP users logically belong to their home domains. The format of their SIP identities (also called Uniform Resource Identifier (URI)) [16] is similar to the one of addresses, including user name and domain name. (e.g., sip:ge.zhang@kau.se) As shown in Figure 2, the identities of both caller and callee contain domain names. A SIP proxy has to contact a DNS server to resolve these domain names to locate remote domains. 2. To interconnect the PSTN with a SIP network, ENUM [17] telephone number mapping is used. This allows the mapping of a PSTN telephone number to a valid SIP address. 3. SIP can utilize different transport layer protocols (e.g., UDP, TCP). To find its right contact server in regard to the used transport layer protocol, a SIP proxy will perform a DNS SRV request for the domain of the regarding SIP URI [18]. The response may contain one or more destination hosts that provide the required services. 4. In some implementations, the callee s proxy may issue a reversing DNS request for the caller s IP address to check whether this SIP message is really coming from the domain as announced in the message. The purpose is to counter SIP identity fraud [19].

76 62 Figure 5: An example attack SIP message using a domain name Figure 6: The victim proxy will be blocked while processing attacking messages Attacking method Issuing a DNS request to DNS servers is classified as external processing since the SIP proxy cannot resolve domain names itself. The SIP proxy needs to fetch DNS mapping information of the destination domain from DNS servers. In this scenario, REI is DNS mapping information. As a result, the time on resolving domain name is beyond the SIP proxy s control. With a distributed database, the processing time of DNS request sometimes can be quite long. Whenever a SIP proxy requests a domain name resolution to a DNS server, there are generally two cases to distinguish: 1. The DNS server knows the name mapping. The DNS might know the mapping because it is the authoritative name server for this domain. As such, all mappings for the domain are preconfigured for this domain server. The server might also know the name because it has resolved the same request previously. In this case, the mapping

77 5. Two Attacking Examples 63 Figure 7: The inter-domain authentication mechanism defined in RFC 4474 result is still stored in the DNS server s internal cache. 2. The DNS server does not know the name mapping. Thus, this DNS server has to perform recursive requests to other DNS servers that might be able to provide an answer. Finally, the DNS server will receive a response, either containing a valid result or an error message that no mapping is possible. In the former case, the mapping will be stored in the server s internal cache for a period. In most cases, the DNS server can also set a timeout for requests. If no answer is received from recursive request during this timeout, the domain name is considered irresolvable. In Figure 4, we show an example where a SIP proxy of the kau.se domain issues a DNS request to sip.iptel.org. The DNS server of kau.se performs a series of recursive requests until it finds the authoritative DNS server of this domain (iptel.org). Finally, this server replies with the IP address of sip.iptel.org to kau.se s DNS server. Only after getting the result, the SIP proxy of kau.se can forward the messages to the iptel.org domain. The recursive DNS requests might be taking a long time. In step 4 of Figure 4, the DNS server of kau.se has to contact the DNS server of iptel.org to get the final result. Thus, the query time can be long if the DNS server of iptel.org is poorly implemented or has poor network conditions. In this way, an attacker can do a pretest by querying different domain names and observing their reply time. Then, the attacker can craft attacking messages containing those domains with high-latency DNS servers, which we defined as hard-to-resolve domain names in this article. The attacker can simply insert a SIP identity with a hard-to-resolve domain name in the request line. An example for such a crafted SIP message can be seen in Figure 5. The highlighted part of the message can lead to proxy blocking. When a SIP proxy receives attacking messages, it has to spend additional time on domain name resolving (as shown in Figure 6). Therefore, the SIP proxy is blocked due to the messages it has to process with high t e. In the real world, a domain name resolving can cost up to 15 seconds according to our tests.

78 64 Figure 8: An example SIP attacking message using web server 5.2 Blocking Attack Using High-latency Web Servers Inter-domain Authentication Spammers frequently use faked SIP identities in order to be untraceable. However, there is no centralized database of user accounts for all domains. It is difficult for the callee s domain to authenticate the originator of a SIP message in an inter-domain context since the callee s domain may do not have the account information of the originator. In this way, spammers can easily send SIP messages with faked identities. To prevent such a identity fraud problem, a solution based on certificates for inter-domain authentication has been proposed in RFC 4474 [20]. Its purpose is to authenticate the originator of inter-domain SIP messages. The method is shown in Figure 7. For each outgoing message to other domains, the SIP proxy in the caller s domain generates a hash digest for this message. The digest is signed by the caller s proxy with its private key. The generated signature is encoded in a new header field Identity added to the original SIP message. Furthermore, the SIP proxy attaches another new header field Identity-info, which contains the Uniform Resource Locator (URL) [21] where the certificate can be fetched from. Then, this SIP request is forwarded to the callee s domain. It is regulated that each certificate must be provided by its domain itself. That is, in a SIP message, the URL indicated in the Identityinfo field and the originator domain indicated in the From field should be matched. For each incoming message from other domains, the SIP proxy in the callee s domain first downloads the certificate according to the URL given in the Identity-info field. The public key extracted from the certificate is used to decrypt the signature contained in the Identity field. Then, a hash digest will be recomputed for the request. The result is used to be compared to the newly generated hash digest. The proxy will continue to process the message only if the two values are equal. This mechanism is recommended to be deployed in future SIP services to prevent SPAM [22].

79 5. Two Attacking Examples 65 Figure 9: The victim proxy will be blocked as long as it tries to connect to the high-latency web server Attacking Method Downloading certificates from web servers on the Internet can be classified as external processing. The REI in this scenario are the certificates of the senders domain. After receiving an inter-domain message, the proxy must authenticate the message beginning by downloading the certificate from the URL indicated in the Identity-info field. Whether the proxy will continue to process this message depends on the authentication result. If this message cannot be successfully verified or its certificate can not be downloaded, the proxy will not process this message further, but replies with an message with authentication failed. Otherwise, the proxy will continue the processing of this message. Thus, the proxy cannot decide whether it should continue to process this message until it tried certificate downloading. During the time for certificate downloading, there are 4 steps to be performed, which are the following ones. 1. The proxy issues a DNS request for the URL indicated in the Identity-info field to get the IP address of the web server which provides the certificate. 2. The proxy tries to establish a HTTP or HTTPS connection with the web server. 3. The proxy tries to download the certificate from the location given in the Identity-info field by HTTP or HTTPS transmission. 4. The proxy closes the connection. If step 1 or step 2 fails, the certificate is considered to be unable to download and the subsequent steps will not be executed. In this way, attackers can increase t e by either using a high-latency DNS server to slow down step 1 or using a high-latency web server to delay

80 66 step 2. Since we have already shown the attacks using high-latency DNS server before, we will focus more on the attacks using high-latency webserver here. For example, if an attacker knows that a website hard-to-connect.com is high-latency, he can craft an attacking message pretending to be from hard-to-connect.com, with its Identity-info field filled with An example of the attack message is shown in Figure 8. The highlighted part in the message can result in the proxy to be blocked. Actually, there is no such a file called test.cer existing on this website. However, when the victim proxy receives this request, it can spend an enormous amount of time on connecting to hard-to-connect.com. The procedure is illustrated in Figure 9. After waiting for a long time, the proxy will give up processing this message because the certificate cannot be downloaded. However, the attacker does not need the attacking message processed, but only wants the proxy being blocked. In practice, the connection with a latency web server can cost up to 60 seconds according to our pretests. 5.3 Preliminary Summary of Blocking Attacks As it is heavily depending on existing Internet infrastructures, a SIP proxy has to interact with external servers to fetch REI for processing SIP messages. We define this type of processing as external processing. For instance, when a proxy receives a message targeting other SIP domains, the proxy has to contact DNS servers to resolve the domain name. Similarly, when a proxy receives a message originated from another SIP domain, the proxy needs to download a certificate from such a domain for authentication. Thus, a sophisticated attacker can craft attacking messages which deliberately make a proxy to contact external high-latency servers. After receiving these messages, a SIP proxy will spend a long time on them and is unable to process further legal messages during that time interval. 6 Experiments In order to investigate the effectiveness of the blocking attacks in the real world, we firstly investigate the distribution of latency between hosts in the Internet. Next, we setup a testbed to perform a series of experiments, including the blocking attacks by exploiting high-latency DNS server and web server, respectively. 6.1 Measurements of Latency in the Real World To launch the blocking attacks in the real world, attackers have to collect a list of highlatency DNS servers or web servers in the Internet. The latency between the servers and the victim SIP proxy should be high enough to cause a large t e. But are these high-latency servers easy to find? And, how much latency can these servers achieve? To answer these questions, we used the MIT King dataset [23] as our measurement dataset. King [24] is

81 6. Experiments CDF Latency (ms) Figure 10: Cumulative distribution of hosts delays according to the MIT king dataset (logarithmic scale) a method to estimate the latency between two hosts in the Internet, by issuing recursive requests through their DNS servers. The MIT King dataset contains measurement of the latency between nearly 2000 randomly selected DNS servers including 97 million results. Then we took 1 ms as the interval and calculate the cumulative distribution based on the dataset, which is shown in Figure 10. The result demonstrates that values for latencies are distributed from 100 milliseconds to 1 second in most cases. However, there is still 10% probability for a latency to be higher than 1 second and 2% probability for a latency to be higher than 10 seconds. As can be seen, it is possible to find high-latency servers in the Internet without much overhead. Therefore, in the following experiments, we will investigate the attacking impact by scaling the latency time from 1 second to 14 seconds. 6.2 Test Bed The testbed consists of five components. 1. A SIP domain called Victim: A Victim domain includes a SIP UA, a SIP proxy and a DNS server. The UA is used to generate SIP messages to simulate the legal users traffic behavior. All SIP traffic to and from the UA is relayed by the SIP proxy. This SIP proxy, the attacking target, is implemented according to RFC 3261 and RFC We configured the victim proxy to be quipped with n ( n = 4 or n = 16) parallel process. These two configurations are most frequently used in practice. 2. A SIP domain called Partner: The Partner domain includes a SIP UA and a SIP proxy. It constantly receives SIP messages from the victim domain and sends replies. The partner domain is used to cooperate with the victim domain to build or tear down

82 68 Figure 11: The test bed for the attack using a high-latency DNS server Table 1: Experiment variables Variable description Variable Unit The number of parallel processes of the victim proxy n null The attacking rate of the attacking tool r INVITEs/s The delay time on a DNS request for an attacking message d dns s The delay time on a connection to the web server for an d web s attacking message calls. The SIP proxy and UA in the partner domain will not be under attack during the test. 3. An attacking tool: The attacking tool constantly sends attacking SIP requests to the victim SIP proxy. The attacking tool can be configured to send messages with variable attacking rate r (INVITEs/s). 4. A DNS server: The SIP proxy in the victim domain can contact the DNS server for DNS request. The DNS server can be specially configured to delay some requests for d dns seconds. The purpose of such a delay is to simulate the time consumption on recursive DNS requests to a high-latency DNS server. The measurement in Section 5.3 shows that the latency varies from 10 milliseconds to more than 10 seconds. In the following test, we select d dns to range from 1 second to 14 seconds. 5. A web server: The SIP proxy in the victim domain can download certificates from this web server. Similar to the DNS server, this web server can be also configured to delay each response for d web seconds. It is used to simulate the time consumption on network latency. The range of d web is selected accordingly to d dns. The experiment variables are listed in Table 1. Software. The attacking tool, victim UA and partner UA are implemented using SIPp [25], an open source SIP traffic generation tool. The SIP proxies are realized by using SIP

83 6. Experiments d dns =1 d dns =2 d dns =3 d dns =4 d dns =5 d dns =6 d dns =7 400 Accomplished calls Attacking rate r (INVITEs/s) (a) The victim proxy equipped with 4 processes (n=4) d dns =2 d dns =4 d dns =6 d dns =8 d dns =10 d dns =12 d dns = Accomplished calls Attacking rate r (INVITEs/s) (b) The victim proxy equipped with 16 processes (n=16) Figure 12: The result of blocking attacks using a high-latency DNS server: throughput rate is reduced as the attacking parameters d dns and r increase

84 70 Express Router (SER) [26]. The web server is implemented based on mini httpd [27]. The DNS server is based on a modified dnsmasq [28]. Hardware. The testbed of the victim domain with the DNS server is established on a Pentium 4 machine with 512 MB RAM running the Linux Ubuntu operating system, with fast Internet access. The partner domain and the attacking tool with the web server are running on other two machines with the same configurations, respectively. Legal user behavior. We made the UA in the victim domain and the UA in the partner domain simulating legal SIP users by constantly building up and tearing down calls according to the 14 steps in Figure 1. We define that one call has been successfully accomplished if all of these 14 steps were accomplished. In a pretest, we found that our test bed can work steadily at a rate of 50 calls/s without attacks. Then, we tried to accomplish 500 calls between the two UAs with a relatively slow rate: 10 calls/s, but under attack. We took 500 calls as the benchmark and observed how many calls can be accomplished when the victim proxy is under attack. The number of accomplished calls is used to indicate the throughput rate of the victim proxy. 6.3 Attack Tests Using a High-latency DNS Server In this scenario, we use four components based on the introduced test bed: the victim domain, the partner domain, the attacking tool and the DNS server. The configuration of this test bed is shown in Figure 11. The attacker pretends to be a roaming user who constantly sends attacking messages to the victim proxy at a rate r. The messages indicate that the attacker wants to talk with a user located in a domain called hard-to-resolve.com. Thus, the proxy will contact the DNS server to resolve the hard-to-resolve.com domain. The DNS server is configured to delay the response for d dns on purpose when it receives DNS requests of hard-to-resolve.com. The purpose of delay is to simulate the time needed for recursive DNS requests. The DNS server does not delay other requests except hard-toresolve.com. Meanwhile, the two legal UAs communicate with each other. We observed how many calls can be accomplished between them when the victim proxy is under attack. The results are illustrated in Figures 12(a) and 12(b). The pictures show that the number of accomplished calls are reduced as the attacking parameters d dns and r increase. Therefore, it is easy for an attacker to mount DoS attacks. For example, setting parameter r = 2 and d dns = 4, the attacker can bascially reduce performace of the victim by half of its initial performance. The same attacking parameter configuration does not work with the victim proxy with n = 16. However, if the attacker just simply speeds up r to 10, still 50% of all calls can not be accomplished. The experiments show that the blocking attack can be easily realized by using a high-latency DNS server.

85 6. Experiments 71 Figure 13: The test bed for the attack using a high-latency web server 6.4 Attack Tests Using a High-latency Web Server In this scenario, we employ all five components of the introduced test bed: the victim domain, the partner domain, the attacking tool, the DNS server and the web server. Since the feasibility of the attack using high latency DNS servers has already been proved in our previous tests, we configure the delay time of the DNS server d dns 0 in this test. Hence, readers should bear in mind that the DNS server in this test does not delay any request any more. The configuration of the testbed for this test is shown in Figure 13. The attacker pretends to be a SIP proxy relaying inter-domain SIP messages to contact the victim proxy. The messages are actually attacking messages which indicate their certificates can be downloaded from the web server. The victim proxy needs to authenticate these messages and thus has to communicate with the web server for downloading the certificates. The web server has already been configured to delay every downloading request for d web seconds. The purpose is to simulate the time needed for network latency on connections. Otherwise the setup is similar to the previous experiment. The test results are shown in Figures 14(a) and 14(b). The pictures show that the number of accomplished calls are reduced as the attacking parameters d web and r increase. Therefore, it is also possible to mount DoS attacks by using high-latency web servers. However, the impact of these attacks are lower compared to the impact of the previously discussed attacks in Section 5.2. The reason is that for the attacks exploiting high-latency DNS servers, the victim proxy contacts the DNS server twice for each attacking message (the first time for a SRV request, and since no result is received, the proxy will continuously issue another A request 3, so it will be delayed twice for each attacking message. But for the attack exploiting high-latency web servers, the proxy contacts the web server only once for each message. Nevertheless, the result still shows the impact of the attack using web server is large enough to launch DoS attacks on SIP proxies. 3 A SIP domain may own several proxies which support different transportation protocols. For DNS resolving, a SIP proxy will issue a SRV request to find out the corresponding transportation protocol supported by the target domain, and then issue an A request for the selected proxy. However, if the SRV request failes, the proxy will issue the A request of the target domain directly [18].

86 d web =1 d web =2 d web =3 d web =4 d web =5 d web =6 d web =7 400 Accomplished calls Attacking rate r (INVITEs/s) (a) The victim proxy equipped with 4 processes d web =2 d web =4 d web =6 d web =8 d web =10 d web =12 d web = Accomplished calls Attacking rate r (INVITEs/s) (b) The victim proxy equipped with 16 processes Figure 14: The result of blocking attacks using a high-latency web server: the throughput rate is reduced as the attacking parameters d web and r increase

87 7. Defence Solutions 73 7 Defence Solutions In this section, we present and discuss several defence solutions against blocking attacks. The solutions are classified in two categories: (1) Proxy-based; (2) Cache-based. 7.1 Proxy-based Solutions Proxy-based solutions aim at minimizing the impact of blocking attacks by increasing the CPU utilization of the victim proxies. The solutions include increasing n, restricting t e and adopting asynchronous processing. Solution 1: Increase n. Observed from the experiments, blocking attacks work most effectively if the proxy utilizes few parallel processes. For example, as shown in Figure 12(a) and 12(b), when n = 4, the attack with parameter r = 6 and d dns = 3 can almost achieve a full DoS. When n = 16, the same attack can only reduce the performance of the proxy by around 40%. This shows that an increase of n is helpful to enhance the performance during attacks. However, we also can observe from the experiments that the attacks will still work as long as the attacker increases the attacking rate r, which can be easily achieved by a Distributed Denial of Service (DDoS). On the other hand, n should be confined within a reasonable range, as each process of the proxy consumes CPU and memory resources. Configured with too many processes, the proxy will take the risk to be overloaded or even crash. Solution 2: Setup a limitation on t e. It has been shown that the more time spent on external processing t e, the more performance of SIP proxies is reduced during attacks. In this way, the system administrator can arbitrary set a timeout of t e for SIP proxies, (e.g., 5 seconds). Thus, for a message whose external processing has already taken 5 seconds and is still going on, the proxy stops waiting and cancels the processing for this message. However, the proxy can still be blocked at least for the timeout during attacks. Another problem is that many messages from legal users might take a long t e as well. Simply setting up a timeout for t e does not solve the problem completely and may cause a high false positive rate annoying legal users. Solution 3: Asynchronous Processing. The easiest way to implement external processing is to use some provided library functions (e.g., gethostbyname() for DNS requests and curl easy perform() for downloading certificates). However, these functions were designed without taking blocking attacks into account. As a result, the SIP proxy cannot do anything besides waiting during external processing. A solution is to re-implement these functions using an asynchronous processing model: after issuing an external processing request, the proxy would not wait until an answer for this request is received. Instead, it puts

88 74 the request into an event queue, saves the transaction data, sets current external processing on hold and continues handling subsequent requests. When a reply for a previous external processing arrives, the suspending transaction is scheduled to continue. In this way, the external processing will not be blocked. Unfortunately, however, since all the states and SIP messages of unfinished external processing have to be saved, the implementation complexity and memory requirements increase considerably. In previous tests [4], we found that asynchronous processing easily leads to the depletion of memory of SIP proxies during attacks. 7.2 Cache-based Solutions As mentioned before, the purpose of external processing is to get REI for a message. Generally speaking, the same REI (e.g., DNS mapping or certificate) can be reused for messages coming from or targeting the same domain. To avoid wasting time on external processing, a SIP proxy can cache fetched REI locally. Thus, there is no need to interact with external servers all the time if its REI can be found locally. The philosophy behind cache-based solutions is to transfer tasks from external processing to internal processing. All the following proposed solutions are based on cache. To explain this section better, we firstly define four kinds of SIP messages from a proxy s point of view. Then, the cache-based solutions are represented. 1. α message: An α message originates from a legal user. The proxy has successfully fetched the REI of this message before. This may has happened because the proxy previously processed another message with the same REI that is needed. For example, consider two messages targeting at two different callees located in the same domain, the REI (DNS mapping) for these two messages are the same. Furthermore, for α messages, their REI is still saved in the local cache on proxy. 2. β message: A β message originates from a legal user as well. The proxy has also fetched the REI of this message before. However, contrary to an α message, the REI is not saved in the local cache. This may be due to two reasons: Firstly, there is a maximum limitation on the size of a cache. So some cached items will be erased to make room for new items when the size limitation is reached. Secondly, cached REI (both the DNS records and certificates) is assigned with a Time-To-Live (TTL) timer by their owner. Cached information will be removed from the cache when the TTL is expired. The cache refreshing is necessary in order to not only keep the proxy with updated information of remote hosts, but also to prevent cache poisoning attacks [29]. 3. γ message: A γ message is sent from a legal user. The proxy has not fetched the REI of this message before. As a result, its REI is not cached, either.

89 7. Defence Solutions 75 Table 2: A taxonomy of SIP messages from a proxy s perspective Type Sender Its REI has been fetched before Its REI is cached α legal user Yes Yes β legal user Yes No γ legal user No No δ attacker No No Figure 15: State transitions between α, β and γ messages 4. δ message: A δ message is generated by an attacker. To maximize the impact of attack, an attacker can randomize domain names or URLs in the message with automation tools to bypass the caching (e.g., adding random hosts names to the left side of a domain). Thus, for each δ message, it is unlikely that the REI has already been fetched for another previous message. In consequence, its REI is not cached as well. A summary of these four message types is shown in Table 2. Furthermore, the same legal message can be classified as α, β or γ message at different times. The state transitions are shown in Figure 15. If a proxy does external processing for a γ message, the REI of this γ message is cached. Then, if the proxy receives the same message another time, it becomes an α message. After its cached information has expired, the same message will be a β message. Certainly the message can become an α message again if the proxy reissues the external process. An ideal solution would process all messages from legal users including α, β, and γ messages and, while δ messages would be filtered by the proxy. Solution 4: Simple deployed caches. The local cache consists of both a positive cache (for such a domain with fetched valid information) and a negative cache (indicates that it is unlikely to get a result for such a domain). Deploying a cache can accelerate processing for the messages with their REI cached. However, given that an attacker generates randomized attack messages (δ message), it is unlikely for a proxy to find the REI from local cache. A victim proxy can still be blocked by δ messages. Thus, simply deploying caches cannot

90 76 eliminate the impact of blocking attacks. Solution 5: Unblocking cache. This solution uses the cache based on an unblocking mechanism, so called unblocking cache. We implemented an unblocking cache as a countermeasure against DNS blocking attack in our previous work [4]. Given a proxy with n parallel working processes, we define one of them as an emergency process. As long as n 1 processes are blocked by external processing, the emergency process will refuse to do external processing any more. Instead, it will only check the result in its local cache and reply with an error message (e.g., 5xx server error) if its external information cannot be found in the cache. The algorithm of the unblocking cache is shown in Algorithm 1. The benefit of using an unblocking cache is two-fold: firstly, when a proxy is under attack, the emergency process can at least handle α messages without being blocked. Moreover, since the emergency process refuses to do external processing at all when the proxy is under attack, the throughput rate of it should not be much reduced. As a result, it is helpful to clear up the message buffer in time and then accept more fresh messages into the message buffer. Input: n: the number of parallel working processes if number o f blocked processes < n 1 then if CheckCache() = NoResult then number o f blocked processes + +; ExternalProcessing(); number o f blocked processes ; UpdateCache(); end else GetFromCache(); end end else if number o f blocked processes n 1 then if CheckCache() = NoResult then Reply(System Busy); end else GetFromCache(); end end Algorithm 1: Unblocking cache The result of our past experiments showed that this solution is more effective than previous ones to counteract blocking attacks. However, the proxy still cannot process β messages during attacks even with the unblocking cache solution. The reason is that this solution refuses to do external process at all as long as n 1 processes are blocked. This

91 7. Defence Solutions 77 may cause problem in practice: for a long lasting blocking attack, all cached information in a proxy may be removed as soon as their TTL expires. Thus, the emergency process will refuse to process any message as the local cache becomes empty. In this way, the impact of denial of service still exists. To address this problem, we have to improve the unblocking cache so it can process β messages during attacks as well. Input: n: the number of parallel working processes if number o f blocked processes < n 1 then if CheckCache() = NoResult then number o f blocked processes + +; ExternalProcessing(); number o f blocked processes ; UpdatePriorityList(); UpdateCache(); end else GetFromCache(); end end else if number o f blocked processes n 1 then if CheckCache() = NoResult then if CheckPriorityList() = NoResult then Reply(System Busy); end else number o f blocked processes + +; ExternalProcessing(); number o f blocked processes ; UpdatePriorityList(); UpdateCache(); end end else GetFromCache(); end end Algorithm 2: Priority mechanism Solution 6: Priority mechanism. The priority mechanism is an improvement of the unblocking cache. The purpose of the priority mechanism is to enable processing of both α and β messages during an attack. The priority mechanism works in a similar manner to the unblocking cache. The difference between them is that the priority mechanism employs a

92 78 Figure 16: Test bed used to compare the effectiveness of different solutions priority list instead of the content of cache to decide whether a message can be processed. The priority list includes a list of domain names or URLs, from which the proxy has previously successfully fetched REI. It only contains domain names or URLs without their detailed external information. Further, it is constantly updated after each successful external processing. Since the priority list only contains domain names or URLs, it does not consume much memory resources and it is not vulnerable to cache poisoning. Therefore, more entities can be managed with a priority list than with a local cache. The algorithm of the unblocking cache is shown in Algorithm 2. When n 1 processes are blocked, the emergency process enables to handle both α messages and β messages in this way: After receiving a message, the emergency process first checks the local cache to determine whether it is an α message. If it is an α message, the emergency process gets REI from cache and processes this message. If it is not an α message, the emergency process will check the priority list to find out whether it is a β message. If it is a β message, the proxy will do external processing for this message and cache the result. Otherwise, for other message types (γ message and δ message), the emergency process will give up processing. In this way, this solution increases the trusted circle and enables the proxy to do external processing for β messages. One may argue that it may take some time for an emergency process to do external processing for a β message. However, since a β message has been successfully processed before, we assume that the message can be trusted and the external processing of it will not take too long. Furthermore, its REI can be cached locally again after successful external processing. This means that the same external processing will not be repeated continuously. Therefore, we assume that this drawback is acceptable. 7.3 Solution Comparison We conducted an experiment to compare the proposed solutions. Since we already proved that proxy-based solutions are insufficient [4], we only apply the cache-based solution prototypes on a victim proxy to observe and compare the effectiveness of the three solutions. The setup of our test bed for these experiments is shown in Figure 16. The attacking tool

93 7. Defence Solutions Deployed only cache Deployed unblocking cache Deployed priority mechanism 400 Number of replied 200 OK Elapsed time (s) Figure 17: Test results of the cache-based solutions comparison: Each point in the figure indicates every tenth received 200 OK message over time generates δ messages to the victim proxy and the DNS server will delay the requests for δ messages. Changing from previous test beds, the partner domain is no longer used in this test. Instead, we selected 15 SIP providers from the real world. Each SIP provider has its own domain. The reason why we change the test bed elements is that we need different domain names in the real world to test deployed caches. To simplify the test, the legal UA in this experiment does not build calls as in previous tests. Instead, our SIP UA only sends OPTIONS 4 messages to these 15 SIP providers through the victim proxy. The total amount of sent OPTIONS messages is 500. We have tested that the UA will receive all OK message replies for OPTIONS messages if there is no attack. We further observe how many 200 OK messages will be received by the UA when the victim proxy is applying the different solutions and is under attack. We start the UA first followed by the attacking tool in order to let the priority list and the local cache get the information of these domains of SIP providers. Each repeated experiment lasts for 1000 seconds. Figure 17 plots the testing result: one point for every tenth received 200 OK messages over elapsed time. In this test, the best performance is achieved by the priority mechanism: the UA received all OK messages. Next, after deploying the unblocking cache solution, nearly OK messages were received by the UA. During the first 300 seconds, the unblocking cache gives the same performance as the priority mechanism. However its throughput is slightly reduced 300 seconds later as the distances between each points increase. This is caused by the refreshing of some cache entries with expired TTL. Since some REI is not in cache any more and the emergency process refuses to do external 4 The SIP OPTIONS method allows a UA to query the capabilities of a SIP proxy. The proxy should then reply with a 200 OK message containing corresponding information.

94 80 processing, some messages can not be processed any more. That is why the proxy missed some legal messages. Nevertheless, the deployed priority mechanism can process all the messages, since the emergency process is allowed to do external processing for β messages, despite of whether their REI are still in cache or not. The experiment also proved that simply applying a basic cache is insufficient for defending against the attacks: the proxy only worked for the first 180 seconds and less than 20% 200 OK messages were replied. 8 Conclusion Since SIP proxies have to frequently contact external servers to fetch related information for processing, the time consumption on interactions with external servers is beyond the control of SIP proxies. This vulnerability increase extra processing time and can be exploited by attackers to reduce the throughput of SIP proxies for mounting a DoS attack on SIP proxies. We define this attack as a blocking attack. Our experiments have proved that the blocking attack can be launched with a low attacking rate by taking advantage of high-latency DNS and web servers. It can be predicted that more Internet-based infrastructures can be deployed for such blocking attacks in the future with increasing SIP applications. Hence SIP designers and implementors should carefully take this vulnerability into account. Finally, we compared several defending solutions and proposed a priority mechanism to enhance the performance of service during the attack. References [1] Voice over IP Security Alliance (VOIPSA). visited at 16th- Sep [2] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, C. Lambrinoudakis, S. Gritzalis, S. Ehlert, and D. Sisalem. Survey of security vulnerabilities in session initiation protocol. Communications Surveys & Tutorials, IEEE, 8(3):68 81, [3] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. SIP: Session initiation protocol, RFC [4] G. Zhang, S. Ehlert, T. Magedanz, and D. Sisalem. Denial of service attack and prevention on SIP VoIP infrastructures using DNS flooding. In IPTComm 07: Proceedings of the 1st international conference on Principles, systems and applications of IP telecommunications, pages 57 66, New York, NY, USA, July ACM. [5] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, and T. Berners- Lee. Hypertext transfer protocol HTTP/1.1, RFC [6] M. Handley and V. Jacobson. SDP: Session description protocol, RFC 2327.

95 REFERENCES 81 [7] D. Sisalem, J. Kuthan, and S. Ehlert. Denial of service attacks targeting a SIP VoIP infrastructure: attack scenarios and prevention mechanisms. IEEE Network, 20(5):26 31, [8] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. Fast detection of denial of service attacks on IP telephone. In 14th IEEE International Workshop on Quality of Service, New Haven, USA, June IEEE. [9] E. Y. Chen. Detecting DoS attacks on SIP system. In 1st IEEE Workshop on VoIP Management and Security, Vancouver, Canada, April IEEE. [10] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. VoIP intrusion detection through interacting protocol state machines. In DSN 06: the International Conference on Dependable Systems and Networks, June. [11] S. Ehlert, C. Wang, T. Magedanz, and D. Sisalem. Specification-based denial-ofservice detection for SIP voice-over-ip networks. In 3rd International Conference on Internet Monitoring and Protection, Bucharest, Hungary, July IEEE. [12] W. Conner and K. Nahrstedt. Protecting SIP proxy servers from ringing-based denialof-service attacks. In the Tenth IEEE International Symposium on Multimedia (ISM), Berkeley, USA, December IEEE. [13] D. Geneiatakis, G. Kambourakis, C. Lambrinoudakis, T. Dagiuklas, and S. Gritzalis. A framework for protecting a SIP-based infrastructure against malformed message attacks. Comput. Netw., 51(10): , [14] A. Fei, G. Pei, R. Liu, and L. Zhang. Measurements on delay and hop-count of the internet. In IEEE GLOBECOM 98 - Internet Mini-Conference, Sydney, Australia, November IEEE. [15] P. V. Mockapetris. Domain names - implementation and specification, RFC [16] T. Berners-Lee, R. Fielding, and L. Masinter. Uniform resource identifier (URI): Generic syntax, RFC [17] P. Faltstrom and M. Mealling. The e.164 to uniform resource identifiers (URI) dynamic delegation discovery system (DDDS) application (ENUM), RFC [18] J. Rosenberg and H. Schulzrinne. Session initiation protocol (SIP): locating SIP servers, RFC [19] M. Nassar, R. State, and O. Festor. VoIP honeypot architecture. In IEEE International Symposium on Integrated Network Management, Munich, Germany, May IEEE.

96 82 [20] J. Peterson and C. Jennings. Enhancements for authenticated identity management in the session initiation protocol (SIP), RFC [21] T. Berners-Lee, L. Masinter, and M. McCahill. Uniform resource locators (URL), RFC [22] J. Rosenberg and C. Jennings. The session initiation protocol (SIP) and spam, RFC [23] The MIT king dataset. visited at 16th- Jan [24] K. P. Gummadi, S. Saroiu, and S. D. Gribble. King: estimating latency between arbitrary internet end hosts. In IMW 02: Proceedings of the 2nd ACM SIGCOMM Workshop on Internet measurment, pages 5 18, New York, NY, USA, ACM. [25] SIPp. visited at 16th-Sep [26] SIP Express Router (SER). visited at 16th-Sep [27] Minihttpd. httpd/, visited at 16th-Sep [28] Dnsmasq. visited at 16th-Sep [29] J. Stewart, DNS cache poisoning - the next generation, Technical report, http: // visited at 4th-Nov-2008.

97 Paper III Increasing SIP firewall performance by ruleset size limitation Reprinted from Proceedings of the IEEE 19 th International Symposium on Personal, Indoor and Mobile Radio Communications (PIMRC 2008), IEEE Press Cannes, France, September 2008

98

99 Increasing SIP firewall performance by ruleset size limitation Sven Ehlert, Ge Zhang and Thomas Magedanz Abstract To protect SIP communication networks from attacks, especially flooding attacks like Denial-of-Service or message spam, Intrusion Detection Systems (IDS) are deployed at the ingress point of the network to filter potential malicious traffic. A key issue of IDS performance is the operation of its firewall to block malicious user requests. Depending on the complexity of the firewall ruleset, filtering performance of the IDS can decrease considerably during high-load flooding situations. In this paper we propose a scheme to increase IDS firewall performance by merging several similar rules into more general ones and ignoring lesser relevant rules to limit the number of firewall rules. We formalise a mathematical model to compute new firewall rules and show exemplary with traffic from SIP VoIP communication networks how the calculation can be performed. If applied to a VoIP IDS, the scheme can increase firewall thoughput considerably, while retaining most of its effectiveness. 1 Introduction The Session Initiation Protocol (SIP) [1] is gaining ever more popularity, as it is the key protocol for most VoIP services in the Internet and next generation networks like the Internet Multimedia Subsystem (IMS) [2]. As such, it becomes ever more attractive for attackers [3] [4], who can launch e.g., Denial-of-Service attacks to disturb the service, annoy users by initiating multiple spam sessions or steal credentials to misuse the service (call theft and fraud). Protecting the service thus becomes of utmost importance for the provider. Session Border Controllers (SBC) have been established as all-in-one advanced protection solutions for SIP-based networks. Besides SBCs, dedicated security solutions for SIP networks exit [5] [6] [7]. The key component of such an advanced security solution is a SIP-aware firewall, that can take SIP features into account. By examining the message payload i.e., SIP header fields, fine-grained security policies can be defined. However, due to the additional complexity of such a SIP firewall, its performance (i.e., throughput capabilities) can decrease, depending on the size of firewall ruleset and the amount of traffic to be processed.

100 86 In this paper we address such performance penalties of SIP-aware firewalls. Our goal is to increase message processing capability of the firewall by limiting the ruleset size to a fixed value. An optimiser component is employed to reduce the original firewall ruleset (R i ) of possibly unlimited size to a new ruleset (R o ) of fixed size, which will actually be applied at the firewall. The optimisation process is performed by merging several similar rules into one new rule, and by dropping rules with lesser security impact. As this process causes an inaccuracy in the new ruleset R o, a metric is defined to minimise it. In the remaining sections we address the problem space and scope, and introduce our ruleset optimiser solution. The algorithm is explained with examples and operation is visualised with real-life VoIP traffic traces. We present other relevant work in this direction and outline some open issues. 2 Background Information 2.1 Voice over IP with the Session Initiation Protocol SIP [1] is a text-based protocol designed to establish or terminate a session between two or more partners. The message format is similar to the HTTP protocol, with message headers and corresponding values e.g., From: user@sip.org to denote the sender of a message. Several message types are defined (e.g. REGISTER, INVITE, ACK, BYE,...) and encoded in the first line of each message (Request-URI). Message headers include e.g., From, To, Call-ID, or User-Agent. A SIP VoIP network consist of several entities, including User Agents (UA) that generate or terminate SIP requests, Registrars, where users log in and announce their availability in the SIP network and Proxies that forward requests in the appropriate SIP networks. Several proxies can be deployed in a SIP infrastructure e.g., outbound proxies that regulate routing outgoing traffic from one network to a foreign network and incoming proxies that handle all incoming SIP requests possibly enforcing additional security checks. 2.2 Firewalls A firewall is a network security component deployed between networks of different trust levels. Located at the network ingress and possibly at the egress point, it examines all in- and outgoing traffic which is then forwarded or dropped according to security policies. Stallings [8] defines three common firewall types: 1) A packet filter inspects packets which represent the basic unit of data transfer on the network level. Packet filters operate solely at the IP level. 2) An Application-Layer Gateway (ALG) works as a relay on the application level. Additional to a packet filter it has application-layer knowledge of certain protocols (common examples are DNS, HTTP, or FTP) and applies its security policy rules also on

101 3. Problem Space and Scope 87 the application level. A SIP-aware firewall is thus an ALG with SIP knowledge. Note, that an SIP ALG needs to implement a SIP text parser - while IP fields can be accessed directly due to its fixed binary format, SIP uses free-form text. After parsing, a SIP ALG could apply security policy rules based on SIP message header fields e.g., drop packets with a certain transaction ID or user agent identification. 3) A Circuit-Level Gateway works on the session level and hides information of protected networks, a common example are web proxies. An essential component of both the packet filter and application-layer gateway is the actual definition of the security policy, which generally consist of a list of rules in the form if condition then action, where condition can be e.g., a comparison to an IP address or port and action is either accepting or discarding. All defined rules at the firewall form its ruleset. Rules can be static e.g., the network security operator has defined these rules manually, or updated dynamically by a firewall controller - commonly an Intrusion Detection System (IDS). At each passing packet, the firewall searches the ruleset for applying rules (the condition matches the examined packet), and performs the defined action on the packet. Firewall rules can be distinguished between single-mapped and multi-mapped rules. A single-mapped rule matches exactly one entity e.g., an IPv4-address condition for address would only match traffic coming from exactly this address. On the other hand, rules utilising pattern to match multiple entities are called multi-matched rules. For example by using regular expressions, the IPv4 address condition * would match traffic in the IPv4 range from to (excluding network and broadcast address). 3 Problem Space and Scope Protecting a VoIP network at the ingress point will be a crucial task in the future. With advanced flooding attacks like DoS or spam call generation, an IDS needs to be deployed to provide attack mitigation features (figure 1). The IDS analyses all passing traffic and dynamically updates the network firewall in realtime to cope with immediate attacks [9]. To detect such advanced attacks it needs sophisticated detection algorithms, which are a topic of ongoing research [10] [11]. However, this setup poses a threat for a self-inflicting DoS. Given a high load of malicious traffic to the service, the IDS will continuously add new rules to the firewall to prevent this traffic from reaching the service. As the size of the firwall ruleset increases, the performance of the firewall will decrease, due to two factors: Searching for matching rules becomes more complex as the firewall ruleset grows. And, especially for SIP ALGs, each passing SIP message need to be parsed before a decision can be made. For example, we show in [5], that the throughput rate of a firewall decreases with an increasing number of rules. Given a constant traffic flooding rate of about 170 Mbit/s, the rate drops to 130Mbit/s after the introduction of 100 IP-layer firewall rules, and drops further to 70 MBit/s after the

102 88 Figure 1: IDS protected SIP VoIP network insertion of SIP ALG rules. Other authors witness similar decrease in performance of protection systems [12] [13]. Hence, security solutions are faced by the following dilemma, which holds true especially in high-traffic scenarios: If no flooding protection is applied, the service s performance will degrate due to the attack; however, applying IDS protection might also degrate service s performance due to limited firewall throughput rates. There a several possibilities to address this conflict in high-flooding scenarios: 1) Define more intelligent protection algorithms for the IDS. Ideally, the protection algorithm should generate as few firewall rules as possible but still provide effective protection. This would increase the complexity of the detection scheme and hence introduce a new performance penalty. Additionally, algorithm optimisations have to be developed separately for each new threat. 2) Design and implement a high-performant firewall. Different designs for firewalls exist [14] to increase firewall performance. However, adding additional features like SIP ALG processing, reduces performance again. 3) Limit the number of rules at the firewall, independent of the used IDS detection algorithm. This is the scope of this work in the context of flooding attacks. By applying a maximum size limit of the ruleset, a certain operating level of the firewall is guaranteed. Each of the solutions have certain advantages and drawbacks. Most importantly, there is likely no ultimate solution that allows optimum security together with maximum performance. Hence, a solution to this problem is likely a tradeoff between these two factors.

103 4. Firewall Ruleset Optimiser 89 Figure 2: The optimiser re-constructs the ruleset generated by IDS in favour of the throughput of IDS 4 Firewall Ruleset Optimiser 4.1 Algorithm Overview To reduce the size of the ruleset at the SIP firewall we define σ max as an upper maximum bound for the number of rules the SIP firewall will accept. Its value depends on the performance of the used firewall and on the traffic scenario of the VoIP network. A higher performant firewall can tolerate a higher value for σ max. The value can e.g., determined by stress tests of the firewall. The value should be set in such a way that whenever Ruleset σ max (where Ruleset indicates the size of the firewall s rules), the firewall will yield acceptable performance for the defined setup and scenario. We introduce a ruleset optimiser which constantly translates the input ruleset R i, generated by an IDS, to the output ruleset R o, which strictly satisfies the requirement Ruleset σ max. R o will then be applied at the firewall (See figure 2). By limiting the maximum ruleset size, the firewall s effectiveness will likely degrate by a certain degree e.g., rules might not be deployed at the firewall because of the maximum size has been reached. We accept this lesser accuracy for flooding scenarios as an unwanted, but necessary sidecondition, as this at least provides partial service protection, in comparison to no protection at all. Also, for DoS attacks, it is acceptable to let some DoS packets pass through, as they will only increase the load at the proxy, but not degrate its performance, if most other packets will be blocked.

104 90 Figure 3: Overview of the ruleset optimiser The basic idea of our algorithm depends on the three steps ruleset merging, rule dropping, and accuracy calculation for optimisation, as seen in figure 3. Firstly, we assume that most rules generated by the IDS will be single-mapped. For example, considering IP addresses, there will be IPv4 address field ruleset conditions for entries , , and Looking at SIP vendor names there might be SIP user-agent header field conditions like Cisco ATA 186 v ata18x, Twinkle/1.1, and Cisco ATA 186 v ata18x. We merge several single-mapped rules into one multi-mapped rule using a redundancy metric. Secondly, if after this step R o > σ max, additional rules will be dropped until R o σ max. We define a metric to select more relevant rules for merging and less relevant ones for dropping. Using both ruleset merging and dropping, the accuracy of the ruleset changes during the transition. For example, by combining multiple single-mapped rules into one multimapped rule, additional targets might be included in the matching ruleset. Contrary, by dropping rules from the ruleset, targets are excluded from the matching ruleset. Hence, we finally apply a metric to calculate a minimum change in accuracy from R i to R o. To meet both performance and security requirements, the optimiser has to ensure, that 1. R o σ max during operation, and 2. the accuracy change through the generation of R o from R i is minimal.

105 4. Firewall Ruleset Optimiser Algorithm Details Redundancy Metric Within the merging step, multiple single-mapped rules will be merged into one multimapped rule. The actual process depends on the scope of the firewall rule, and has to be defined for each examined field individually. We demonstrate this here with two examples, which can easily be extended for other fields of interest. IPv4 Address Field The most common use in firewalls is the matching of IP address fields. We apply merging at the subnet level i.e., several single-mapped address rules are mapped into one multi-mapped rule covering one whole subnet. Ideally, if there are 254 single-mapped address rules covering e.g., the address range from to in R i, we can replace these 254 rules with one multi-mapped rule * in R o. Admittedly, this example covers an ideal situation: there are exactly 254 IPv4 addresses in the same subnet in R i, so one can simply use the subnet address in R o instead of 254 individual IPv4 addresses. However, merging with less than those 254 rules would change the accuracy of the resulting R o. We introduce the variable χ to determine the threshold after which single-mapped rules are replaced by a multi-mapped one. Rules in R i can be merged into a multi-mapped rule only if the number of mergeable rules is greater than χ. For example, if there are three address rules , and from the same subnet, and given that χ = 3, they will be merged into *. However, if χ = 4, they will not be merged. The value of χ will be computed in the optimisation step. SIP User Agent Header Field Many SIP header-fields are free-from text fields e.g., the User-Agent string that denotes the generator of the SIP message. Its usage in SIP firewall would be highly beneficial e.g., to filter ill-configured user agents. Entries vary considerably due to the diversity of vendors and versions. We have seen through observation a common pattern how the string is generated, consisting of three parts, UA name, sub-name and version ususally in left to right order, commonly separated by whitespace. Based on this observation, single-mapped UA string rules can be merged into one multi-mapped one. As an example, we can separate a UA string into two parts by the last non-alphabet, non-numeric character. We call the left part name part and the right part version part. Firstly, we subgroup the rules which share the same name part. For example, Zultys ZIP and Zultys ZIP can be subgrouped because they share the same name part Zultys ZIP 2 3., however sipsak and sipura/spa can not be subgrouped as their name parts are different. Again, χ indicates how many different UA strings can be merged into a new one. Only if more than χ rules can be found sharing the same name part, a new merged rule is created for it.

106 Significance Metric We define a significance value F rq as the number of times a rule is matched within the IDS. For instance, given a rule that allows incoming traffic from IP address which is matched at the IDS by incoming traffic 10 times since the last optimisation, we set F rq = 10. Using a Most Frequently Used (MFU) policy, we are able to order the rules in R i by significance. This ensures that at least the offenders which the most overhead traffic will be denied access to the network Accuracy Changes We introduce the term space to indicate how many entities are mapped to possible targets. For example, the space of a single-mapped IPv4 rule is always 1, while it is higher for multi-mapped rules (i.e., it is 254 for the above defined subnet rules). For UA strings we look at the size of the UA string. We can then define S ruleset as the space of all rules in a ruleset combined. Ideally, S Ri should be close to S Ro as this would indicate an accurate conversion. Now we can calculate false positives and false negatives within the two rulesets. We define F p as the increase of space through rule merging in R o : F p = i, i S Ro, i S Ri (1) Similarly, we can define F n as the number of false negatives: F n = i, i S Ri, i S Ro (2) Both merging and dropping will decrease accuracy in the target ruleset R o, either by the introduction of false-positives (caused by merging) or false-negatives (caused by dropping). Hence, with the conversion from R i to R o, the target space will change, causing R o to become less reliable. For example, given R i with 600 rules and setting σ max to 20 and considering only singlemapped rules, only 20 rules with the highest F rq can be considered for R, and information contained in the 580 lower significant remaining rules would be lost, so S Ri = 600 and S Ro = 20, and the false negative index F n = S Ri S Ro = 580. The change in accuracy can be denoted by a (preliminary) inaccuracy index, as the sum of F p and F n. The higher this index gets, the more information is lost during the conversion from S Ri to S Ro. However, F p and F n will generally not considered equally in all situations. For example, if in a DoS scenario it would be acceptable to let a certain degree of malicious traffic pass, but regular users should rather not be affected, F p should be rather low, while higher

107 4. Firewall Ruleset Optimiser 93 R i R o σ max F p F n χ η Table 1: Introduced variables original ruleset consisting of a list of single-mapped rules output ruleset after optimising, consiting of a list of single- and multi-mapped rules size constraint of R o false positive index introduced by optimisation false negative index introduced by optimisation a threshold number to indicate the minimun number of single-mapped rules needed before they can be merged into one multi-mapped rule a weighting factor to indicate the importance of F p compared to F n values for F n are acceptable for a firewall in blacklisting mode. Other scenarios might require a different setup. To reflect this, we introduce a weighting factor η and and define µ = F p + ηf n (3) where µ is the final inaccuracy index, which should be as low as possible. All defined variables are listend in table Formal Specification The formal specification of the algorithm is listed as algorithm 3. Given the input values R i, σ max and χ the algorithm calculates the optimised ruleset R o using a temporary ruleset R tmp. R i will be separated into subsets with each subset containing its own mergeable rules. Then, the size of each subset is calculated, and if the size is greater or equal than χ, all rules will be merged into a multi-mapped rule, which in turn is inserted into R tmp. Otherwise, the rules in the subnet will not be merged, and will be inserted into R tmp independently. F rq of a multi-mapped rule is calculated as the sum of each single-mapped rule s F rq. Finally, rules in the R tmp are sorted according to their F rq and the top σ max rules with highest F rq are selected to generate R o. The methods SubGroup and Merge are depended on the type of rules (e.g., IPv4 address rule, UA header string).

108 Input: R i, σ max, χ Output: R o R o = φ; R tmp = φ; SubGroup(R i ): R i = R i1 R i2 R i3... R in ; foreach j( j {1,..., n}) do if R i j χ then r multi = Merge(R i j ); R tmp = R tmp r multi ; end else R tmp = R tmp R i j ; end end S ortbyfrqacend(r tmp ); while R o σ max do R o = R o Pop(R tmp ); end Algorithm 3: Converting R i to R o We call the procedure in code lines 3 to 12 merging and the procedure in code lines 13 to 15 dropping. Finally, we formalise the optimisation model as follows. min : µ = F p + ηf n (4) s.t. : R o = f (R i, σ max, χ) (5) R o σ max (6) Here, (4) is the minimisation objective function to achieve, indicating the goal to find an optimal result with the inaccuracy index µ minimised. (5) and (6) are constraint functions, with (5) showing how to reach the output ruleset R o using algorithm 1 as f, and constraint (6) indicating that the size of output R o must be less than σ max Example Run The general optimisation process using a concrete example can be seen in figure 4. Here, different rules (a x, b x, c x ) with their frequency are shown. First, similar rules are subgrouped, so that e.g., all a x rules are put together. Then, similar rules a 1 a 4 are merged into one new rule, as there are 4 individual a-rules here, passing the threshold value χ = 3. However, the b-rules are not merged, as there are only two of them. The four new rules are

109 5. Application 95 Figure 4: Example process of the optimisation algorithm - here, the four similar rules a 1 a 4 are merged into one new rule and rules with lesser frequency are dropped. sorted by their frequency, and finally the two rules with the lowest frequency are dropped to satisfy σ max = 2. 5 Application 5.1 Calculation with Real-Life Traffic For testing and verification, we have applied the ruleset optimiser to test-traffic from different real-life SIP VoIP providers. Traffic was recorded for several hours, resulting altogether in about four Gbyte of tracefile data. As a simple test, we generate for each traffic sample an input ruleset R i that matches every single packet. We generated 6 different samples from that traffic to be used as R i : ruleset A - C containing each 450, 600, and 1034 IPv4 address rules, respectively. Furthermore, rulesets D - F with 51, 86, 107 SIP UA rules. We have developed a prototype optimiser written in Perl to input these 6 samples as R i. The program optimises the ruleset and generates R o, including the calculation of F p and F n. The optimiser runs on a 1 Ghz Linux machine with 512 MByte RAM. For the tests, we arbitrarily set σ max = 20 and η = 20. The result is shown in figure 5. The inaccuracy index µ is calculated for each values for χ ranging from 1 to 254. Here, we

110 Ruleset A Ruleset B Ruleset C Inaccurancy index Threshold X Figure 5: The inaccuracy index of outcome ruleset varies according to threshold χ for ruleset A and B, when η = 20, σ max = 20 can clearly see the optimum value for χ as a local minimum. For example, for ruleset A, the optimum value for χ is around 38. Setting the wrong value for χ, either by setting it to low or to high causes the accuracy to degrate. Moreover, the optimum value for χ changes for different rulesets. To calculate the false positive F p for the SIP UA rules, we arbitrarily assume that each multi-mapped rule contains 50 entries at most. For instance, if a group of 5 single-mapped UA rules are merged into one multi-mapped rule, the False positive is 50-5 = 45. In this way, we can calculate F p for the given R o. Figure 6 shows our test result with ruleset D, E and F. The result is similar to the previous one. 5.2 Optimisation To find the optimum value for χ, we looped over each value of χ to find out the local minimum. This is a very time-consuming process and finding the right value for χ is an NPhard problem [15]. We therefore apply a high efficient heuristic algorithm to calculate the best value for χ in reasonable time. Here, we employ Golden Section Search (GSS) [16] to solve this problem. GSS is a simple and efficient 1-dimensional optimisation method which does not require derivatives. It can deal with our unimodal objective by rapidly narrowing our search interval and still finding the optimum result. We ran several calculations of the optimisation process both with the full loop search and with GSS optimisation applied. Seen in table 2, we can see that GSS can improve calculation time by around 90% with our script prototype. While reducing calculation

111 6. Related Works Ruleset D Ruleset E Ruleset F 1600 Inaccurancy index Threshold X Figure 6: The inaccuracy index of outcome ruleset varies according to threshold χ for ruleset C, when η = 20, σ max = 20 Table 2: Calculation Time comparison of the algorithms, T2 with GSS applied Ruleset T1 (s) T2 (s) Solution with GSS A χ optimal = 38 B χ optimal = 46 C χ optimal = 97 D χ optimal = 3 E χ optimal = 5 F χ optimal = 3 time, the accuracy of the resulting µ is not influenced by the application of GSS. 6 Related Works Researchers have proposed different ways to improve the performance of a firewall, mainly two approaches exist: improving performance by generating an optimised order of firewall rules or reducing the size of the ruleset. A proper order of rules is helpful to reduce the number of rule comparisons required per packet. Fulp [17], or Hamed et al. [18] propose such a mechanism based on different metrics, like traffic statistics. However, they do not reduce the size of the ruleset. Like our work, researchers have proposed mechanism to reduce the overall ruleset size.

112 98 Gupta [19] introduces forward or backward redundant rules that can be eliminated from the ruleset. A backward redundant rules is defined as an existing rule r appearing earlier than r, which is a subset of r. On the other hand, if there exists a rule r appearing after r, which is a subset of r, it is forward redundant. Liu [20] proposes further methods to eliminate backward and forward redundant rules. Similar to our work, Yoon et al. [21] propose an aggressive reduction algorithm to find a group of rules and replace it with a smaller new group. However, their work does not to allow the space of the generated ruleset to differ from the original one, hence it is not guaranteed that the generated ruleset will be significantly smaller. All of these propositions work only at the network level and would need further enhancements to work in SIP ALGs. 7 Conclusion and Future Work Flooding attacks will be a severe threat for Internet services based on SIP. While new methods are currently designed to counter these threats, all components of a security solution have to be prepared to take the excessive overload traffic that is generated by this threat. In this work we have proposed a new firewall operation algorithm to balance between optimum security and optimum performance, as both aspects together are almost impossible to achieve. So, instead of trying to prevent and deny every uncommon message, we accept a small fraction of these messages and thus ensure the ongoing operation of the service. Our algorithm is only a first step in this direction. We have shown a way to reduce the load at the firewall and still retaining most of the firewall s effectiveness. The feasibility of this solution has shown with real-life traffic captures. However, our next step would be to actually apply this algorithm to a firewall and evaluate its behaviour with ongoing flooding traffic. Depending on the situation, there is also optimisation potential for the proposed parameters of the algorithm e.g., by taking different message fields into account or utilise the Time-to-Live property for a more accurate calculation of the most import rules in the firewall. Performance of the calculation can also be increased by iteratively calculating the new optimised ruleset, instead of a complete recalculation each time new rules are inserted. References [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Spark, M. Handley, and E. Schooler. Session Initiation Protocol, [2] IP Multimedia Subsystem (IMS); Stage 2. Technical Report TS (Release 8), 3GPP, 2007.

113 REFERENCES 99 [3] VoIP Security and Privacy Threat Taxonomy. Technical Report Public Release 1.0, VOIPSA, October [4] D. Geneiatakis, T. Dagiuklas, G. Kambourakis, C. Lambrinoudakis, S. Gritzalis, S. Ehlert, and D. Sisalem. Survey of Security Vulnerabilities in Session Initiation Protocol. IEEE Communications Surveys and Tutorials, 8(3):68 81, July [5] J. Fiedler, T. Kupka, S. Ehlert, T. Magedanz, and D. Sisalem. VoIP Defender: Highly Scalable SIP-based Security Architecture. In Principles, Systems and Applications of IP Telecommunications (IPTComm 2007), New York, USA, July [6] M. Nassar, S. Niccolini, R. State, and T. Ewald. Holistic VoIP Intrusion Detection and Prevention System. In Principles, Systems and Applications of IP Telecommunications (IPTComm 2007), New York, USA, July [7] Borderware SIPassure VoIP / SIP Security Solution. [8] W. Stallings. Network Security Essentials: Applications and Standards, 3rd edition. Pearson Education, [9] I. Green, T. Raz, and M. Zviran. Analysis of Active Intrusion Prevention Data for Predicting Hostile Activity in Computer Networks. Communications of the ACM, [10] H. Sengar, D. Wijesekera, H. Wang, and S. Jajodia. Fast Detection of Denial of Service Attacks on IP Telephone. In 14th IEEE International Workshop on Quality of Service, New Haven, CT, USA, June [11] S. Ehlert, C. Wang, T. Magedanz, and D. Sisalem. Specification-based Denial-of- Service Detection for SIP Voice-over-IP Networks. In Third International Conference on Internet Monitoring and Protection (ICIMP2008), Bucharest, Romania, July [12] Y. Qiu, J. Zhou, and F. Bao. Design and Optimize Firewalls for Mobile Networks. In Proceedings of IEEE 60th Vehicular Technology Conference, [13] M. Luo, T. Peng, and C. Leckie. CPU-based DoS Attacks Against SIP Servers. In IEEE/IFIP Network Operations and Management Symposium (NOMS 2008), Salvador, Bahia, Brazil, April [14] B. Potter. Open source firewall alternatives. Network Security, 2006(1), January [15] M. R. Garey and D. S. Johnson. Computers and Intractability: A Guide to the Theory of NP-Completeness. WH Freeman Co., New York, NY, USA, [16] R. L. Rardin. Optimization in Operations Research. Prentice Hall, 1998.

114 100 [17] E. W. Fulp. Optimization of Network Firewall Policies Using Ordered Sets and Directed Acyclical Graphs. In Proceedings of IEEE Internet Management Conference, [18] H. Hamed and E. Al-Shaer. Dynamic Rule-ordering Optimization for High-speed Firewall Filtering. In Proceedings of the 2006 ACM Symposium on Information, Computer and Communications Security, [19] P. Gupta and N. McKeown. Packet Classification on Multiple Fields. In Conference on Application, Technologies, Architectures and Protocols for Computer Communication, [20] A. X. Liu and M. G. Gouda. Removing Redundancy from Packet Classifiers. In Proceedings of ACM SIGCOMM, [21] M. Yoon, S. Chen, and Z. Zhang. Reducing the size of rule set in a firewall. In Proceedings of IEEE International Conference on Communications, ICC 07, 2007.

115 Paper IV Revealing the calling history on SIP VoIP systems by timing attacks Reprinted from Proceedings of the 4 th International Conference on Availability, Reliability and Security (ARES 2009), IEEE Press Fukuoka, Japan, March 2009

116

117 Revealing the calling history on SIP VoIP systems by timing attacks Ge Zhang, Simone Fischer-Hübner, Leonardo A. Martucci, and Sven Ehlert {ge.zhang, simone.fischer-huebner, Abstract Many emergent security threats which did not exist in the traditional telephony network are introduced in SIP VoIP services. To provide high-level security assurance to SIP VoIP services, an inter-domain authentication mechanism is defined in RFC However, this mechanism introduces another vulnerability: a timing attack which can be used for effectively revealing the calling history of a group of VoIP users. The idea here is to exploit the certificate cache mechanisms supported by SIP VoIP infrastructures, in which the certificate from a caller s domain will be cached by the callee s proxy to accelerate subsequent requests. Therefore, SIP processing time varies depending whether the two domains had been into contact beforehand or not. The attacker can thus profile the calling history of a SIP domain by sending probing requests and observing the time required for processing. The result of our experiments demonstrates that this attack can be easily launched. We also discuss countermeasures to prevent such attacks. 1 Introduction Voice over IP (VoIP) is an innovative technology which enables its users to place calls via Internet-based infrastructures instead of traditional Public Switched Telephone Networks (PSTN). In recent years, VoIP has attracted considerable commercial interest. One of the important reasons is its low-cost. By allowing voice to be converted into packets and transported over packet-switched networks, the consolidated network serves as a foundation for enterprises to reduce operating expenses. It is predictable that in the near future, many enterprises will deploy their own VoIP infrastructures instead of using traditional PSTN equipment. The Session Initiation Protocol (SIP) [1] has been widely adopted as the signaling protocol to handle VoIP services. Similarly to the addressing scheme, SIP VoIP users are logically grouped by means of domains. Each domain provides telephony services to its own SIP users independently. The domains also cooperate for inter-domain telephony services.

118 104 Contrary to VoIP, security threats are considered minimal in PSTN. This is achieved by not only using a closed networking environment, but also independent protocols and infrastructures. In contrast, launching an attack on VoIP is much simpler because VoIP services are based on an open environment shared with other existing Internet-based services. Therefore, VoIP can suffer from similar security threats as any other Internet services. In order to provide a trusted inter-domain context, an inter-domain authentication mechanism was proposed in RFC 4474 [2]. In this paper we present a timing attack aiming to disclose the calling history of a SIP domain. The disclosed information is not the calling history of a single user, but of a whole SIP domain. The calling history in this paper refers to whether a domain contacted another specific domain recently. This calling history is frequently regarded as confidential business information since other information can be predicted from it [3 5]. If such a domain is bound to a company, an attacker can aggregate the calling history during a period of time of the company. The calling history might be especially useful to predict future actions within the company. It can also reveal the company s customer base. This vulnerability is caused by the certificate cache introduced in the inter-domain authentication mechanism. The proxy cache stores downloaded certificates to speed up the processing of subsequent SIP requests. Therefore, the time required for processing a SIP request varies whether the corresponding certificate has already been cached or not. Thus, this timing attack is based on two factors: first, the certificate of the caller s domain will be cached by the callee s proxy for each call; Second, for further requests coming from the same domain, processing will take less time since there is no need for the callee s proxy to download the certificate again. In this way, an attacker can generate crafted probing requests to the victim proxy and retrieve the calling history of a domain by observing processing time. The result of our experiments show that this attack is easy to launch. To defend against this timing attack, we propose a special delay solution to uniformize the processing time which affects legal users only by a minimum degree. This paper is organized as follows. Section 2 provides information on SIP and its mechanism for identity management. In section 3, we describe in detail how and why the timing attack works in the SIP VoIP context and we present experimental results that demonstrate the severeness of this threat. Several solutions to counteract such a timing attack will be proposed in section 4. Section 5 shows an overview of related work. Finally, we provide conclusions in section 6. 2 Voice over IP using SIP SIP [1] works as a signaling protocol at the application layer of the TCP/IP model. It establishes or terminates media sessions between two parties. A general SIP infrastructure consists of User Agents (UA), and several SIP servers such as registrar servers, redirect servers and SIP proxies. Here, UA and SIP proxy are more related to the scope of this

119 2. Voice over IP using SIP 105 Figure 1: An overview of essential components on SIP infrastructures paper. A UA generates, terminates, or accepts SIP requests and responses. SIP proxies forward SIP requests and responses in the SIP network. SIP users are indicated by means of Uniform Resource Identifiers (URI), consisting of a pair of user name and domain name, (e.g., sip:alice@abc.co.uk), which is similar to the format. Therefore, SIP users logically belong to different domains, and there are one or more SIP proxies in charge of processing SIP requests for each domain. The general SIP-based telephony calling setup is shown in Figure 1. There are two SIP users in this scenario: Alice, a caller, is located in the domain abc.co.uk and Bob, a callee, is located in the domain xyz.com. First, Alice sends an INVITE request to its local proxies at (abc.co.uk). Then, the local proxies at (abc.co.uk) will forward this INVITE request to the remote proxies at (xyz.com). Then, the INVITE request will be delivered to Bob. If Bob would like to accept the request from Alice, he will reply with a 200 OK message back through the proxies. After Alice sends an ACK message to confirm the request, the signaling handshaking is accomplished. Finally, Alice and Bob will build a media session independently without the assistant of proxies, so that they can talk in this session. Inter-domain Authentication in SIP: Many emerging attacks and spams towards VoIP have been reported recently [6 8]. Attackers and spammers frequently spoof identities in order to be untraceable. Therefore, an overall authentication mechanism is needed to identify callers. Generally, SIP proxies identify their users in their home domain. However, historically, there was no mechanism to identify callers in an inter-domain context. If the caller and callee are not in the same domain, the callee s proxy cannot guarantee that the received request is really sent from that domain as announced. A solution based on certificates for originator authentication is proposed in RFC 4474 [2]. The purpose is to assist the SIP proxies to authenticate the source of inter-domain SIP requests. As a consequence, forging the source of a SIP request is becoming more difficult. The method is shown in Figure 2 and described as follows. For each outgoing request to other domains, the SIP proxy in the caller s domain generates a hash digest covering several header fields (e.g., To, From, etc) and payload of this

120 106 Figure 2: The mechanism of identity management as defined in RFC 4474 request. The digest is signed by the caller s proxy with its private key. The signature is encoded in a new header field Identity and included into the original SIP request. Furthermore, the SIP proxy attaches another new header field Identity-info, which contains the URL where the certificate can be fetched from. Then, this SIP request will be forwarded to the callee s domain. For each incoming request from other domains, the SIP proxy in the callee s domain will first download the certificate according to the URL within the Identity-info field. After that, a hash digest of the incoming request will be re-computed by the proxy. The public key retrieved from the certificate will be used to decrypt the signature contained in the Identity field. Finally, the result will be used to compare both hash digests. The verification is successful only if the two values are equal, otherwise, the verification fails and the proxy will reply with a response indicating a failed verification. A domain s certificate can be used to verify all requests from this domain. Since VoIP is a real-time service, repeatedly downloading certificates for each incoming request will have a negative impact on performance. Thus, a certificate cache mechanism is recommended in RFC 4474 [2]. In this way, the downloaded certificate will be cached in the local proxy for a while. Therefore, for the next incoming request originated from the same domain, the proxy will extract the certificate from the local cache instead of downloading it again. 3 Timing Attack 3.1 Threat model The objective of the timing attack is to retrieve confidential information by exploiting a protocol design flaw. The timing attack described in this paper reveals whether someone

121 3. Timing Attack 107 Figure 3: The working flow shows the comparison of time cost in two situations, one with the certificate already cached, another not from a domain had been in contact recently with someone from another domain. The disclosed information is not the exact identities of caller and callee, but their domains. The attacker can be an outsider who does not belong to any domain and does not need to authenticate himself on any domain. The attacker just needs Internet access to send packets to SIP proxies. Although this kind of attack can be launched against any SIP domain which is deployed according to RFC 3261 and RFC 4474, it is most attractive against enterprises SIP domains. Generally, two enterprises frequently communicate when they have a business connection. Therefore, the calling history might reveal such potential business connections. Companies usually have an interest to keep their business relationship confidential. In particular, companies that secretly talk about mergings would like to keep this confidential in regard to the outside world. Therefore, the disclosure of the calling history might cause direct or indirect economic losses for a company. In the traditional PSTN context, the calling history of an enterprise is kept secret by the telephony operator, a trusted third party in a closed context. It needs more efforts for an external attacker to gather this information. However, in the SIP VoIP context, the telephony service is integrated with other ICT-based infrastructures based on an open environment, which simplifies the attack. The details of how to launch a timing attack will be shown in the following sections. 3.2 Attacking method The inter-domain authentication defined in RFC 4474 is recommended to be deployed in future SIP VoIP services to prevent spam [9]. However, this mechanism causes other vulnerabilities. As we mentioned before, for each incoming inter-domain request, the SIP proxy should verify whether the request is really from the domain as it was announced in

122 108 the request. To get the public key for verification, the callee s SIP proxy has to download the certificate according to the URL in the field of the Identity-info header, either through an HTTP or an HTTPS connection. Since the downloaded domain certificate is valid to authenticate all the requests from the same domain, there is no need to re-download the certificate again for further requests from the same domain. The downloaded certificate will be retained in the certificate cache at the callee s proxy for a while in favor of the next request. In this way, the content of certificate cache can reveal the calling history in form of which domains contacted this domain recently. For example, if domain A contacted domain B recently, the certificate of domain A should be found in the certificate cache at domain B s proxy. Therefore, the attacker can infer the calling history of domain A when he knows whose certificates are cached at domain A s proxy. We introduce a timing attack to reveal the content of the certificate cache. As mentioned before, the processing time for each request varies, depending on whether the certificate of a domain is cached by the victim proxy or not. If the certificate of the domain has already been stored in the local cache, the SIP proxy can use it without downloading it again. Then, the total processing time for such a request is relatively short. Otherwise, the victim proxy has to download the certificate, which takes more time. Therefore, the attacker first selects a victim domain as the attacking target. He also selects some domains that might have connections with the victim domain. We call these domains testing domains. Next, he can deliberately generate fake requests which seem to come from the testing domains, and then send these requests to the proxy in the victim domain. We call these requests probing requests. When the victim proxy receives the probing requests, it will verify them to see whether they are really sent from a testing domain. Therefore, the victim proxy will verify the requests using the certificates of testing domains, either extracting from the local cache or downloading from the remote certificate provider. Since the attacker does not own the private key of the testing domains, he cannot generate the correct signature. Hence, the verification will fail, and the victim proxy will reply with a verification failed response to the attacker. To ensure that such a response will be delivered back to the attacker, and not to the testing domains, the attacker can simply encode his IP address in the first Via field 1. In this way, the attacker is able to find out whether the testing domains contacted the victim domains recently by comparing the time interval between the request and the response. For example, given a victim domain victim-domain.com and a testing domain testing-domain.com. If an attacker tries to find out whether these two domains had contacted each other recently, he can send a probing request to the SIP proxy in victim-domain.com like Figure 4, with the Identity-info filled with the URL of testing-domain s certificate. And the first Via field is encoded with the IP address of 1 A Via header field indicates the location where the response is to be sent. In some cases, a SIP request has to be passed through several intermediate hops between two domains and the IP addresses of the intermediate hops will be recorded in the Via field in favor of routing back the corresponding response. Therefore, it is natural if the IP address in the Via field does not belong to the caller s domain.

123 3. Timing Attack 109 Figure 4: A sample probing request the attacker. The signature in the Identity field is randomly created. Nevertheless, the attacker does not care whether the request can be successfully authenticated, instead, he is just concerned about the response time of this request. How the victim proxy handles the probing requests in detail is shown in Figure 3. We define: t sum : The total time for processing a probing request. t 1 : The time for the probing request transmitting from the attacker to the victim proxy. t 2 : The time for the request pre-processing, including message parsing, etc. t 3 : The time for the verification of the caller s identity. t 4 : The time for the response transmitting from the victim proxy to the attacker. t d : The time for downloading the certificate through an HTTP or an HTTPS connection. In Figure 3(a), the attacker first sends a probing request to the victim proxy. Secondly, the victim proxy will pre-process the message. Then, since the related certificate has already been cached in the victim proxy, there is no need to download it. Thus, the victim proxy will use the cached certificate to verify the request directly. The verification should fail, and the victim proxy will reply with the failure reason to the attacker. The total time is t sum = t 1 + t 2 + t 3 + t 4 The procedure shown in Figure 3(b) is similar to the one in Figure 3(a). The only difference is that the victim proxy has to download the certificate remotely since the required certificate has not been cached yet. The total time for processing the request is t sum = t 1 + t 2 + t d + t 3 + t 4

Unwanted Traffic and Information Disclosure in VoIP Networks

Unwanted Traffic and Information Disclosure in VoIP Networks Unwanted Traffic and Information Disclosure in VoIP Networks Threats and Countermeasures Ge Zhang Faculty of Economic Sciences, Communication and IT Computer Science Dissertation Karlstad University Studies

More information

Authentication and Authorisation for Integrated SIP Services in Heterogeneous Environments 1

Authentication and Authorisation for Integrated SIP Services in Heterogeneous Environments 1 Authentication and Authorisation for Integrated SIP Services in Heterogeneous Environments 1 Dorgham Sisalem, Jiri Kuthan Fraunhofer Institute for Open Communication Systems (FhG Fokus) Kaiserin-Augusta-Allee

More information

INTRODUCTION OF VOIP AND SIP SECURITY 2

INTRODUCTION OF VOIP AND SIP SECURITY 2 INTRODUCTION OF VOIP AND SIP SECURITY 2 Ge Zhang, Karlstad University May, 2009 Outline Review SIP vulnerabilities by external infrastructures DNS server as an example Confidentiality Integrity Availability

More information

VOICE OVER IP SECURITY

VOICE OVER IP SECURITY VOICE OVER IP SECURITY February 2008 The Government of the Hong Kong Special Administrative Region The contents of this document remain the property of, and may not be reproduced in whole or in part without

More information

A Brief Overview of VoIP Security. By John McCarron. Voice of Internet Protocol is the next generation telecommunications method.

A Brief Overview of VoIP Security. By John McCarron. Voice of Internet Protocol is the next generation telecommunications method. A Brief Overview of VoIP Security By John McCarron Voice of Internet Protocol is the next generation telecommunications method. It allows to phone calls to be route over a data network thus saving money

More information

Session Initiation Protocol Security Considerations

Session Initiation Protocol Security Considerations Session Initiation Protocol Security Considerations Sami Knuutinen Helsinki University of Technology Department of Computer Science and Engineering May 28, 2003 Abstract Session Initiation Protocol (SIP)

More information

Multimedia Communication in the Internet. SIP Security Threads. Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS 1

Multimedia Communication in the Internet. SIP Security Threads. Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS 1 Multimedia Communication in the Internet SIP Security Threads Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS 1 Denial of Service Prevent service availability Software vulnerabilities

More information

A Comparative Study of Signalling Protocols Used In VoIP

A Comparative Study of Signalling Protocols Used In VoIP A Comparative Study of Signalling Protocols Used In VoIP Suman Lasrado *1, Noel Gonsalves *2 Asst. Prof, Dept. of MCA, AIMIT, St. Aloysius College (Autonomous), Mangalore, Karnataka, India Student, Dept.

More information

Unregister Attacks in SIP

Unregister Attacks in SIP Unregister Attacks in SIP Anat Bremler-Barr Ronit Halachmi-Bekel Interdisciplinary Center Herzliya Email: {bremler,halachmi.ronit}@idc.ac.il Jussi Kangasharju Darmstadt University of Technology jussi@tk.informatik.tu-darmstadt.de

More information

A Call Conference Room Interception Attack and its Detection

A Call Conference Room Interception Attack and its Detection A Call Conference Room Interception Attack and its Detection Nikos Vrakas 1, Dimitris Geneiatakis 2 and Costas Lambrinoudakis 1 1 Department of Digital Systems, University of Piraeus 150 Androutsou St,

More information

SIP, Session Initiation Protocol used in VoIP

SIP, Session Initiation Protocol used in VoIP SIP, Session Initiation Protocol used in VoIP Page 1 of 9 Secure Computer Systems IDT658, HT2005 Karin Tybring Petra Wahlund Zhu Yunyun Table of Contents SIP, Session Initiation Protocol...1 used in VoIP...1

More information

Chapter 2 PSTN and VoIP Services Context

Chapter 2 PSTN and VoIP Services Context Chapter 2 PSTN and VoIP Services Context 2.1 SS7 and PSTN Services Context 2.1.1 PSTN Architecture During the 1990s, the telecommunication industries provided various PSTN services to the subscribers using

More information

User authentication in SIP

User authentication in SIP User authentication in SIP Pauli Vesterinen Helsinki University of Technology pjvester@cc.hut.fi Abstract Today Voice over Internet Protocol (VoIP) is used in large scale to deliver voice and multimedia

More information

Firewall-Friendly VoIP Secure Gateway and VoIP Security Issues

Firewall-Friendly VoIP Secure Gateway and VoIP Security Issues Firewall-Friendly VoIP Secure Gateway and VoIP Security Issues v Noriyuki Fukuyama v Shingo Fujimoto v Masahiko Takenaka (Manuscript received September 26, 2003) IP telephony services using VoIP (Voice

More information

Session Initiation Protocol (SIP) The Emerging System in IP Telephony

Session Initiation Protocol (SIP) The Emerging System in IP Telephony Session Initiation Protocol (SIP) The Emerging System in IP Telephony Introduction Session Initiation Protocol (SIP) is an application layer control protocol that can establish, modify and terminate multimedia

More information

VoIP some threats, security attacks and security mechanisms. Lars Strand RiskNet Open Workshop Oslo, 24. June 2009

VoIP some threats, security attacks and security mechanisms. Lars Strand RiskNet Open Workshop Oslo, 24. June 2009 VoIP some threats, security attacks and security mechanisms Lars Strand RiskNet Open Workshop Oslo, 24. June 2009 "It's appalling how much worse VoIP is compared to the PSTN. If these problems aren't fixed,

More information

Securing VoIP Networks using graded Protection Levels

Securing VoIP Networks using graded Protection Levels Securing VoIP Networks using graded Protection Levels Andreas C. Schmidt Bundesamt für Sicherheit in der Informationstechnik, Godesberger Allee 185-189, D-53175 Bonn Andreas.Schmidt@bsi.bund.de Abstract

More information

Asymetrical keys. Alices computer generates a key pair. A public key: XYZ123345 (Used to encrypt) A secret key: ABC98765 (Used to decrypt)

Asymetrical keys. Alices computer generates a key pair. A public key: XYZ123345 (Used to encrypt) A secret key: ABC98765 (Used to decrypt) Encryption keys Symmetrical keys Same key used for encryption and decryption Exchange of symmetrical keys between parties difficult without risk of interception Asymmetrical keys One key for encryption

More information

Overview of VoIP Systems

Overview of VoIP Systems 2 Overview of VoIP Systems In their simplest form, Voice over IP protocols simply enable two (or more) devices to transmit and receive real-time audio traffic that allows their respective users to communicate.

More information

Multimedia Communication in the Internet. SIP: Advanced Topics. Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS

Multimedia Communication in the Internet. SIP: Advanced Topics. Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS Multimedia Communication in the Internet SIP: Advanced Topics Dorgham Sisalem, Sven Ehlert Mobile Integrated Services FhG FOKUS SIP and NAT NAT Concept NAT = Network Address Translation Share one IP address

More information

A Lightweight Secure SIP Model for End-to-End Communication

A Lightweight Secure SIP Model for End-to-End Communication A Lightweight Secure SIP Model for End-to-End Communication Weirong Jiang Research Institute of Information Technology, Tsinghua University, Beijing, 100084, P.R.China jwr2000@mails.tsinghua.edu.cn Abstract

More information

7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security?

7 Network Security. 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework. 7.5 Absolute Security? 7 Network Security 7.1 Introduction 7.2 Improving the Security 7.3 Internet Security Framework 7.4 Firewalls 7.5 Absolute Security? 7.1 Introduction Security of Communications data transport e.g. risk

More information

Media Gateway Controller RTP

Media Gateway Controller RTP 1 Softswitch Architecture Interdomain protocols Application Server Media Gateway Controller SIP, Parlay, Jain Application specific Application Server Media Gateway Controller Signaling Gateway Sigtran

More information

A Novel Approach for Evaluating and Detecting Low Rate SIP Flooding Attack

A Novel Approach for Evaluating and Detecting Low Rate SIP Flooding Attack A Novel Approach for Evaluating and Detecting Low Rate SIP Flooding Attack Abhishek Kumar Department of Computer Science and Engineering-Information Security NITK Surathkal-575025, India Dr. P. Santhi

More information

An Overview on Security Analysis of Session Initiation Protocol in VoIP network

An Overview on Security Analysis of Session Initiation Protocol in VoIP network An Overview on Security Analysis of Session Initiation Protocol in VoIP network Tarendra G. Rahangdale 1, Pritish A. Tijare 2, Swapnil N.Sawalkar 3 M.E (Pursuing) 1, Associate Professor 2, Assistant Professor

More information

Basic Vulnerability Issues for SIP Security

Basic Vulnerability Issues for SIP Security Introduction Basic Vulnerability Issues for SIP Security By Mark Collier Chief Technology Officer SecureLogix Corporation mark.collier@securelogix.com The Session Initiation Protocol (SIP) is the future

More information

SIP SECURITY WILEY. Dorgham Sisalem John Floroiu Jiri Kuthan Ulrich Abend Henning Schulzrinne. A John Wiley and Sons, Ltd.

SIP SECURITY WILEY. Dorgham Sisalem John Floroiu Jiri Kuthan Ulrich Abend Henning Schulzrinne. A John Wiley and Sons, Ltd. SIP SECURITY Dorgham Sisalem John Floroiu Jiri Kuthan Ulrich Abend Henning Schulzrinne WILEY A John Wiley and Sons, Ltd., Publication Foreword About the Authors Acknowledgment xi xiii xv 1 Introduction

More information

Chapter 10 Session Initiation Protocol. Prof. Yuh-Shyan Chen Department of Computer Science and Information Engineering National Taipei University

Chapter 10 Session Initiation Protocol. Prof. Yuh-Shyan Chen Department of Computer Science and Information Engineering National Taipei University Chapter 10 Session Initiation Protocol Prof. Yuh-Shyan Chen Department of Computer Science and Information Engineering National Taipei University Outline 12.1 An Overview of SIP 12.2 SIP-based GPRS Push

More information

Security. Contents. S-72.3240 Wireless Personal, Local, Metropolitan, and Wide Area Networks 1

Security. Contents. S-72.3240 Wireless Personal, Local, Metropolitan, and Wide Area Networks 1 Contents Security requirements Public key cryptography Key agreement/transport schemes Man-in-the-middle attack vulnerability Encryption. digital signature, hash, certification Complete security solutions

More information

VOICE OVER IP (VOIP) TO ENTERPRISE USERS GIOTIS KONSTANTINOS

VOICE OVER IP (VOIP) TO ENTERPRISE USERS GIOTIS KONSTANTINOS VOICE OVER IP (VOIP) TO ENTERPRISE USERS GIOTIS KONSTANTINOS Master of Science in Networking and Data Communications THESIS Thesis Title Voice over IP (VoIP) to Enterprise Users Dissertation submitted

More information

Client Server Registration Protocol

Client Server Registration Protocol Client Server Registration Protocol The Client-Server protocol involves these following steps: 1. Login 2. Discovery phase User (Alice or Bob) has K s Server (S) has hash[pw A ].The passwords hashes are

More information

Securing SIP Trunks APPLICATION NOTE. www.sipera.com

Securing SIP Trunks APPLICATION NOTE. www.sipera.com APPLICATION NOTE Securing SIP Trunks SIP Trunks are offered by Internet Telephony Service Providers (ITSPs) to connect an enterprise s IP PBX to the traditional Public Switched Telephone Network (PSTN)

More information

Prevention of Anomalous SIP Messages

Prevention of Anomalous SIP Messages International Journal of Future Computer and Communication, Vol., No., October 03 Prevention of Anomalous SIP Messages Ming-Yang Su and Chung-Chun Chen Abstract Voice over internet protocol (VoIP) communication

More information

TECHNICAL CHALLENGES OF VoIP BYPASS

TECHNICAL CHALLENGES OF VoIP BYPASS TECHNICAL CHALLENGES OF VoIP BYPASS Presented by Monica Cultrera VP Software Development Bitek International Inc 23 rd TELELCOMMUNICATION CONFERENCE Agenda 1. Defining VoIP What is VoIP? How to establish

More information

A Lightweight Countermeasure to Cope with Flooding Attacks Against Session Initiation Protocol

A Lightweight Countermeasure to Cope with Flooding Attacks Against Session Initiation Protocol A Lightweight Countermeasure to Cope with Flooding Attacks Against Session Initiation Protocol Intesab Hussain, Soufiene Djahel, Dimitris Geneiatakis ±, and Farid Naït-Abdesselam LIPADE, University of

More information

SIP : Session Initiation Protocol

SIP : Session Initiation Protocol : Session Initiation Protocol EFORT http://www.efort.com (Session Initiation Protocol) as defined in IETF RFC 3261 is a multimedia signaling protocol used for multimedia session establishment, modification

More information

How To Attack A Phone With A Billing Attack On A Sip Phone On A Cell Phone On An At&T Vpn Vpn Phone On Vnet.Com (Vnet) On A Pnet Vnet Vip (Sip)

How To Attack A Phone With A Billing Attack On A Sip Phone On A Cell Phone On An At&T Vpn Vpn Phone On Vnet.Com (Vnet) On A Pnet Vnet Vip (Sip) Billing Attacks on SIP-Based VoIP Systems Ruishan Zhang, Xinyuan Wang, Xiaohui Yang, Xuxian Jiang Department of Information and Software Engineering George Mason University, Fairfax, VA 22030, USA {rzhang3,

More information

Internet Security. Internet Security Voice over IP. Introduction. ETSF10 Internet Protocols 2011-11-22. ETSF10 Internet Protocols 2011

Internet Security. Internet Security Voice over IP. Introduction. ETSF10 Internet Protocols 2011-11-22. ETSF10 Internet Protocols 2011 Internet Security Voice over IP ETSF10 Internet Protocols 2011 Kaan Bür & Jens Andersson Department of Electrical and Information Technology Internet Security IPSec 32.1 SSL/TLS 32.2 Firewalls 32.4 + Voice

More information

A VoIP Traffic Monitoring System based on NetFlow v9

A VoIP Traffic Monitoring System based on NetFlow v9 A VoIP Traffic Monitoring System based on NetFlow v9 Chang-Yong Lee *1, Hwan-Kuk Kim, Kyoung-Hee Ko, Jeong-Wook Kim, Hyun- Cheol Jeong Korea Information Security Agency, Seoul, Korea {chylee, rinyfeel,

More information

SS7 & LTE Stack Attack

SS7 & LTE Stack Attack SS7 & LTE Stack Attack Ankit Gupta Black Hat USA 2013 akg0x11@gmail.com Introduction With the evolution of IP network, Telecom Industries are using it as their core mode of communication for their network

More information

EE4607 Session Initiation Protocol

EE4607 Session Initiation Protocol EE4607 Session Initiation Protocol Michael Barry michael.barry@ul.ie william.kent@ul.ie Outline of Lecture IP Telephony the need for SIP Session Initiation Protocol Addressing SIP Methods/Responses Functional

More information

An outline of the security threats that face SIP based VoIP and other real-time applications

An outline of the security threats that face SIP based VoIP and other real-time applications A Taxonomy of VoIP Security Threats An outline of the security threats that face SIP based VoIP and other real-time applications Peter Cox CTO Borderware Technologies Inc VoIP Security Threats VoIP Applications

More information

NAT TCP SIP ALG Support

NAT TCP SIP ALG Support The feature allows embedded messages of the Session Initiation Protocol (SIP) passing through a device that is configured with Network Address Translation (NAT) to be translated and encoded back to the

More information

A Model-based Methodology for Developing Secure VoIP Systems

A Model-based Methodology for Developing Secure VoIP Systems A Model-based Methodology for Developing Secure VoIP Systems Juan C Pelaez, Ph. D. November 24, 200 VoIP overview What is VoIP? Why use VoIP? Strong effect on global communications VoIP will replace PSTN

More information

Vesselin Tzvetkov, Holger Zuleger {vesselin.tzvetkov, holger.zuleger}@arcor.net Arcor AG&Co KG, Alfred-Herrhausen-Allee 1, 65760 Eschborn, Germany

Vesselin Tzvetkov, Holger Zuleger {vesselin.tzvetkov, holger.zuleger}@arcor.net Arcor AG&Co KG, Alfred-Herrhausen-Allee 1, 65760 Eschborn, Germany Service Provider implementation of SIP regarding security Vesselin Tzvetkov, Holger Zuleger {vesselin.tzvetkov, holger.zuleger}@arcor.net Arcor AG&Co KG, Alfred-Herrhausen-Allee 1, 65760 Eschborn, Germany

More information

SIP and VoIP 1 / 44. SIP and VoIP

SIP and VoIP 1 / 44. SIP and VoIP What is SIP? What s a Control Channel? History of Signaling Channels Signaling and VoIP Complexity Basic SIP Architecture Simple SIP Calling Alice Calls Bob Firewalls and NATs SIP URIs Multiple Proxies

More information

AV@ANZA Formación en Tecnologías Avanzadas

AV@ANZA Formación en Tecnologías Avanzadas SISTEMAS DE SEÑALIZACION SIP I & II (@-SIP1&2) Contenido 1. Why SIP? Gain an understanding of why SIP is a valuable protocol despite competing technologies like ISDN, SS7, H.323, MEGACO, SGCP, MGCP, and

More information

How to make free phone calls and influence people by the grugq

How to make free phone calls and influence people by the grugq VoIPhreaking How to make free phone calls and influence people by the grugq Agenda Introduction VoIP Overview Security Conclusion Voice over IP (VoIP) Good News Other News Cheap phone calls Explosive growth

More information

Security issues in Voice over IP: A Review

Security issues in Voice over IP: A Review www.ijecs.in International Journal Of Engineering And Computer Science ISSN:2319-7242 Volume 3 Issue 2 February, 2014 Page No. 3879-3883 Security issues in Voice over IP: A Review Rajni a, Preeti a, Ritu

More information

White paper. SIP An introduction

White paper. SIP An introduction White paper An introduction Table of contents 1 Introducing 3 2 How does it work? 3 3 Inside a normal call 4 4 DTMF sending commands in sip calls 6 5 Complex environments and higher security 6 6 Summary

More information

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream

Receiving the IP packets Decoding of the packets Digital-to-analog conversion which reproduces the original voice stream Article VoIP Introduction Internet telephony refers to communications services voice, fax, SMS, and/or voice-messaging applications that are transported via the internet, rather than the public switched

More information

A Model for Spam Prevention in IP Telephony Networks using Anonymous Verifying Authorities

A Model for Spam Prevention in IP Telephony Networks using Anonymous Verifying Authorities A Model for Spam Prevention in IP Telephony Networks using Anonymous Verifying Authorities N.J Croft and M.S Olivier April 2005 Information and Computer Security Architectures Research Group Department

More information

SIP: Protocol Overview

SIP: Protocol Overview SIP: Protocol Overview NOTICE 2001 RADVISION Ltd. All intellectual property rights in this publication are owned by RADVISION Ltd. and are protected by United States copyright laws, other applicable copyright

More information

This specification this document to get an official version of this User Network Interface Specification

This specification this document to get an official version of this User Network Interface Specification This specification describes the situation of the Proximus network and services. It will be subject to modifications for corrections or when the network or the services will be modified. Please take into

More information

This presentation discusses the new support for the session initiation protocol in WebSphere Application Server V6.1.

This presentation discusses the new support for the session initiation protocol in WebSphere Application Server V6.1. This presentation discusses the new support for the session initiation protocol in WebSphere Application Server V6.1. WASv61_SIP_overview.ppt Page 1 of 27 This presentation will provide an overview of

More information

A SIP based VOIP to avoid Vulnerabilities in designing VOIP network in Enterprise

A SIP based VOIP to avoid Vulnerabilities in designing VOIP network in Enterprise A SIP based VOIP to avoid Vulnerabilities in designing VOIP network in Enterprise K.Subhash Bhagavan #1, Kirankumar.P #2, MVSS Nagendranath#3, #1 Student, Sasi Institute of Technology and Engineering,

More information

Analysis of SIP Traffic Behavior with NetFlow-based Statistical Information

Analysis of SIP Traffic Behavior with NetFlow-based Statistical Information Analysis of SIP Traffic Behavior with NetFlow-based Statistical Information Changyong Lee, Hwankuk-Kim, Hyuncheol Jeong, Yoojae Won Korea Information Security Agency, IT Infrastructure Protection Division

More information

What is Web Security? Motivation

What is Web Security? Motivation brucker@inf.ethz.ch http://www.brucker.ch/ Information Security ETH Zürich Zürich, Switzerland Information Security Fundamentals March 23, 2004 The End Users View The Server Providers View What is Web

More information

Chapter 7 Transport-Level Security

Chapter 7 Transport-Level Security Cryptography and Network Security Chapter 7 Transport-Level Security Lectured by Nguyễn Đức Thái Outline Web Security Issues Security Socket Layer (SSL) Transport Layer Security (TLS) HTTPS Secure Shell

More information

Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs

Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Overview of Network Security The need for network security Desirable security properties Common vulnerabilities Security policy designs Why Network Security? Keep the bad guys out. (1) Closed networks

More information

Security vulnerabilities in the Internet and possible solutions

Security vulnerabilities in the Internet and possible solutions Security vulnerabilities in the Internet and possible solutions 1. Introduction The foundation of today's Internet is the TCP/IP protocol suite. Since the time when these specifications were finished in

More information

3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW

3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW 3.1 SESSION INITIATION PROTOCOL (SIP) OVERVIEW SIP is an application layer protocol that is used for establishing, modifying and terminating multimedia sessions in an Internet Protocol (IP) network. SIP

More information

Voice over IP Security

Voice over IP Security Voice over IP Security Patrick Park Cisco Press Cisco Press 800 East 96th Street Indianapolis, Indiana 46240 USA vii Contents Introduction xvii Part I VoIP Security Fundamentals 3 Chapter 1 Working with

More information

SIP: Ringing Timer Support for INVITE Client Transaction

SIP: Ringing Timer Support for INVITE Client Transaction SIP: Ringing Timer Support for INVITE Client Transaction Poojan Tanna (poojan@motorola.com) Motorola India Private Limited Outer Ring Road, Bangalore, India 560 037 Abstract-The time for which the Phone

More information

SIP and PSTN Connectivity. Jiri Kuthan, iptel.org sip:jiri@iptel.org September 2003

SIP and PSTN Connectivity. Jiri Kuthan, iptel.org sip:jiri@iptel.org September 2003 SIP and PSTN Connectivity Jiri Kuthan, iptel.org sip:jiri@iptel.org September 2003 Outline PSTN Gateways. PSTN2IP Demo Integration challenges: CLID Interdomain Trust Gateway Location Outlook: Reuse of

More information

Technical Means to Combat Spam in the VoIP Service

Technical Means to Combat Spam in the VoIP Service Section Four Technical Means to Combat Spam in the VoIP Service Spam refers in general to any unsolicited communication. Spam will also become one of the serious problems for multimedia communication in

More information

TLS and SRTP for Skype Connect. Technical Datasheet

TLS and SRTP for Skype Connect. Technical Datasheet TLS and SRTP for Skype Connect Technical Datasheet Copyright Skype Limited 2011 Introducing TLS and SRTP Protocols help protect enterprise communications Skype Connect now provides Transport Layer Security

More information

MAC Based Routing Table Approach to Detect and Prevent DDoS Attacks and Flash Crowds in VoIP Networks

MAC Based Routing Table Approach to Detect and Prevent DDoS Attacks and Flash Crowds in VoIP Networks BULGARIAN ACADEMY OF SCIENCES CYBERNETICS AND INFORMATION TECHNOLOGIES Volume 11, No 4 Sofia 2011 MAC Based Routing Table Approach to Detect and Prevent DDoS Attacks and Flash Crowds in VoIP Networks N.

More information

Examining Proxies to Mitigate Pervasive Surveillance

Examining Proxies to Mitigate Pervasive Surveillance Examining Proxies to Mitigate Pervasive Surveillance Eliot Lear Barbara Fraser Abstract The notion of pervasive surveillance assumes that it is possible for an attacker to have access to all links and

More information

Integrating Voice over IP services in IPv4 and IPv6 networks

Integrating Voice over IP services in IPv4 and IPv6 networks ARTICLE Integrating Voice over IP services in IPv4 and IPv6 networks Lambros Lambrinos Dept.of Communication and Internet studies Cyprus University of Technology Limassol 3603, Cyprus lambros.lambrinos@cut.ac.cy

More information

COSC 472 Network Security

COSC 472 Network Security COSC 472 Network Security Instructor: Dr. Enyue (Annie) Lu Office hours: http://faculty.salisbury.edu/~ealu/schedule.htm Office room: HS114 Email: ealu@salisbury.edu Course information: http://faculty.salisbury.edu/~ealu/cosc472/cosc472.html

More information

MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM

MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM MODELLING OF INTELLIGENCE IN INTERNET TELEPHONE SYSTEM Evelina Nicolova Pencheva, Vessela Liubomirova Georgieva Department of telecommunications, Technical University of Sofia, 7 Kliment Ohridski St.,

More information

NTP VoIP Platform: A SIP VoIP Platform and Its Services

NTP VoIP Platform: A SIP VoIP Platform and Its Services NTP VoIP Platform: A SIP VoIP Platform and Its Services Speaker: Dr. Chai-Hien Gan National Chiao Tung University, Taiwan Email: chgan@csie.nctu.edu.tw Date: 2006/05/02 1 Outline Introduction NTP VoIP

More information

VoIP Security regarding the Open Source Software Asterisk

VoIP Security regarding the Open Source Software Asterisk Cybernetics and Information Technologies, Systems and Applications (CITSA) 2008 VoIP Security regarding the Open Source Software Asterisk Prof. Dr.-Ing. Kai-Oliver Detken Company: DECOIT GmbH URL: http://www.decoit.de

More information

SIP A Technology Deep Dive

SIP A Technology Deep Dive SIP A Technology Deep Dive Anshu Prasad Product Line Manager, Mitel June 2010 Laith Zalzalah Director, Mitel NetSolutions What is SIP? Session Initiation Protocol (SIP) is a signaling protocol for establishing

More information

A Scalable Multi-Server Cluster VoIP System

A Scalable Multi-Server Cluster VoIP System A Scalable Multi-Server Cluster VoIP System Ming-Cheng Liang Li-Tsung Huang Chun-Zer Lee Min Chen Chia-Hung Hsu mcliang@nuk.edu.tw {kpa.huang, chunzer.lee}@gmail.com {minchen, chhsu}@nchc.org.tw Department

More information

Security Issues In Cloud Computing and Countermeasures

Security Issues In Cloud Computing and Countermeasures Security Issues In Cloud Computing and Countermeasures Shipra Dubey 1, Suman Bhajia 2 and Deepika Trivedi 3 1 Department of Computer Science, Banasthali University, Jaipur, Rajasthan / India 2 Department

More information

CE 817 - Advanced Network Security VoIP Security

CE 817 - Advanced Network Security VoIP Security CE 817 - Advanced Network Security VoIP Security Lecture 25 Mehdi Kharrazi Department of Computer Engineering Sharif University of Technology Acknowledgments: Some of the slides are fully or partially

More information

Secure Text in SIP Based VoIP

Secure Text in SIP Based VoIP MASTER S THESIS 2005:183 CIV Secure Text in SIP Based VoIP JOHAN KULTTI MASTER OF SCIENCE PROGRAMME Computer Science Luleå University of Technology Department of Computer Science and Electrical Engineering

More information

Security of VoIP. Analysis, Testing and Mitigation of SIP-based DDoS attacks on VoIP Networks

Security of VoIP. Analysis, Testing and Mitigation of SIP-based DDoS attacks on VoIP Networks Security of VoIP Analysis, Testing and Mitigation of SIP-based DDoS attacks on VoIP Networks A thesis submitted in partial fulfilment of the requirements for the Degree of Master of Science in Computer

More information

Review: Lecture 1 - Internet History

Review: Lecture 1 - Internet History Review: Lecture 1 - Internet History late 60's ARPANET, NCP 1977 first internet 1980's The Internet collection of networks communicating using the TCP/IP protocols 1 Review: Lecture 1 - Administration

More information

Vulnerability Analysis on Mobile VoIP Supplementary Services and MITM Attack

Vulnerability Analysis on Mobile VoIP Supplementary Services and MITM Attack Vulnerability Analysis on Mobile VoIP Supplementary Services and MITM Attack You Joung Ham Graduate School of Computer Engineering, Hanshin University, 411, Yangsan-dong, Osan, Gyeonggi, Rep. of Korea

More information

APNIC elearning: Network Security Fundamentals. 20 March 2013 10:30 pm Brisbane Time (GMT+10)

APNIC elearning: Network Security Fundamentals. 20 March 2013 10:30 pm Brisbane Time (GMT+10) APNIC elearning: Network Security Fundamentals 20 March 2013 10:30 pm Brisbane Time (GMT+10) Introduction Presenter/s Nurul Islam Roman Senior Training Specialist nurul@apnic.net Specialties: Routing &

More information

SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)...

SHORT DESCRIPTION OF THE PROJECT...3 INTRODUCTION...4 MOTIVATION...4 Session Initiation Protocol (SIP)...5 Java Media Framework (JMF)... VoIP Conference Server Evgeny Erlihman jenia.erlihman@gmail.com Roman Nassimov roman.nass@gmail.com Supervisor Edward Bortnikov ebortnik@tx.technion.ac.il Software Systems Lab Department of Electrical

More information

DoS: Attack and Defense

DoS: Attack and Defense DoS: Attack and Defense Vincent Tai Sayantan Sengupta COEN 233 Term Project Prof. M. Wang 1 Table of Contents 1. Introduction 4 1.1. Objective 1.2. Problem 1.3. Relation to the class 1.4. Other approaches

More information

SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University

SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University SIP: NAT and FIREWALL TRAVERSAL Amit Bir Singh Department of Electrical Engineering George Washington University ABSTRACT The growth of market for real-time IP communications is a big wave prevalent in

More information

Voice Printing And Reachability Code (VPARC) Mechanism for prevention of Spam over IP Telephony (SPIT)

Voice Printing And Reachability Code (VPARC) Mechanism for prevention of Spam over IP Telephony (SPIT) Voice Printing And Reachability Code (VPARC) Mechanism for prevention of Spam over IP Telephony (SPIT) Vijay Radhakrishnan & Ranjith Mukundan Wipro Technologies, Bangalore, India Email:{radhakrishnan.vijay,

More information

Denial of Services on SIP VoIP infrastructures

Denial of Services on SIP VoIP infrastructures Denial of Services on SIP VoIP infrastructures Ge Zhang Karlstad University ge.zhang@kau.se 1 Outline Background Denial of Service attack using DNS Conclusion 2 VoIP What is VoIP? What is its advantage?

More information

Service Provider implementation of SIP regarding security

Service Provider implementation of SIP regarding security Service Provider implementation of SIP regarding security Vesselin Tzvetkov, Holger Zuleger {vesselin.tzvetkov, holger.zuleger}@arcor.net Arcor AG&Co KG, Alfred-Herrhausen-Allee 1, 65760 Eschborn, Germany

More information

Chapter 8 Security. IC322 Fall 2014. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012

Chapter 8 Security. IC322 Fall 2014. Computer Networking: A Top Down Approach. 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 Chapter 8 Security IC322 Fall 2014 Computer Networking: A Top Down Approach 6 th edition Jim Kurose, Keith Ross Addison-Wesley March 2012 All material copyright 1996-2012 J.F Kurose and K.W. Ross, All

More information

VoIP Security. Piero Fontanini

VoIP Security. Piero Fontanini Piero Fontanini Master s Thesis Master of Science in Information Security 30 ECTS Department of Computer Science and Media Technology Gjøvik University College, 2008 Avdeling for informatikk og medieteknikk

More information

An Investigation into the Effect of Security on Performance in a VoIP Network

An Investigation into the Effect of Security on Performance in a VoIP Network Abstract An Investigation into the Effect of Security on Performance in a VoIP Network Muhammad Tayyab Ashraf, John N. Davies and Vic Grout Centre for Applied Internet Research (CAIR) Glyndŵr University,

More information

How To Protect Your Phone From Being Hacked By A Man In The Middle Or Remote Attacker

How To Protect Your Phone From Being Hacked By A Man In The Middle Or Remote Attacker An Empirical Investigation into the Security of Phone Features in SIP-based VoIP Systems Ruishan Zhang 1, Xinyuan Wang 1, Xiaohui Yang 1, Ryan Farley 1, and Xuxian Jiang 2 1 George Mason University, Fairfax,

More information

Session Initiation Protocol and Services

Session Initiation Protocol and Services Session Initiation Protocol and Services Harish Gokul Govindaraju School of Electrical Engineering, KTH Royal Institute of Technology, Haninge, Stockholm, Sweden Abstract This paper discusses about the

More information

Introduction to VoIP Technology

Introduction to VoIP Technology Lesson 1 Abstract Introduction to VoIP Technology 2012. 01. 06. This first lesson of contains the basic knowledge about the terms and processes concerning the Voice over IP technology. The main goal of

More information

VOIP TELEPHONY: CURRENT SECURITY ISSUES

VOIP TELEPHONY: CURRENT SECURITY ISSUES VOIP TELEPHONY: CURRENT SECURITY ISSUES Authors: Valeriu IONESCU 1, Florin SMARANDA 2, Emil SOFRON 3 Keywords: VoIP, SIP, security University of Pitesti Abstract: Session Initiation Protocol (SIP) is the

More information

Denial of Service on SIP VoIP Infrastructures Using DNS Flooding

Denial of Service on SIP VoIP Infrastructures Using DNS Flooding Master Thesis Computer Science Thesis no: March, 2007 Denial of Service on SIP VoIP Infrastructures Using DNS Flooding - Attack Scenario and Countermeasures Department of Security Engineering School of

More information

Request for Comments: 4579. August 2006

Request for Comments: 4579. August 2006 Network Working Group Request for Comments: 4579 BCP: 119 Category: Best Current Practice A. Johnston Avaya O. Levin Microsoft Corporation August 2006 Status of This Memo Session Initiation Protocol (SIP)

More information

CPNI VIEWPOINT 01/2007 INTERNET VOICE OVER IP

CPNI VIEWPOINT 01/2007 INTERNET VOICE OVER IP INTERNET VOICE OVER IP AUGUST 2007 Abstract Voice over IP (VoIP) is the term used for a set of technologies that enable real time voice or video conversations to take place across IP networks. VoIP devices

More information

WHAT S BEHIND YOUR SMARTPHONE ICONS? A brief tour of behind-the-scenes signaling for multimedia services

WHAT S BEHIND YOUR SMARTPHONE ICONS? A brief tour of behind-the-scenes signaling for multimedia services WHAT S BEHIND YOUR SMARTPHONE ICONS? A brief tour of behind-the-scenes signaling for multimedia services Harry G. Perros Computer Science Department NC State University, Raleigh 27695 USA Email: hp@ncsu.edu

More information