Countering Unsolicited Calls in the Internet Telephony: An anti-spit Architecture

Transcription

1 Countering Unsolicited Calls in the Internet Telephony: An anti-spit Architecture Panos STAMATIOU 1 and Dimitris GRITZALIS 1,2 1 Hellenic Open University (HOU), Dept. of Informatics, Patras, Greece 2 Athens University of Economics & Business (AUEB), Dept. of Informatics, Information Security and Critical Infrastructure Protection Research Group, Athens, Greece Abstract: Internet Telephony (Voice over Internet Protocol, VoIP), a telephony service which is based in packet transmission through IP networks, is becoming increasingly popular. Besides the obvious advantages of VoIP technology, in terms of cost reduction, user portability, and sophisticated end-user services, the use of the Internet as VoIP s main infrastructure introduces several threats and vulnerabilities. Most of these threats and vulnerabilities are related to the Spam phenomenon, which - in the case of VoIP context - is called Spam over Internet Telephony (SPIT). The scope of this paper is twofold: to study and evaluate the current anti-spit techniques and mechanisms and to propose a new architecture for managing SPIT. Index terms: SIP, SPAM, SPIT, VoIP 1. INTRODUCTION * Voice-over-IP (VoIP) increasingly penetrates the telephony market, as it appears to be an attractive alternative compared to traditional telephony. This is mainly due to its seamless integration with the existing IP networks, to its low-cost, and to the use of computerbased soft-phones. Currently, VoIP services drift towards the Session Initiation Protocol (SIP), due to its simplicity and its strong market acceptance. SIP is used for establishing communications between users, providing services such as voice telephony and instant messaging (IM) [1,2]. An identified threat to VoIP is the voice Spam, referred to as SPAM over Internet Telephony. With the exponential growth and use of VoIP technology, it is expected that voice SPAM will emerge as a potential threat. The effectiveness of telephone calls as a communication medium presents huge incentives to send a large number of unsolicited session initiation requests in an attempt to establish voice channels with many VoIP subscribers simultaneously. This situation - known as SPIT (Spam over Internet Telephony) - might impede the deployment of IP telephony and, if it is not confronted on time, it is likely to become a problem similar to SPAM [3]. This paper is organized as follows: In section 2, the characteristics of the VoIP technology are presented, followed by an introductory description of the Session Initiation Protocol (SIP). The next step is an introduction * This work has been partially performed within the SPIDER (CooP ) project, funded by the European Commission under FP6. of the Session Initiation Protocol (SIP). This provides the necessary background for the study and analysis of the techniques and architectures dealing with SPIT in the context of SIP. The threat that SPIT represents for IP telephony is indicated, as well as its similarities and differences to the corresponding phenomenon of SPAM. Afterwards, the vulnerabilities of the SIP protocol, which might lead to SPIT incidents, are presented, while SPIT attack profiles are discussed and analyzed with the use of attack modeling. A part of the paper is dedicated to the evaluation of the state-of-the-art anti-spit means. Finally, a new anti-spit architecture is specified, using new ideas and exploiting available anti- SPIT technologies. 2.1 VoIP 2. BACKGROUND The basic principle of VoIP is simple. The analog voice signal is turned to digital, compressed into data packets and transferred over the Internet or other IP networks, instead of the traditional telephone network (PSTN). In the receiver s side, a reverse procedure rebuilds the packets to the analog voice signal. IP telephony usually comprises of a signaling phase and a multimedia plane. The signaling plane is used to transport the necessary signaling information for establishing the session between IP telephony devices, while after call setup; the media transport plane is used to transfer the compressed voice data packets between IP telephony components. A call control protocol like SIP can be used to transfer the signaling information, while the media traffic can be transferred through the RTP (Real-time Transfer Protocol) which provides a framework for delivery of audio and video across IP networks with unprecedented quality and reliability [2,4,5]. One of the most advantageous features of VoIP is its cost-saving potential. By moving away from the Public Switched Telephone Networks, long distance phone calls may become inexpensive. VoIP is also cost effective because all of an organization s electronic traffic (phone and data) is condensed into one physical network. The support of transferring data, voice, video, and fax trough one network, launched the development of new integrated services (teleconference, file sharing, call identification services), which can be easier to provide through VoIP, without requiring expensive equipment. Moreover, the user s mobility is supported, while the signaling and call control protocols used can offer more secure telecommunications than the traditional telephony [5]. HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 49

2 There are two major call control protocols in VoIP; the H.323 [2,5], developed by the ITU, and the Session Initiation Protocol (SIP) [2,5,6], developed by the IETF. SIP with its Internet architecture, text based encoding and its simplicity, is gaining momentum and is emerging as the de facto signaling standard for IP communications. 2.2 SIP The Session Initiation Protocol (SIP) is an applicationlayer protocol for establishing, modifying and terminating multimedia sessions [6]. SIP is a peer-to-peer protocol, where each peer is referred to as a User Agent (UA), where UA can either act in client or server mode. SIP identity, a type of Uniform Resource Identifier, called a SIP URI, is used for initiating interactive communication sessions between users. The SIP architecture comprises five entities, namely: SIP User Agents (UAs), Proxy Servers, Redirect Servers, Location Servers and Registar Servers. A SIP proxy receives SIP messages from a UA or another proxy, and routes or forwards them. Redirection servers determine the next hop that a message should follow in order to reach its destination. Finally, registrar servers hold and update information about UA locations, and receive registration requests [4]. SIP is a client-server protocol, which resembles HTTP. Signaling is based on text messages: a message consists of a header and an optional body. Messages are either requests or responses. If a SIP entity receives a request, it performs the corresponding action and sends back a response to the originator of the request. Responses are three-digit status codes. Table 1 lists SIP requests; Table 2 lists classes for SIP response codes. INVITE BYE ACK OPTIONS CANCEL REGISTER Table 1: SIP Requests SIP Request Description Initiates a call signaling sequence Terminates a session Acknowledge Queries a server about its capabilities Used to cancel a request in progress Used to register location information at a registrar Table 2: SIP Response Codes SIP Response Codes 1xx informational 2xx ok 3xx redirection 4xx client error 5xx server error 6xx global failure Fig. 1 illustrates a SIP session setup example between two endpoints, which belong to a single operator with one proxy server. Figure 1: SIP Session establishment First, the two User Agents (UA) need to register with the local Registar. The Registar stores the location information at a Location server. When UA A wants to call UA B, it sends an INVITE request to the local SIP proxy (Domain Proxy). The proxy needs to look up the IPaddress of UA B at the Location server and then passes the request to UA B while it responds to the request with a 100 Trying message. After the UA B has picked up the phone responds to the request with a 200 OK message. UA A can now request the start of the media transfer (ACK). After a session has been established, the UAs can communicate with each other directly. At the end of communication, one of the UAs terminates the session by sending a BYE request to its counterpart. 2.3 SPAM & SPIT The SPAM is well known and is defined as the transmission of bulk, unsolicited , reaching today the 80% of all distributed worldwide 1. SPIT on the other hand, usually refers to bulk unsolicited phone calls. However, due to the fact that SIP protocol is used for other purposes (i.e. instant messages services) as well, three different forms of SPIT have been identified [7,8]: Call SPIT, i.e., a bulk unsolicited set of session initiation attempts. Instant Message SPIT (SPIM), i.e., a bulk unsolicited set of instant messages. Presence SPIT, i.e., a bulk unsolicited set of presence requests, so as the malicious user (spitter) to become a member of the address book of one or more users. SPIT constitutes a new type of threat in VoIP environments. It illustrates several similarities with SPAM. Both spammers and spitters use the Internet infrastructure so as to target group of users, and instantiate, bulk, unsolicited calls or messages, respectively. Impersonation of address tools, harvesting addresses, and dictionary attacks, as well as zombie 1 Symantec, Global Internet Security Threat Report, April HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 50

