The Design of a Secure SIP-Based Architecture for

The Design of a Secure SIP-Based Architecture for Broadband Service Providers Dr. Ali El-Mousa

Eng. “Mohammed Rasol” Saleem Al Saidat

Computer Engineering Department University of Jordan Amman, Jordan [email protected]

Voice Networks Infrastructure Department Jordan Telecom Group (Orange) Amman, Jordan [email protected]

Abstract— A large number of service providers are looking for a secure model that can be easily implemented in their own environments and provide a robust secure architecture against todays vulnerabilities and threats. SIP is one the most popular protocols that is used in IP multimedia subsystems and adopted by a wide level of networking vendors. This study suggests a secure distributed SIP based architecture that can be deployed in service provider data centers to maintain the service availability, security and reduce the processing on the core devices.

Keywords— SIP, SDP, SIP attacks, Security

I.

INTRODUCTION

The Internet Engineering Task Force (IETF) introduced the Session Initiation Protocol (SIP) as a signaling protocol that is used to create and manage exchanged data between associated peers. The exchanged data between the peers are considered as sessions [1]. The SIP was developed in a way to set up, modify, tear down peer sessions, request and deliver presence; and send/receive instant messages. In a few years, a lot of Internet Service Providers (ISPs) and communication vendors adopted this protocol to develop a wide variety of Voice over IP (VoIP) services such as Voice and Video conferences, call transfers, and instant messages [2]. An incredible growth of SIP based applications was noted due to the flexibility in its networking design, cost reduction, and ease of deployment compared with the legacy TDM services. The increased use of SIP services and its applications, however, faces risky vulnerabilities and security threats these days. Since SIP is deployed over IP networks, it inherits the classical threats from the IP network itself such as denial of service attacks, IP spoofing, and man in the middle attacks. Other vulnerabilities exist in SIP due to the nature of the protocols themselves such as bogus terminate attacks [3]. Other weak points that may reside on SIP platforms such as SIP proxy servers and Session Border Controllers (SBCs), form critical risks like buffer overflow and SQL injection attacks [4]. There are a lot of security protocol solutions that may be deployed in SIP core environments which Service Providers (SP) may use to secure their own network operation centers

and the clients who are served by them. It is important to build a SIP model that will contribute in serving SIP customers in a secure manner. Applications using SIP are continuously increasing in different areas including multimedia streaming applications such as IPTV and VoIP services. The SIP trunk service may eliminate the need to purchase ISDN, PRIs or local PSTN gateways [5]. The number of customers who will use these applications and services will increase as well, so it is mandatory to understand the fundamental network security services required in SIP in order to preserve the confidentiality and the integrity of the messaging, preventing also the security threats that have been mentioned previously. Furthermore, to ensure the presence of a secure authentication and privacy model for those who will be involved in different ISPs services, including messaging services like SMS texts, voice calls, fax images, and video on demand. Knowing that SIP will also serve a lot of IP users, then we should expect negative results like loss of integrity and confidentiality with unauthorized access if strong security policies are not deployed. Hence, it is important to design and implement a set of security mechanisms which are necessary to enhance SIP, both inside and outside ISPs autonomous systems. A lot of ISPs who do not secure their SIP applications faced tremendous problems and money loss. The specific type of SIP attack which affects ISPs financial gain and was exploited by hackers is referred to as 'VoIP toll fraud' [6][7]. Many attempts were suggested to find secure techniques in the deployment of SIP services over the well-known general architecture of SIP [8]. Very few researches suggest changing the architecture itself. The challenge is to come up with a secure architecture and deploy secure countermeasures which will result an acceptable SIP model. This paper proposes a new secure model. It also examines the model in a real core service provider network and tries to focus on the strong points of the SIP architecture model. Section two in this paper aims to illustrate how SIP is implemented and also to provide a real SIP scenario together with a deep discussion of SIP messages and media information attributes. The third section will classify some popular attacks that may affect the SP SIP network and show an example of a DoS attack. Additionally, this section covers previous studies

that attempt to develop SIP security models. We will discuss our proposed model in the fourth section; clarify the pros and cons after deploying the model in real SP environment. Finally the conclusion is discussed in the fifth section. II.

SIP OVERVIEW