3 networks could be utilized for SPIT or SPAM attacks. Automated software tools (well known as software bots ) are found to be an effective tool for automatic generation of SPAM, and potentially of SPIT. However, there are certain differences between SPIT and SPAM, summarized in Table 3 [8]. Table 3: SPIT and mail SPAM characteristics Communication Scope Attack cost Main impacts Proposed countermeasures Means Spam (SMTP) Asynchronous (store and forward) Sending bulk unsolicited mail messages Low for each message Disruption to activities - Moderated user annoyance due to text Mainly checking and filtering mail content Mainly message, attached video, sound, image Compared to SPAM, SPIT might become a problem, which is harder to deal with. While s are only a few kilobytes a piece, voice messages can take up several megabytes. Hence, it is easy to understand the excessive burden which SPIT may cause to a network and how easy it is for a spitter to cause a DoS (Denial of Service) attack. This becomes more serious due to the integration of the networks, in which case DoS does not only concern the telephone network, but affects the data network, too. 2.4 SIP Threats and Vulnerabilities SPIT (SIP) Asynchronous (during session establishment) synchronous (during the session) Making bulk unsolicited phone calls or sending bulk instant messages Significant for the session establishment dialog, high during the session Significant network overload - Considerable user annoyance due to sound Real-time control of SIP signaling process, prior to the establishment of the session Mainly phone call or video session, secondary instance message In the context of SIP-based VoIP, SPIT is defined as the possible action or event that exploits SIP vulnerabilities in order to launch massive unsolicited calls. Therefore, for an anti-spit mechanism to be effective, it should eliminate the identified vulnerabilities regarding SPIT. These vulnerabilities are classified into four categories: (a) protocol inherent vulnerabilities, (b) vulnerabilities due to the optional recommendations of SIP, (c) vulnerabilities due to interoperability with other protocols, and (d) vulnerabilities due to generic security risks. These vulnerabilities are described in Table 4 [8]. Table 4: SIP Vulnerabilities regarding SPIT Category of vulnerabilities Inherent vulnerabilities of SIP: Exploitation of a mandatory characteristic in the description of the structure and functionality of the SIP protocol. SIP optional recommendations: Exploitation of optional recommendations of the SIP protocol. Interoperability with other protocols: Exploitation of weaknesses of protocols used by SIP Generic security risks: Exploitation of security weaknesses 2.5 SPIT attack modeling Recognized vulnerabilities Sending ambiguous requests to proxies Listening to a multicast address Population of active addresses. Contacting a redirect server with ambiguous requests. Misuse of stateless servers Anonymous SIP servers and B2BUAs. Sending messages to multicast addresses Exploitation of forking proxies Exploitation of messages and header fields Exploitation of registrar servers Exploitation of particular domains address resolution procedures Monitoring traffic near SIP servers Port scanning on wellknown SIP ports Proxy-in-the-middle Exploitation of the record route header field In order to counter SPIT attacks, one needs to understand how spitters behave while conducting such an attack. Attackers typically follow certain attack strategies, often employing serially interconnected attacks, so as to achieve their goal [9]. In the SPAM context, for example, such a generic strategy is depicted in Fig. 2. HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 51

4 Figure 2: Generic SPAM attack strategy Predicting attacks, together with identifying vulnerable points, can be exploited for preventing similar future attacks, as well as for limiting their impact. Attack graphs and attack trees are used for modeling the security of a specific system against certain types and categories of attacks. For example, attack strategies can be modeled through directed acyclic graphs (DAG), which are graphs with nodes representing attacks and edges representing the temporal order of them [10]. They can be also used to represent all possible steps an attacker can follow during a multi-step attack to achieve a specific goal. Therefore, attack graphs could be used in order to reveal attack strategies by enumerating all possible sequences of attacks that can be followed to compromise a system. Attack tree is the representation of an attack against a system, provided for in a tree structure [11]. The root node of a tree represents the main goal of an attacker. The leaves represent specific attacks that could be used in order for the main goal to be fulfilled. An intermediate node of the tree, together with its branch, can be conjunctive (aggregation) or disjunctive (choice) [12]. In order to realize the attack denoted by a specific node, either all of its sub-attacks (children nodes) must happen (conjunctive-and node), or just any of them (disjunctive -OR node). Fig. 3 depicts an example attack tree [9]. Figure 4: SIP-oriented SPIT attack graph The SIP-oriented SPIT attack model consists of three levels: (a) the SPIT attack strategy, (b) the SPIT attack graph, and (c) the attack trees. Each and every level is an abstraction of its lower ones. The main concepts of each level are [9]: Attack strategies describe the actions needed so as an attack takes place (in our case the generic SPIT attack strategy). The attack graph describes, in detail, the SPIT attack strategy. It consists of several SIP SPIT abstract attacks showing the relationships among them. The SPIT attack trees analyze every abstract attack, which is a part of the previous attack graph. Fig. 5 depicts the various levels of the SIP-oriented SPIT attack model [9]. Figure 5: SPIT conceptual view, attack graphs and attack trees Figure 3: Attack tree (Path: Encapsulate SPIT in SIP Messages ) Attack graph is a formal means for modeling system security vulnerabilities. It represents all possible sequences of steps an attacker may follow to achieve her goal [9]. In essence, attack graphs are graphs describing all likely series of attacks, where nodes and edges represent the sequences of possible attacker actions. Fig. 4 depicts an example attack graph, where every node is the root of an attack tree and the edges represent the sequences of possible attacker steps [9]. 3. ADOPTING ANTI-SPIT TECHNIQUES FOR COUNTERING SPIT SPIT management can be carried out in three steps: (a) prevention, being able to stop SPIT a priori, (b) detection, being able to detect a SPIT call or message, and (c) handling a detected SPIT call or message. So far, a number of anti-spam techniques have been proposed so as to counter SPIT attacks [8,14,23]. Some of them appear to be the basic building blocks of more sophisticated anti-spit architectures, which have been proposed in the literature. In the sequel, we provide a brief description of anti-spit techniques, aiming at: (a). HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 52

5 classifying them according to the above-mentioned three progressive steps, and (b). checking their SPIT handling capability. Content filtering. It is based on filters that check the content of the messages. They appear to be inappropriate as an anti-spit technique, due to the real-time requirements of VoIP communications. However, the technique could be used for the detection of SPIM, (instance messaging SPIT), that appears to have several similarities with SPAM. Black and white lists. An end-used accepts the calls, or messages, initiated by any of the trusted members in her white list. Black lists include the potential initiators of SPIT calls, which should be blocked. Consent-based. In this case, the communication is achieved only when the callee gives her explicit consent. Reputation-based. This is a trust-based approach. When a callee receives a request for communication, the level of trust of the caller is determined through direct estimations or second-hand reputations. If the trust level is above a predefined threshold, then the communication is permitted; otherwise it is blocked. Address Obfuscation. SPAM bots typically look for text in pages of the form "user@domain" and assume that anything of that form is an address. To hide from such SPAM bots, websites have recently begun placing addresses in an obfuscated form, usable to humans, but difficult for automata to read. Examples include forms such as, "user[at]example[dot]com", etc. Limited Use Addresses. In this case, a user has a large number of addresses at his disposal, each of which has constraints on its applicability. A limited use address can be time-bound, so that it expires after a fixed period. Or, a different address can be given to each correspondent. When SPAM arrives from that correspondent, the limited use address they were given is terminated. Challenge-Response. In this case, the communication is feasible only when the caller correctly answers a challenge sent by the callee. The main idea is to counter SPIT by providing the means to distinguish humans from bots. Such mechanisms include Turing tests and computational puzzles. Charging-based. This approach forces spitters to pay for every unsolicited bulk call (message), hence the overall cost of sending SPIT is getting high in terms of money or computational resources. Legal Action. SPIT is controlled through legislation, in a similar way to current SPAM laws. However, there is a debate on whether legislation can really be effective in preventing SPAM [1]. Circles of Trust. In this model, a group of domains (e.g., a set of enterprises), agree to exchange SIP calls among them and also agree to introduce a fine that they should pay if any of them is Spamming. Each company would then enact measures, e.g. to lay off employees who send SPAM from their accounts. Centralized SIP Providers. It is a variation of the circles of trust. A small number of providers get established as "inter-domain SIP providers". They act as SIP-equivalent to the interexchange carriers in the PSTN. Every enterprise, consumer SIP provider, or other SIP network (call these the local SIP providers) connects to one of these inter-domain providers. The local SIP providers only accept SIP messages from their chosen inter-domain provider. The inter-domain provider charges the local provider, on a SIP message basis, for the delivery of SIP messages to other local providers. SPIT Report. The basic idea in this technique is that each user, who receives a SPIT session request, will send a feedback to a SPIT identification system (e.g., using a button on the user interface of the client). Information could be also exchanged among domains and/or servers in order to increase effectiveness of SPIT detection systems. When some session requests are not detected as SPIT by the anti-spit system, the callee picks up the call and when she realizes that she received an unsolicited session request, then she terminates the session with a special button, which informs the system that a SPIT session request was just delivered. In Table 5 the above described anti-spit techniques are categorized according to their role in fighting SPIT, so as to demonstrate which technique is more efficient for each of the different stages of SPIT fighting. Table 5: anti-spit techniques and their scope Prevention Detection Reaction Content filtering Black/ White lists Consent-based Reputation-based Address Obfuscation Limited Use Addresses Challenge- Response Charging-based Legal Action Circles of Trust Centralized SIP Providers SPIT Report 3.1 Evaluation of anti-spit techniques A comparative evaluation of the proposed anti-spit techniques should define and take into account various qualitative and quantitative criteria. In the following we use the criteria [8, 15] depicted in Table 6. We also adopt five levels of satisfaction of these criteria, so as to evaluate the effectiveness of the anti-spam techniques for countering SPIT phenomenon. HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 53