SIP is defined by RFC 3261[1] as a text based application layer protocol which control the sessions of the SIP peers. Fig. 1 shows a SIP message exchange between two SIP phones for a VoIP service. The two SIP phones are dedicated IP phones and can be related to any client running on a laptop or PC (known as soft clients), PDAs, or mobile phones. It is assumed that both devices are connected to an IP network like the Internet and each of them can identify the peer IP address. The voice gateway is the SP edge device which provides signaling and media connectivity between the SIP peers. The first message sent from the source, contains information about the type of session or requested call and is called the INVITE message.

Fig. 1. The standard exchanged SIP messages between two SIP peers.

This message means that a SIP client is being invited to participate in a call session. The INVITE message contains the following information: INVITE sip:+962777374859;tgrp=C13420-as-HO;[email protected]:5060 SIP/2.0 Via: SIP/2.0/UDP domain1.com:5060;branch=z9hG4bKhk9phs00004hofgmt340. From: ;tag=gK0e3875bd To: Call-ID: [email protected] CSeq: 5830 INVITE Max-Forwards: 69 Allow: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE, NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH Accept:application/sdp,application/isup, application/dtmf,application/dtmf-relay, multipart/mixed

Contact: Remote-Party-ID: ;privacy=off Content-Length: 335 Content-Disposition: session; handling=required Content-Type: application/sdp v=0 o=Sonus_UAC 10461 15896 IN IP4 12.194.27.31 s=SIP Media Capabilities c=IN IP4 12.194.27.31 t=0 0 m=audio 29276 RTP/AVP 18 4 2 0 101 a=rtpmap:18 G729/8000 The fields which are listed in the above (INVITE message)

are the header and body fields. They have the form of Attribute: Value. The first line of the request message, also called the start line, lists the method, which is INVITE, the Request-URI, and then the SIP version number (2.0), are all separated by spaces. The end of each line of a SIP message is terminated by Carriage Return Line Feed (CRLF). The first header field following the start line shown in the above message is a Via header field. Every SIP peer that originates or forwards a SIP message stamps its own address in a Via header field, that is generally written as a fully qualified name and can be translated to an IP address using a query form. In the above message, the fully qualified name of the sender is domain1.com and the fully qualified name of the receiver is domain2.com. The Via header field contains the SIP version number (2.0), a “/”, then UDP for UDP transport, a space, the hostname or address, a colon, then a port number (in this example the “well-known” SIP port number 5060). The transport protocols of SIP may contain these types: TCP, UDP, TLS, and SCTP. All of these protocols are associated with a specific port number. The branch field is a transaction identifier. The responses from the receiver related to this specific request can be highly correlated to each since they will contain the same transaction identifier in the branch field. The next header fields are the To and From, these types of headers show the originator and destination of the SIP request. SIP requests are routed based on the Request-URI rather than the field of To attribute. The idea behind this is that Request-URI can be changed and rewritten as a forwarded request, while the To URI field generally remains fixed without changing. When a name label is used in the transactions, the SIP URI is enclosed in brackets < >. The name label could be displayed during the update process or on the IP phone screen. The next header is called the Call-ID which is considered as the key that is used to keep track of a particular SIP session. The SIP peer sender of the initial request creates a locally unique ID. Some older implementations also add an “@” and its host name to the ID. In consequence to the Call-ID, each party in the session adds a random unique identifier and this identifies and marks each call. These identifiers, named as tags, are embedded in the To and From header fields when the session is established. The initial INVITE in the message exist in a From tag but in a To tag. The next header field shown is the CSeq, or command sequence. It contains a number, followed by the method name, INVITE. This number is incremented for each new SIP request that is sent. Max-Forwards filed is used as a mechanism to provide loop detection where it contains an

integer value that is decremented by every SIP server hob passed through. The next field header is the Allow where the message which may be used by the SIP peers are listed below as SIP message headers such as: INVITE,ACK,CANCEL,BYE,REGISTER,REFER,INFO,SUBSCRIBE, NOTIFY,PRACK,UPDATE,OPTIONS,MESSAGE,PUBLISH. The Content-Type and Content-Length header fields

indicate that the message body is Session Description Protocol or SDP [9]. The media information is needed because SIP makes no assumptions about the type of media session to be established between the SIP peers so the originator or the sender must specify exactly what type of session (audio, video, gaming) that he wishes to establish. Table I shows the media information indicated in the message body. TABLE I. Media information description SDP Parameter v=0 o=Sonus_UAC 10461 15896 IN IP4 12.194.27.31 s=SIP Media Capabilities c=IN IP4 12.194.27.31 t=0 0 m=audio 29276 RTP/AVP 18 4 2 0 101 a=rtpmap:18 G729/8000

III.