6 Reliability Promptitude Ease of use Required Recourses (user) Required Resources(provider) Economic Cost (provider) Human Interference Vulnerabilities Privacy Risk COUNTERING UNSOLICITED CALLS IN THE INTERNET TELEPHONY: AN ANTI-SPIT ARCHITECTURE Satisfaction level Very High High Medium Low Very Low The colors in the results have been added to facilitate as a visual aid in the case of inversion of the meaning of levels. This appears when, for instance, in most criteria (e.g. in reliability) a level of Very High is needed; in others (e.g. in Cost or Required Resources) a level of Very Low is needed (the colors have been inverted, i.e., the white shows the best result and the black the worst). Technique Table 6: Anti-SPIT techniques evaluation V H Μ V L Μ V L V L V L V L V L Black lists H H Μ V L V L V L H Μ Μ White lists H H Μ V L V L V L H V L Μ Turing Tests H Μ V L Μ V L V L Μ L V L H Μ V L Μ V L V L Μ L V L H Μ V L Μ V L V L V L L Υ Μ V H V L V L V L V L V L L V L Legal Action Μ V H V H V L V L V L V L Μ V L Consentbased Computation al puzzles Chargingbased Limited Use Addresses Circles of Trust Reputationbased Centralized SIP Providers Address Obfuscation Content filtering Μ V H L V L V L V L V L Μ L Μ Υ V L Μ V L V L Υ Μ Υ Μ Μ V H V L Υ Υ V L L V L L V H L V L V L V L V L V H V L V L V L V H V L V H V L V H V H V H Content filtering, a successful anti-spam technique, is not appropriate for SPIT handling. This is mainly due to the real time nature of VoIP communications. On the contrary, the Consent-based technique, presents very good results. 4. ANTI-SPIT MECHANISMS In this section, we discuss a number of anti-spit architectures that have been proposed so far [8]. 4.1 Anonymous Verifying Authorities. This architecture [16] extends the call setup procedure. It is mainly based on the call-me-back scheme. It also introduces two new entities: (a) the Mediator and (b) the Anonymous Verifying Authority (AVA). The role of the mediator is to receive call requests, to forward them to an AVA, and to establish the call when the permission has been granted. The role of the AVA is to identify, validate, and locate the caller and the callee, to inform the callee s proxy and, in case the call was approved, to generate a unique token. The call-me back scheme is achieved because when the call is approved, then the callee s and not the caller s proxy is responsible for initiating the media transfer. 4.2 Network-Level Anti-SPIT Entity A network-level entity is proposed in [17]. This entity is placed at the edge of the network and its scope is to filter and analyze network traffic (it analyzes the transmitted SIP packets). The SPIT detection depends on five criteria: (a) the duration of the calls, (b) the number of received error messages returned from SIP protocol, (c) the automated logic of addresses presented in SIP headers, (d) the simultaneous calls attempts, and (e) the analysis of the simultaneous calls made by a user. By using these criteria a weighed sum (spitlevel) is calculated. Then, it is compared to a threshold. If this threshold is exceeded, then the call is classified as SPIT. 4.3 Reputation and Charging In this case [18] two techniques are proposed for SPIT detection and mitigation. The first is based on reputation and the second on charging (payment). The Reputationbased technique creates a reputation network in which the owner of a contact list and the users belonging to the list are considered as nodes connected with weighted edges. The weights indicate how much trust the owner of the list has to its members. The Charging-based technique is a variant of the payment- at-risk proposal, where the senders pay for each message they send, so as the sending expenses are increased. To support functionality of the proposed technique, it is assumed that SIP users are allowed to have a white list. It also assumed that in each domain there is a server for authentication and accounting purposes. Furthermore, some agreements have to be established between different SIP providers for the exchange of authentication information. When the SIP proxy of the callee s domain receives a SIP request, it first checks if the sender belongs to its white list. If so, the SIP request is processed; otherwise, the SIP server generates a reply or forwards the request to an IVR service. In both cases the sender is informed that she should pay a fee in order for the request to be satisfied. If the sender pays the fee, then the SIP server passes the sender s information to an AAA server, which checks the authenticity of the sender and makes all the required charging and accounting actions; otherwise the session is terminated. 4.4 DAPES The DAPES (Domain-based Authentication and Policy- Enforced for SIP) system is based on the SIP trapezoid to classify in real time a SIP request as SPIT or legitimate [19]. Its basic requirements are: (a) all SIP messages must HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 54

7 pass through proxies that support TLS or IPSec authentication, (b) outbound proxies have certificates signed by trusted CA, (c) all signaling negotiation between proxies must use TLS or IPsec, and (d) the identity of the caller must be verified by its domain proxy. Any SIP-based communication passes through two stages of verification. In the first stage the caller s identity is verified, while the second involves mutual authentication of the participated proxies, and verification of the outbound proxy through DNS records. Furthermore, DAPES classifies SIP domains based on their trustworthiness and, especially, on how they handle identity management and AAA services. 4.5 Progressive Multi Gray-Leveling (PMG) The PMG [20] calculates and assigns a gray level for each caller. The gray level, which indicates a graduation between white and black, is used for determining the legitimacy of a sender and is calculated based on previous call patterns of the particular caller. The overall Gray level is the sum of the short-term and the long-term level. When the overall Gray level exceeds a pre-defined threshold for a particular caller, then the caller is characterized as a potential spitter and her calls are blocked; otherwise, the user is characterized as legitimate and calls are permitted. However, the gray level is not static, so if the caller does not make any further SPIT calls within a certain period, then the corresponding gray level is decreased; if it drops below a predefined threshold, then the caller is allowed to initiate calls again. 4.6 Biometric countermeasure In this case [21], the use of global servers that bind users identities to personal data is proposed, in an effort to confront the problem created from the fact that spitters can frequently change their identity. The selected data is biometric (a person s voice), and the servers are selected as global, so even if a caller switches to another SIP provider she will be identified. When the user first uses VoIP, she registers to a trusted authentication server in order for her voice to be recorded and bound to a unique VoIP identity. The server asks the client to repeat a sentence, stores the client s voice file, and finally sends back unique credentials. The client can now make calls to other clients, and be authenticated using these credentials. 4.7 SIP SAML This architecture exploits SAML (Security Assertion Markup Language) [22] for SIP authentication and authorization through asserted traits. A SIP Authentication Service (AS) authenticates the user, by creating a cryptographically signed authentication token for that user, while it facilitates the sharing of users identity to peers. The AS authenticates a user who wants to establish a call, and then it forwards the call-setup message to the callee s SIP proxy. This message includes the caller s identity information, as well as a reference to a SAML assertion, which asserts various traits of the caller and points to the caller s domain certificate. If the assertion and domain certificate pass the verification phase on the callee s proxy, then the call setup process is continued. 4.8 Differentiated SIP (DSIP) In [13] an extension to SIP is proposed. It aims at handling SPIT by classifying the callers into three categories: (1) white listed, i.e., those who are legitimate callers, (2) black listed, i.e., those who are spitters, and (3) grey listed, i.e., those who are not yet classified as legitimate callers or spitters. When a caller belongs to the callee s white list, then the call can be established. If the caller belongs to the callee s blacklist, then the call is rejected. Finally, if the caller is unknown, then the caller is forwarded to a human verification test. After passing the test, the caller is allowed to communicate with the callee. However, the caller should not be able to leave voic messages on the callee s voic server, if the callee is not available for the calls. Instead, the caller stores the message on local proxies and provides the callee with instructions to retrieve the message, when the latter becomes online. 4.9 VoIP Seal VoIP SEAL [23] combines a number of different techniques to detect a suspicious VoIP call. For example, there are modules that can apply black or white list logic, measure SIP INVITE rates, test reputation or check if INVITE messages with different SIP URI are coming from the same IP address, etc.. Each module does a test and produces a score, and at the end the scores are combined to give an overall score that measures how dangerous a call might be. VoIP SEAL can apply tests in two phases, i.e., before answering the call, and after picking it up. In phase 1, the suspiciousness level of a call can be assessed and if the level is low then the second phase can be skipped by simply connecting the call to the recipient. If the level passes a predefined threshold, then the call is diverted to an answering machine that can apply further tests. In phase 2, VoIP SEAL can measure the speech energy when a greeting or outgoing message is being played. For a genuine human caller this energy should be low, as humans tend to listen rather than talk over greetings. There are more sophisticated audio CAPTCHA tests (Turing Tests), which can also be applied to attempt to tell the difference between a human and a bot. The main feature of VoIP SEAL is the adoption of a modular architecture, and the easiness to add and update modules to respond to new or different kinds of SPIT Voice SPAM Detector The Voice SPAM Detector (VSD) [24] combines many of the anti-spit techniques (see Section 3). The system is a multi-stage adaptive SPAM filter, based on presence, trust, and reputation. It also uses feedback between the different stages so as to detect SPAM in voice calls. The building blocks of the VSD include the following filters: (a) presence, (b) traffic pattern, (c) black and white lists, (d) Bayesian learning, and (e) social networks and reputation. Presence filtering depends on the current status of the callee. For example, if a callee is busy, then HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 55

8 it is possible that she will not accept incoming calls or messages. The traffic pattern filter analyzes the rate of incoming calls. This is followed by white/black lists filtering. Bayesian filtering is the next step, where a call is checked regarding the behavior of the participated entities by looking up trust information available for those entities. The trust information would be available if any of the entities has a history of calling an end-user. Finally, reputation techniques are used to check the acceptance of a call based on social relationships (network) that an end- user maintains with other entities participating in the VoIP environment SPIT-AL SPIT-AL [25] accepts calls as a proxy for the called subscriber. According to the meta-data of the call (caller identity, call origin, time - if applicable), as well as of the preferences of the subscriber, the call gets rated. Depending on the rating of the call, the system decides which action to take on it SPIT Prevention System (SPS) This is based on the fact that, within a reasonable short duration of time, an INVITE request is uniquely bound to its initiator (From URI), the originating SIP device (first Via address) and to a voice stream (media address and port). SPS establishes [3], as a part of the SPIT prevention mechanism, a correlation among five attributes, which they select from INVITE messages. In normal conditions this correlation is well maintained and remains relatively invariant with time. When a SIP proxy server comes under a voice SPAM attack, then the deviation from normal behavior is measured and used to raise an alert flag RFC 4474 An end-user authentication scheme is also proposed in [26], but in this case via Public Key Infrastructures (PKI) and Certificate Authorities (CA). This proposal achieves end-to-end authentication. The identity control is kept within the callers domain. The caller generates an INVITE and places her identity in the From header field of the request. She then sends an INVITE over TLS to an authentication proxy for her domain. The authentication service authenticates the caller and validates that she is authorized to assert the identity that is populated in the From header field. It then computes a hash over some particular headers, including the From header field and the body in the message. This hash is signed with the certificate for the domain and inserted in a new header field in the SIP message, the Identity header. The proxy, as the holder of the private key of its domain, is asserting that the originator of this request has been authenticated and that she is authorized to claim the identity (the SIP address-of-record) that appears in the From header field. The proxy also inserts a companion header field, Identity-Info, that tells the callee how to acquire its certificate. When the callee s domain receives the request, it verifies the signature provided in the Identity header, and thus validates that the domain indicated by the host portion of the AoR in the From header field authenticated the user. Although the proposed mechanism is not an anti- SPIT mechanism and is not oriented for SPIT handling, the offered identity control is useful for controlling SPIT. A categorization of the described architectures is now done (Table 8), based on each one s preventive, detective or reactive capability. Mechanism AVA Table 8: anti-spit mechanisms and their scope Prevention Detection Reaction Anti-SPIT entity Reputation / charging DAPES PMG Biometrics SIP SAML DSIP VoIP SEAL VSD SPIT-AL SPS RFC EVALUATION OF ANTI-SPIT MECHANISMS In the sequel, the previously mentioned anti-spit mechanisms are evaluated using specific criteria. The criteria are categorized as efficiency, adoption, and operation criteria (the later refers more to the structure of the mechanisms and the results from a possible experimental implementation [15]). Table 8 presents those anti-spit mechanisms that measure, estimate, or just mention the aforementioned criteria. The results of our analysis have not been based on which criteria each mechanism could, should, can, or may fulfill. We rather mention the existence of each criterion in the mechanisms description. For instance, in the description of VoIP SEAL mechanism, it is mentioned that the particular mechanism is intrusive for the end-user, as there is an interactive part requiring user s feedback. In our analysis, we do not assess how intrusive this mechanism is, but we note that there is information in the description of the mechanism that could help someone value accordingly the particular criterion (i.e., Human Interference). HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 56

9 Reliability Promptitude Ease of use (Human Interference) Parameterization requirements Vulnerabilities Privacy Risk Recourses overhead for SIP provider Scalability Ease of Adoption Processing overhead Availability Mechanism s deployment Percentage of SPIT calls avoided Strong authentication Policy Combination of techniques Use of certificates COUNTERING UNSOLICITED CALLS IN THE INTERNET TELEPHONY: AN ANTI-SPIT ARCHITECTURE Table 8: Anti-SPIT mechanisms evaluation EFFICIENCY ADOPTION OPERATION CRITERIA MECHANISM AVA Anti-SPIT entity Reputation/Charging DAPES PMG Biometric SIP SAML DSIP VoIP SEAL VSD SPIT-AL SPS The mechanisms mostly use, as building blocks, some of the anti-spit techniques that were mentioned in Section 3. The combined operation of these techniques might be an efficient way to create an effective and holistic anti-spit solution. From the evaluation of the anti-spit mechanisms it appears that none of them can be considered ideal or simply more effective than the others. 6. SPECIFICATIONS OF AN EFFICIENT ANTI- SPIT MECHANISM The following set of specifications, which an anti-spit mechanism must fulfill, in order to be efficient, derives from the evaluation criteria, in combination with the satisfaction degree of each criterion. Reliability. It refers to the precision needed for making the adequate adjustments about SPIT calls and callers, in terms of false positive and false negative rates. Promptitude. Due to the real-time nature of VoIP, quick decisions regarding SPIT detection are a requirement, especially when legitimate calls are analyzed. In such a case, trustworthy users should not tolerate large delays. Ease of use (human interference). This metric represents the transparency of the anti-spit mechanism to the enduser. Parameterization requirements. Low requirements of this kind are usually considered as positive for a mechanism, since they do not cause user annoyance. However, an anti-spit mechanism should have the capability of wide parameterization, so as to adapt in different requirements, HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 57