Parameter Name Version number Origin Call subject Connection Time Media Attributes

TYPES OF SIP THREATS

Because SIP is deployed over the Internet it is exposed to a lot of vulnerabilities and threats. The following are some classified attacks that may face the SIP service providers. A. Spoofing Attacks This type of attack is caused by the impersonation of a legitimate user who can send a message to the SIP service provider claiming that he is authenticated. The hacker may also abuse the services that have been given to ISPs customers. If SIP peer credentials were stolen by a hacker, the authorized users would lose the authenticity and the service itself. Fig. 2 shows a spoofed scenario for a client who takes a service from a service provider. When the customer is given a user name and password as credentials from his ISP, he will get an IP address if the credentials are correct. The hacker tries to capture these credentials and claims that he is the legitimate user. This can be achieved by knowing the To and From header fields in the INVITE message. B. DoS Attacks DoS attack aims to degrade or interrupt a targeted service. It could be an unusual saturation of one resource which limit or block the delivery of a service. Hackers can also exploit a bug in equipment such as the sending of a specifically crafted packet to crash the equipment. SIP DoS attacks have different types according to SIP attack themselves or the way which the attackers make their vulnerabilities in the SIP applications. It may cause the consumption of the network bandwidth [10].

Fig. 2. SIP threat caused by a hacker who spoofed the authentication and IP address.

The attacker may modify, deny, alter or hijack the VoIP calls and this occurs in the SIP messages flow. The attackers may also send a high SIP volume messages to the session border controllers of the SIP service providers where these SBCs will process each request then the SBCs will hang because of the high number of concurrent SIP requests. Fig. 3 shows DoS on a 2x10Gb/s optical link between two routers on an ISP residential backbone. It can be noted that during 24 hours the spike attacks happened twice where the utilization of interfaces reached 100% and this caused an operation down since the interfaces capacity became full on the2x10Gb interfaces. The outgoing traffic is the clean traffic which is affected during the DoS attack and reached zero utilization in the spike interval. C. Interception and modification attacks In this type of attack the attacker intercepts the SIP messages in the sessions between the sender and receiver and tries to eavesdrop on the SIP and RTP packet. The attacker can analyze the media parameters listed in table I, hence, he can listen to calls. He can also decode the parameters of RTP like the attributes which provide information about the call codecs. The attacker may also alter the content of the SIP messages such as changing the route of the SIP packets toward another SIP service provider gateway.

Fig. 3. DoS attack on a 2x10Gb/s optical link between two routers on Service provider residential backbone

D. Miscellaneous Attacks There are a number of different attacks that may occur on a SIP service related to the weakness architecture of the SIP model that is implemented at the service provider and results from specific attacks like DoS attacks. If the model of service provider is weak, then the users may lose the service during the attack and this happens especially if the service provider has one device of the session border gateway. The attackers may send a lot of fake SIP messages to increase hardware resources of SIP platform then affect the performance of the SIP services. Previous studies try to find robust secure solutions for the mentioned SIP attacks and help the SP to deploy these solutions in their service networks. Jinlong [11] suggested an important approach for SIP security architecture based on Source Address Validation (SAV) of the SIP agents. He also proposed a new SIP security architecture including a new security framework, and a two way authentication algorithm from the core network to the SIP agents with Identity Based Signature (IBS) approach, which enabled the SIP agents who do not need public key certificates but they require a private key generator to maintain a directory of public system parameters. This study illustrated the IBS based Identity Security Algorithm (IISA) scheme model and IBS security algorithm but it did not provide a practical measure for deploying these security algorithms on real networks. Another study by Zhang [12] who discussed the security threats that hit the SIP proxies like Denial of Service (DoS) attack on VoIP system by exploiting the long response times of external infrastructures. The research showed how the attack can force the whole VoIP system into a blocked state thus reducing the availability of its provided signaling services. They also conducted experiments to prove the feasibility of blocking attacks that result from DoS attacks. The research presented security DoS attacks that affect ISPs network but it did not address other types of attacks that may affect the ISPs platforms. IV.

PROPOSED MODEL

Our proposed design for a SIP based model for SIP service providers is illustrated in fig. 4 with the registration requests flow that is initiated from the SIP peer edge to the access network toward the SIP core network for the SIP service provider. In this proposed solution, the architectural design of the SIP model provides the possibility of any subscriber to any location subscription. This means that if user A is located in location X then he may take the service from two different locations (A data center and B data center) which dynamically assign a serving SIP service to that subscriber. This assignment occurs in conjunction with a registration operation. After a subscriber is assigned to a serving location and their related configuration (customer’s profiles, offers, etc.) is downloaded, the subscriber will be able to send and receive calls. This functionality is critical for recovery of services following a catastrophic event that destroys the data center location (e.g., natural disaster).

Fig. 4. Proposed secure SIP based model for broadband services.

The model contains the following nodes: A) CPE or customer premises edge device that is used as a SIP client and acts as user agent server or user agent client. The SIP IP phones may be connected to the CPE on RJ45 ports or it may contain FXS ports for the legacy analogue phones. B) SBC or the Session Border Controller which is considered as the gateway of the CPEs and it handles all the SIP peer registrations and SIP call requests. SBCs also forward the calls to the local switches in the TDM network if an IP user wants to call a PSTN subscribers or mobile subscribers. C) Proxy server: This service loads the subscriber profiles and the customer offers. It is also responsible for call processing. It also controls call routing and acts as intermediate device between the SBC and the DB servers in order to send a grant ticket during the SIP registration phase. D) The data base server is the main repository of the customer’s information. It contains specific tables for the directory numbers and the SIP peer credentials. E) DNS server is used to allow a SIP peer to resolve a SIP Uniform Resource Identifier (URI) into the IP address, port, and transport protocol of the SBC in order to contact it. The DNS server is used to allow the SIP peers to contact the SBC in X location if there is a failure on a second location. As shown in Fig. 4, the model call flow in this architecture is initiated with the CPE which sends a query request to the DNS server asking which SBC should be contacted. The DNS responds with SBC IP address. In step two the CPE will contact the SBC for registration in order to be authenticated for originating a SIP calls, receiving them or asking for SIP multimedia service. The SIP peer user will send an invite message to the SBC in site A for example asking to connect. The SBC will also reply with a challenge or none, and then the original SIP peer user will respond and send username and password in message digest to the SBC. In step three and before sending the SIP 200 message (typically known as an

OK message) to the SIP peer, the SBC will send a request to the proxy server asking if the request which came from the SIP peer is authorized to get the requested SIP service. Step four shows that the proxy server will send the SIP peer respond to the database server inside location A. In step five* the data is matched from the local DB and remote DB server. This is to ensure data stability in the response. If the data is validated, then the DB returns the grant response in step five ** towards the proxy server. In step six a grant ticket is sent from the proxy server towards the SBC, else the request will be canceled. If the request is valid the SBC server will send a 200 message OK in step seven. Now the SIP peer is permitted to get the SIP service.

model where each SBC receives the SIP requests independently, it is noted that the SIP registration attempts were very high with respect to the total number of successful SIP registration counts in the period between 7th December and 11th December. This caused a high number of running processes on the SBC which handles the SIP. On 18th December the proposed model was deployed and it is noted that the SIP registration attempts were decreasing which means that the proposed model positively influenced the performance on the SBCs due to the fact that the processes of the Attempts are minimized.

If this model faces a DOS attack, the DNS will route the traffic to a clean site until the attack is stopped by a mitigation security system. If the SIP traffic is spoofed, the Call-ID attribute in the SIP header will identify the call. This will be used as a reference to detect the status when two calls are occurred simultaneously with two different Call-ID. This means that the subscriber service is spoofed and a tracing mechanism should be acting to identify the real source of attack. In a test lab environment that contained SBCs, proxy servers, and database servers from SONUS networks [13], we simulated the original SIP model and checked the SBCs performance together with the number of registration counts on the SBCs. It was noted that the number of registrations decreased on the SBC in site A because the registration of SIP peers were distributed between the SBCs in the two locations. Thirty five SIP peers were connected to site A, then after two hours the configuration was changed to the proposed secure SIP model in Fig. 4. The results of the registration count before and after are shown in Fig. 5. It is obvious that the overhead processing is reduced in each SBC.

Fig. 6. Registration counts for SIP attempts and total successful SIP registration.

Deploying this proposed model in a service provider platform provides the following advantages: • • • • •

Fig. 5. Registration count statistics for 35 SIP peers moved after 02:00 clock on the SIP model discussed in Fig. 4.

Registration SIP counts statistics were extracted before deploying the proposed SIP model and after applying it. The results are shown in Fig. 6. Before deploying the proposed SIP