10 and to remain effective in a constantly evolving environment of threats. Vulnerabilities. It refers to the capability of a spitter to bypass any of the anti-spit countermeasures. Privacy Risk. It is associated with the collection, manipulation, and dissemination of private data. We assume that the end-user consents for the collection and manipulation of his private data, and he has authorized specific legal entities for these purposes. Resources Overhead for the SIP provider. SIP providers should estimate the required resources for the implementation of the mechanism. This quantitative criterion seems essential for providers, as the number of calls that should be analyzed per unit time might be enormous, whilst registered users might be numerous. Scalability. It should be considered when authentication is involved, as PKI and CA might need to establish complex cross-certification chains, or reputations and assertions are used. Ease of Adoption. It corresponds to the success of the anti-spit countermeasure and depends on the effort it takes for an end-user, or a provider, to initiate its use. Processing overhead. The degree of overhead that the usage of an anti-spit mechanism adds to the process of call setup request, due to the addition of processing steps or entities. Evolutions conformity capability. An anti-spit mechanism should be able to adjust to new threats, new requirements and to adopt new and more effective techniques which are bound to be proposed. Strong Authentication. The strong authentication of the caller is an important element for the effectiveness of a mechanism. The mechanism s capability for identification of the caller, beyond the contribution in SPIT detection, can also act as a deterrent, thus achieving a more complete protection. Policy. An effective SPIT handling mechanism should have the capability to enforce the anti-spit policies that will be adopted. Combination of techniques. If a mechanism is based on the combined operation of several techniques, its effectiveness is expected to increase. Specify and develop tools for SPAM detection and control. Support different means for detection that can be added based on user and provider specific needs. Integration and testing of developed tools and solutions in a provider's VoIP infrastructure. 7.1 Generic architecture description The SPIDER architecture adopted a modular approach and hence ensures the following: incorporation of newly detection mechanisms in response to the emergence of new SPIT forms activities, seamless replacement of SPIT detection mechanisms without harming the overall architecture, and flexibility of the suggested solution to be adjusted to the providers requirements. This architecture consists of two main layers: (a) a detection layer, where the SPIT detection intelligence is distributed over different modules, and (b) a decision layer, where the results received from the detection layer are gathered and accordingly a decision is made. Detection layer: The main task of this layer is to test the received SIP requests against some predefined rules describing the SPAM behavior. This layer consists of modules that operate more or less independently. The results of these tests are passed to a Decision Point, which decides whether the SIP request is SPIT or not. Decision layer: The main task of the Decision Point is to receive the results of the tests performed by the detection modules, combine them, and classify the intercepted requests as SPIT or not. The generic SPIDER architecture is depicted in Fig. 6. The SIP server is the component that intercepts the SIP requests and passes the corresponding information to the Decision Point, which in turn triggers the SPIT testing and takes a decision according to the corresponding results. The decision information is passed back to the SIP server, which is going to either forward further the request, or reject it. 7. SPIDER We propose an architecture called SPIDER (Spam over Internet Telephony Detection Service). SPIDER is named after a co-operative research project, funded by the European Union. It aimed at endowing the participating small and medium enterprises with an anti-spit framework so as to enhance their VoIP infrastructures and protect their customers from abuse 2. The SPIDER main objectives were: Design and implement a framework for secure VoIP calls to avoid misuse of VoIP for Spam delivery. 2 HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 58

11 Figure 6: SPIDER Generic architecture 7.2 SPIT Detection Modules In Fig. 7, except for the SIP server (SIP Express Router, SER [27]) and the Decision Point, the detection modules (Detection Layer) are also presented. For obvious reasons, not all modules that appear in Fig. 7 are used every time the SPIDER is enabled. Figure 7: SPIDER architecture The first two detection modules are the Authentication and the Proxy Check ones. These two are used alternatively (i.e., only one of them can be used at an instance), because even though they operate with a different logic, they are used for the same scope, i.e., the prevention of use of obfuscated or fake identities. Authentication module. It aims at enhancing domain verification for the anti-spit solutions. The module tries to identify senders by the set of SIP servers they use to send their requests. The idea behind the domain verification techniques is to get some information from the sender s domain that helps to verify that this domain is exactly the source of the message. As a consequence, a SIP message issued, apparently, from iptel.org could not be sent by a user outside iptel.org. The solution adopted here is described in [26]. Proxy check module. This module is in charge of checking whether the issued calls are using open relay servers. It is also based on the assumption that if an INVITE message is received from a host that is not known to be a proxy of the caller s domain, then it is likely to be SPIT. If any suspicious information is present in the SIP message header, the call will simply be dropped else should be tested further, by the other detection modules. White/Black lists module. A SPIT black list is a list of IP addresses and domains of known SPIT users and servers. In practice, black lists are used to block all SIP requests coming from certain SIP servers identified as being used to send SPAM. White lists are the opposite of blacklists; they involve trusted IP addresses and domains that are always allowed to establish calls and send instant messages, no matter what the content is. In SPIDER, global and local, white and black lists are used. If the request sender is black listed, then the request will be rejected without further checks. If the sender is registered in the white lists, then the request will be forwarded to the callee, also without further checks. If the caller is not registered either in the black or in the white lists, then the request will be further examined by the next module. Machine learning module. This module can be used to automatically filter SPIT, based on machine learning techniques. The SIP message can be considered as a block of text to which a learning algorithm (decision tree, HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 59

12 probabilistic approach, etc.) could be applied. Because of the similarities between and SIP instant messaging, this technique can be applied successfully to detect SPIT instant messages. As for SIP calls, the filtering is restricted to the SIP message header fields, due to the useful data encapsulated to them. The SIP message header contains related information to the «FROM» field, the «TO» field, the «SUBJECT» field and some other data that might be valuable for detecting SPIT. If the check indicates SPIT, then the request is rejected without further checks; otherwise the request is forwarded to the next module. The next module can be the Challenge/ Response or the audio analyzer module. These two modules also operate alternatively. Even though they are designed based on a different idea, they share the same goal, which is to separate the requests generated by automats from those that derive by humans. Challenge/Response module. The Challenge/Response (C/R) module uses reverse Turing tests (CAPTCHAs) [28] and not computational puzzles based on hash functions. This technique was selected due to the fact that the VoIP communications are designed to be established between low CPU power devices (e.g., mobile or handheld phones). This might introduce delays when solving hash-based computational puzzles, which are intense in resources. Such delays are commonly unacceptable by a legitimate caller. When the decision point module indicates that a C/R test is needed, then a visual/audio CAPTCHA challenge is initiated in the callee s domain and it is sent to the caller. The latter will send a response and based on its correctness, the relevant output will be forwarded to the decision point. The C/R module will return a pass or not pass reply to the decision module. If the CAPTCHA test is successful, the request will be forwarded to the callee. If it fails, another test can be initialised so as to avoid rejecting a call of a legitimate user. Audio Analyzer module. Like the previous module the audio analyzer is intended to be used for fighting SPIT generated by automats. This implies that the audio message which is heard by the receiver is always the same. In a normal VoIP communication the audio checksums of two different calls are never the same. If a checksum is seen more than once the probability of SPIT is very high for this signature. The Analyzer has similarities with an Interactive Voice Response (IVR). It answers a call and plays a pre-recorded audio for human caller. This audio informs the caller of a short delay while processing her call. This does not only inform human callers, it also simulates a human receiver for spitters, which are waiting for an audio answer before sending their messages. While playing the information, the Audio Analyzer starts recording the caller audio. The recorded audio data will be fed to a checksum calculating algorithm; the checksum is checked against a database. If the counter of the checksum is unknown, then this call is potentially no SPIT, otherwise it is likely to be SPIT. Reputation Manager. It uses the amount of the chain trust that may exist between the SIP request receiver and the SIP request sender. In fact, each SIP subscriber is supposed to score the persons on his contact list according to the trust that he has in them. The amount of trust is expressed by a real number that we assume to be between 0 and 1 for simplicity. The greater this value, the more trustful the scored person is. When combining all these rated contact lists, a weighted graph is generated as depicted in Fig. 8. Figure 8: A social network example In addition to that, the Reputation Manager generates all possible paths between any two given SIP users. These paths are assigned a reputation value according to some appropriate metrics defined in [18] and are stored in the trust chains repository. This operation is regularly performed in order to minimize the SIP proxy response time to the incoming SIP requests. The Reputation Manager uses the amount of the chain trust that may exist between the SIP request receiver and the SIP request sender. In fact, each SIP subscriber is supposed to score the persons on her contact list according to the trust that she has in them. The greater this value, the more trustful the scored person is. When combining all these rated contact lists, a weighted graph is generated as depicted in Fig. 9. HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 60

13 Figure 9: A reputation based architecture If a path between the source and the destination is found, then the corresponding computed score is compared to a predefined threshold. Based on the comparison result, the SIP request is accepted or rejected. User feedback. If, finally, one call is forwarded to the callee, the later sends feed back to the system, through an interface, so as the next call from the same caller to be either rejected (if the caller is spitter), or accepted without the particular caller to undergo the same checks. 7.3 Pro s and Con s of SPIDER architecture SPIDER introduces specific advantages, which render the mechanism effective. On the other hand, a number of disadvantages have been, also, identified. Pros SPIDER fulfills the defined effectiveness criteria. More specifically: The modular approach permits: Incorporation of newly detection techniques in response to the emergence of new SPIT forms activities. Seamless replacement of SPIT detection modules without harming the overall architecture. Flexibility of the mechanism to be adjusted to the providers requirements. Use by variety of hardware. The domain authentication is supported, while the identity of the caller must be verified by its domain proxy. The use of SER as SIP proxy ensures the anti-spit policy enforcement capability. The use of machine learning techniques decreases the parameterization requirements. Cons It does not encounter the case of domain flooding by a very large number of simultaneous call requests; case which may cause collapse and subsequent Denial of Service (DoS) attack. The audio analyzer technique adds processing overhead and requires increased processing resources. Chains of trust that are used, may introduce scalability problems, due to the continuously increasing number of users where complex reputation networks should be created. 7.4 Improvement Proposals The drawback of the potential call request flooding of the domain is serious. To avoid it, an improvement is depicted in Fig Inbound calls rate counter. The use of rate counters requires the proper definition of a threshold, which can be achieved with the statistical analysis of the ordinary rate of inbound calls. This threshold will not be static, but will vary, according to the ordinary call rate for each day and time of the day. Thus, with the addition of a proper margin, a reliable threshold can be identified. The counter can be implemented through a module, which is placed immediately after the SIP proxy (SER) of the domain. With this adaptation, the mechanism attains an inbound calls rate counter, which is updated with every new inbound call. If the rate of inbound calls increases beyond the predefined threshold, for that day and time, the counter informs SIP proxy to reject the rest of the calls Calls in progress counter. In the case of a SPIT attack, until the inbound SIP proxy stops accepting calls, many calls will possibly enter the domain. When the number of calls already received and already in some check stage, fall below a threshold, then the inbound calls rate counter returns to zero and the SIP server is informed that it can accept calls again. The scope of this second counter is network decongestion after call requests flooding, before new calls can enter the domain for processing. HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 61

14 Figure 10: SPIDER architecture with the proposed improvements To make the use of counters more clear, let us describe a hypothetical scenario. Threshold Calculation. The use of an inbound calls rate counter requires the proper predefinition of a threshold. Say that in some domain the ordinary rate of inbound calls, for a specific day and hour, is 100 calls/min. We can add a margin of 50 more calls and therefore calculating a threshold of 150 calls/min. Normal Call rate. The inbound calls rate counter is updated with every new inbound call so as to count the inbound calls rate. Under normal circumstances this rate does not exceed the predefined threshold, so no action is taken. SPIT Attack. In case of a SPIT attack, it is expected that a mass inbound call attempts will reach the domain s SIP proxy. In this case the inbound calls rate will exceed the predefined threshold, thus the inbound calls rate counter will inform SIP proxy to reject the rest of the calls. Calls in progress. In case of a SPIT attack, until the SIP proxy reject the calls, it is certain that a lot of these calls will have already entered the domain and will be at some stage of checking. The number of these calls is counted by the Calls in progress counter and can be quite large. For this counter, a proper threshold is calculated and exceeding this threshold indicates the domain is close to congestion. Domain Decongestion. As the calls that have entered the domain and are already at some check stage are rejected or forwarded to the callees, the number of calls in progress decreases; when it falls below the predefined threshold, the inbound calls rate counter (first counter) returns to zero and the SIP server is informed that it can accept calls again. Network decongestion is significant, before new calls can enter the domain for processing. However, locking calls may mean customer dissatisfaction. Also, when a non predictable event happens (e.g., a crisis), then this technique may result in blocking calls in the case of an emergency, that is, when communication is mostly needed Audio analyzer vs. consent based scenario The audio analyzer technique aims at resolving the introduction problem. It is demanding in resources and may add serious delays and processing overhead. Instead of such a technique, a Consent-Based approach can be used. This can be implemented through a module, which will be added as the last SPIDER module. According to this approach, SPIDER rejects the call request and informs the caller that the callees consent is requested for the call s establishment. With the new configuration, the requested resources are decreased, the promptitude is faster and furthermore, there is no large processing overhead. As the mechanisms effectiveness is concerned, consent-based communication technique is reliable, since for the call to be established the consent of the callee is required. On the other hand, it is clear that a request for consent may have the exact same annoyance to a phone ringing. 8. CONCLUSIONS VoIP is attractive to spitters, as it offers the capability of mass automated transmission of voice messages, in a low cost and with a push of a button. In this paper the anti-spit techniques and the anti- SPIT mechanisms that have been proposed up to today for dealing with SPIT were examined and evaluated. The criteria that have been used and the conclusions HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 62