Active geographic redundancy: This results from having two different replica data centers in two different locations. Enhanced availability: Based on the DNS server the SIP provider can route the SIP requests toward a specific data center. Dynamic subscriber association: The SIP peer may send the request of service registration in site A and make the calls using site B and vice versa. Load balancing: The subscriber may make the first call from site A and the second call from site B and so on in Round Robin mechanism. Simpler subscriber management: Since the data base servers in the two data centers are replicated then it is easy to manage any subscriber from any site.

This model provides as well a secure SIP system against fake SIP sessions that may occur as each session is authenticated from two different locations. It is clearly noted that if one of the SBCs faces a DoS attack then the SIP traffic can be routed to another site without affecting the service itself. The drawback of this model is that it is only applied on the SIP core networks while other protocols like H323 and MGCP is not applicable here because of the complexity in the messages transactions that is needed. Table II shows a comparison

between the generic SIP architecture and the proposed secure model. TABLE II. Comparison between the general SIP architecture setup and the proposed secure model. Comparison point

General Architecture Setup of SIP

Proposed Secure Model

Philosophy

The design is built to allow flexible signaling connectivity between two SIP peers.

This model is built to provide secure service for both SIP peers and service providers.

Simple

More complex than the generic SIP model

Complexity

Reliability

Cost

Scalability

Security

REFERENCES [1]

[2] [3]

[4] [5] [6]

In this model SIP is depend on procedures to handle the failure states. For example use the reinvite message and depend on SIP session timers

Here the SIP will be more reliable because of the SIP procedures and the redundant setup of the service core

Less cost

More cost

[9]

It will depend on the SBC or the session handler

There will be load balanced where the scalability will be noticed more

[10]

Lack of security if the core is attacked.

More secure setup even in the attack time where the sessions will be directed to the health site.

V.

CONCLUSION

This paper introduced a secure SIP model design that service providers can use to provide broad band services like VoIP and IPTV. This model suggest a full geo redundant setup for the SIP core networks which can be recognized as a good solution against a variety SIP vulnerabilities and threats which may affect the service provider networks. The load balancing mechanism with the rigid registration technique that have been used in this model empower the service provider to deliver a high quality SIP based services. The current model may be developed in the future to reduce more threats according to certain call flow which can be considered as added value techniques similar to encryption and IPsec.

[7] [8]

[11]

[12]

[13]

Rosenberg, Jonathan, Hennmg Schulzrinne, G. Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley, and E. Schooler. "RFC 3261." SIP: session initiation protocol 6 (2002). Sacker, Stephen M., Matthew Santaiti, and Catherine Spence. "The Business Case for Enterprise VoIP." Intel Corporation (2006): 6. Werapun, W., A. Abou El Kalam, B. Paillassa, and J. Fasson. "Solution analysis for SIP security threats." In Multimedia Computing and Systems, 2009. ICMCS'09. International Conference on, pp. 174-180. IEEE, 2009. Keromytis, Angelos D. "A look at VoIP Vulnerabilities." ; login: 35, no. 1 (2010): 41-50. Janne Magnusson: SIP trunking, benefits and best practices, Ingate Systems whitepaper,(2006). Dantu, Ram, Sonia Fahmy, Henning Schulzrinne, and Joao Cangussu. "Issues and challenges in securing VoIP." computers & security 28, no. 8 (2009): 743-753. Keromytis, Angelos D. "A look at VoIP Vulnerabilities." ; login: 35, no. 1 (2010): 41-50. Rehman, Ubaid Ur, and Abdul Ghafoor Abbasi. "Security analysis of VoIP architecture for identifying SIP vulnerabilities." In Emerging Technologies (ICET), 2014 International Conference on, pp. 87-93. IEEE,(2014). Handley, Mark, Colin Perkins, and Van Jacobson. "SDP: session description protocol." (2006). Rahangdale, Tarendra G., Pritish A. Tijare, Swapnil N. Sawalkar, Zameshkumar J. Balhare, Vijay S. Gulhane, Shruti S. Mane1 Varshika V. Parmar, Soumitra C. Limaye et al. "An Overview on Security Analysis of Session Initiation Protocol in VoIP network." (2014). Jinlong, Hu, and Liao Bin. "SIP Security Architecture Based on Source Address Validation." In Computer Science & Service System (CSSS), 2012 International Conference on, pp. 300-303. IEEE, 2012. Zhang, Ge, Simone Fischer-Hübner, and Sven Ehlert. "Blocking attacks on SIP VoIP proxies caused by external processing."Telecommunication Systems 45, no. 1 (2010): 61-76. Sonus softswitch services, http://www.sonus.com/