15 drawn by the evaluation, have led to a certain specification, which an anti-spit mechanism should fulfill to be efficient. Finally, a new and provably efficient anti-spit architecture, called SPIDER, is described and evaluated. ACKNOWLEDGMENTS The authors would like to express their appreciation to Stelios Dritsas (AUEB) and Marianthi Theoharidou (AUEB) for their most helpful comments and suggestions. We also thank all our colleagues in the SPIDER consortium; among them Sven Ehlert (Fraunhofer) and Yacine Rebahi (Fraunhofer) are to be specifically mentioned. REFERENCES [1]. J. Rosenberg, C. Jennings, The Session Initiation Protocol (SIP) and SPAM, February [2]. A. Johnston., SIP: Understanding the Session Initiation Protocol, Artech House, [3]. VODASEC, SPS: A SPIT prevention system for voice-over IP telephony services, USA, [4]. H. Y. Youm, Technical Means to Combat SPAM in the VoIP, Q.9/ SG17, ITU-T, [5]. D. Kuhn, T. Walsh, S. Fries, Security Considerations for Voice Over IP Systems, Special Publication No , NIST, USA, January [6]. J. Rosenberg, et al., Session Initiation Protocol, RFC 3261, June [7]. S. Dritsas, J. Mallios, M. Theoharidou, G. Marias, D. Gritzalis, Threat Analysis of the Session Initiation Protocol Regarding SPAM, in Proc. of the 3 rd IEEE International Workshop on Information Assurance (WIA 2007), pp , IEEE Press, USA, April [8]. G. Marias, S. Dritsas, M. Theoharidou, J. Mallios, D. Gritzalis, "SIP vulnerabilities and anti-spit mechanisms assessment", in Proc. of the 16 th IEEE International Conference on Computer Communications and Networks (ICCCN '07), pp , IEEE Press, USA, August [9]. J. Mallios, S. Dritsas, B. Tsoumas, D. Gritzalis, Attack modeling of SIP-oriented SPIT, in Proc. of the 2 nd IEEE-IFIP International Workshop on Critical Information Infrastructures Security (CRITIS 07), Spain, October [10]. P. Ning, D. Xu, Learning attack strategies from intrusion alerts, in Proc. of the 10 th ACM Conference on Computer and Communication Security, pp , ACM Press, USA, October [11]. B. Schneier, Attack trees: Modelling security threats, Dr. Dobb's Journal, December 1999 ( (accessed Nov. 12, 2008). [12]. S. Mauw, M. Oostdijk, Foundations of Attack Trees, Lecture Notes in Computer Science (LNCS) Vol. 3935, pp , Springer-Verlag, [13]. G. Madhosingh, The Design of a Differentiated SIP to Control VoIP SPAM, Technical Report, Computer Science Department, Florida State University, USA, [14]. J. Rosenberg, C. Jennings, The Session Initiation Protocol (SIP) and SPAM, draft-ietf-sippingspam-05, July 9, [15]. S. Dritsas, J. Soupionis, M. Theoharidou, J. Mallios, D. Gritzalis, SPIT Identification Criteria Implementations: Effectiveness and Lessons Learned, in Proc. of the 23 rd International Information Security Conference (SEC-2008), Samarati P., et al. (Eds.), pp , Springer, Milan, September [16]. N. Croft, M. Olivier, "A Model for SPAM Prevention in Voice over IP Networks using Anonymous Verifying Authorities," in Proc. of the 5 th Annual Information Security South Africa Conference (ISSA 2005), South Africa, July [17]. B. Mathieu, et al., SPIT Mitigation by a Network-Level Anti- SPIT Entity, in Proc. of the 3 rd Annual VoIP Security Workshop, Germany, June [18]. Y. Rebahi, D. Sisalem, T. Magedanz,, SIP SPAM Detection, in Proc. of the International Conference on Digital Telecommunications, pp , France, August [19]. K. Srivastava, H. Schulzrinne, Preventing SPAM For SIPbased Instant Messages and Sessions, Technical Report, University of Columbia, USA, [20]. S. Dongwook, A. Jinyoung, S. Choon, Progressive Multi Gray-Leveling: A Voice SPAM Protection Algorithm, IEEE Network, 20(5), pp , September/October [21]. R. Baumann, S. Cavin, S. Schmid, Voice Over IP - Security and SPIT, Swiss Army, Technical Report, August-September [22]. H. Tschoferig, R. Falk, J. Peterson, Using SAML to Protect the Session Initiation Protocol (SIP), IEEE Network, Vol. 20, No. 5, pp , September/October 2006 [23]. S. Niccolini, SPIT prevention: State of the art and research challenges, Network Laboratories, NEC Corp., Germany, [24]. R. Dantu, P. Kolan, Detecting SPAM in VoIP Networks, in Proc. of Steps to Reducing Unwanted Traffic on the Internet Workshop, USA, July [25]. M. Hansen, J. Moller, T. Rohwer, G. Tolkmit, H. Waack, Developing a Legally Compliant Reachability Management System as a Countermeasure against SPIT, in Proc. of the 3 rd Annual VoIP Security Workshop, Germany, June [26]. J. Peterson, C. Jennings, Enhancements for Authenticated Identity Management in the Session Initiation Protocol, RFC 4474, August [27]. (accessed Nov. 11, 2008) [28]. M. Chew, J. Tygar, Image Recognition CAPTCHA, in Proc. of the 7 th International Information Security Conference (ISC 2004) Springer, pp , September AUTHORS Panos Stamatiou is a Helicopter Commanding Officer. He holds a B.Sc. (Informatics) from the Hellenic Open University, Greece ( [email protected]). Dimitris Gritzalis is an Associate Professor of ICT Security with the Dept. of Informatics of the Athens University of Economics and Business, Greece. He is, also, with the Dept. of Informatics of the Hellenic Open University ( [email protected]). Manuscript received 14 November HOUJOI Hellenic Open University Journal Of Informatics houjoi.eap.gr 63