Problem solve Get help with specific problems with your technologies, process and projects.

SIP network security measures

Learn about specific security measures that can protect your oganization in the event of a SIP-based network attack. This chapter details the different types of SIP attacks and discusses various security measures and solutions to protect your network.

Session Initiation Protocol (SIP): Controlling Convergent Networks
Chapter 7, Security in a SIP Network

Session Initiation Protocol (SIP): Controlling Convergent NetworksLearn about security in a SIP network and find out how an organization can protect itself from SIP-based VoIP and network attacks. In this section, you'll learn about the specific security measures that can be used to protect your SIP network.

Session Initiation Protocol (SIP): Controlling Convergent Networks
Table of contents:
Identifying SIP-based network attacks
SIP network security measures
Security solutions for SIP management

SIP network security measures

Security remains one of the biggest issues in packet communications today. When one looks at the many security breaches and network attacks to date, security was seriously lacking. We already talked about one specific case where the perpetrator was able to hack into thousands of computers where even the simplest of security measures (changing the password) had not been practiced.

Security can be very robust and sophisticated, and it can be very simple. Don't be fooled into thinking that highly complex and sophisticated security measures will prevent attacks on your network. Some of the world's most secure networks have been breached.

However, this is no excuse for not implementing any security at all. When you look at the makeup of network attacks, there are basically two types of attackers: one that is looking for the easiest networks to breach (little to no security) and one who seeks out those with very high security (the challenge). Why, you might ask?

Think about those networks with very high security. There is usually something there worth stealing; otherwise, there wouldn't be so much security. If there is something of value to the hacker, then the hacker will attempt to break in. There is also the concept of a challenge. There are many who just want to be able to say they were able to do it as a personal challenge.

So what does this mean for the average network operator? This means you certainly have something worth stealing, so you definitely need to protect it. But you need not spend a fortune doing so, since we already know that the best security available is still breachable. You should take some basic measures at the very least to prevent being attacked just because your network is so easy.

Know that the more security you put into place, the least likely a hacker is going to choose your network unless there is something specific they want from your network. It's the same concept used in physical security.

For example, when putting an alarm system in a home or business, simply placing signs and stickers at every entry point identifying your home as alarmed is usually enough to keep most burglars away. Why? They know your home is going to be more difficult (not impossible) and they can find another house next door that will be easier to break into. This is true as long as there is nothing inside they are looking for specifically (again, if you have something they want, they are going to try and get it).

Thieves look for the easiest way that takes the least effort, so keep this in mind when securing the network. Making it difficult for the thief but somewhat non-intrusive to the subscriber is the difficult balance. There should be as much transparent security as possible so that the users of your services are not impacted (there is nothing worse than having to enter a password three or four times to access a service).

There are many ways to implement security. Many operators have implemented session border controllers as firewalls to their network. While this is probably a good practice, thinking this will stop network attacks is dangerous. Many recent reports have proven that the majority of attacks come from within the network itself, as well as outside the network. This means that robust internal security must be implemented as well as border security to prevent the network from being compromised.

Also bear in mind that attackers are now well-funded and highly educated individuals with the backing of highly sophisticated organizations. Organized crime and terrorist cells are the most common attackers today, and it then becomes necessary to build a security plan with this in mind. We are no longer fighting the teenager with nothing to do but hack computers. We are now talking about older individuals who pursue this for a living and do nothing more than break into networks for pay.

The most basic concept in network security is maintaining a trusted domain. This means that all interconnections are made with entities that are known and can be trusted to send legitimate traffic. In security terms, the trusted domain is often referred to as the "realm."

A realm can be considered analogous to the trusted domain. It is identified in security parameters within SIP using the domain name of the trusted domain. Everything within the realm is known by the network, meaning it knows the subscribers within its own control and has authenticated all users.

Anything outside of the realm is not to be trusted and should be authenticated prior to authorizing services. This is similar to the concept used in GSM networks, where a cell phone device must first register with the network and exchange credentials. Without proper credentials, the device is denied access to the network.

This example shows how the realm is identified within a security context in a SIP INVITE:

AUTHORIZATION: Digest realm-""

When a subscriber is in their home network, and are establishing sessions within their home domain, they are still authenticated by their home network. However, the home network has all of the subscriber's credentials and can easily authenticate the subscriber without issue.

When the same subscriber is roaming in another network, the visited network does not have the credentials to authenticate the subscriber. Therefore, an agreement must be established between the home network and the visited network. This agreement allows for both network operators to exchange subscriber details necessary to authorize services, and to bill one another for services rendered when each operator's subscribers are roaming in the other operator's network.

The reason many phones do not work in other networks when you are roaming is quite simple. The operators do not have an agreement between themselves, and therefore your device is not granted authorization to access any services. This situation is getting a little better as operators partner with more and more networks, allowing their subscribers to roam in many different countries, but there is still a long way to go.

Take the cable industry, for example. The cable industry has established a federation among all of the cable operators. All members of the federation are considered as trusted domains and can exchange subscriber and billing information with one another. This means that the cable operators have effectively created a massive network of networks where their subscribers can get services as if they were in their home network without restriction.

Of course, cable operators have not gone wireless yet. Many have offered wireless services through established wireless carriers but have not launched their own networks. This is all rapidly changing as the cable industry quietly adds more and more services to its portfolio. When cable companies do build out their own wireless networks, they will be part of a huge network composed of many different trusted domains.

There are basically six aspects to securing a SIP network:

  • Authentication
  • Authorization
  • Confidentiality
  • Integrity
  • Privacy
  • Non-repudiation

Authentication requires the use of passwords and the exchange of credentials. We talked a little about this already. Whenever a subscriber registers his or her location with the network, the registrar should always challenge the initial registration. This challenge is explained in more detail in the course of this chapter.

It is unfortunate that many networks simply do not challenge registrations. Instead they verify the user identity and trust that the identity is true. This is one of the reasons there are so many attacks on SIP networks today. Simply challenging the registrations could eliminate many security breaches.

Authorization requires querying a database containing the basic account information for a subscriber. This account information provides the public as well as private identities for the subscription, and all the services the subscriber is authorized to access. This can be part of the authentication process to be most effective.

Confidentiality protects the subscriber and the subscriber's identity. It ensures that conversations cannot be snooped on, and that the subscriber can exchange information freely without the information being captured by someone else. This remains one of the big challenges for network operators, especially given the many tactics being used today to capture sensitive data from subscribers.

At the same time, it is equally important that the integrity of any data sent by a subscriber be sent intact without alteration. This includes any Web sites that may have been accessed as well. It is far too easy for hackers to access SIP messages and change the contents in an effort to change the service and where it is being delivered. It is also very easy to capture a SIP message containing text and alter the text message before it is delivered to its final destination.

Privacy can sometimes be an issue when it is openly provided to anyone. Today on the Internet there are anonymous services where e-mails and other messages can be directed in an effort to hide the address of the originator, and make it appear that the message came from someplace else. At the same time, privacy can also be offered as a feature to some clients who have a need for such a feature.

One example of this is law enforcement agents. Today when they make a call, the call does not give away their identity or the number they are calling from. This is an important service to law enforcement agencies and government alike, and it should be maintained even in the SIP domain.

Finally, non-repudiation prevents subscribers from accessing services and later denying they used those services. If the operator implements the right tools and audit systems, you should have total visibility to every network transaction that takes place. This includes any downloads that the subscriber may have made.

Today this is not the case, and the reason many operators are losing money on music and ringtone downloads. While it is true they are making money on these services, it is also a documented fact that they are losing even more money. One industry analyst firm reports error rates in the reporting of downloads to be as high as 80 percent. The reason for this is simple: no monitoring systems are capable of supporting all of the protocols used within a SIP network.

We have listed the various aspects of a security deployment. Now let's talk about the specifics behind security implementations in a SIP network. These are simple suggestions and recommendations and by no means an exhaustive description of all that can be done. Nor is this meant to be a very detailed, highly technical discussion on how these security mechanisms work. Always refer to the specific RFCs for the specifications.

Password and Access Controls

I put passwords first because this is the easiest and the most overlooked security measure there is. Passwords are painful for everyone, the consumer included. No one likes to have to deal with passwords every time they access their phone or every time they try to make a call.

What's ironic is that while we hate passwords, we would never think of leaving the house without at least locking the door, and many of us go one step further and set an alarm. Yet isn't it funny that typing in a simple password is too much of a bother?

The trouble with passwords is managing the passwords so that they cannot be compromised. This means implementing password aging, which would require everyone to change their passwords periodically. Some change their passwords every month, while others change passwords every three months.

There are several levels of password control within a network. Certainly the devices accessing the network should be protected themselves, but the network is the most critical asset to the operator, and every entity within the network should be protected as well.

This may seem obvious, yet most network operators do not change the passwords on their voicemail platforms, their gateways, or even their routers. Instead, they deploy these entities using the factory default passwords sent by the vendor. These passwords are well documented and advertised all over the Internet, which means the hackers know your passwords as well.

So the first, most rudimentary step to security in a network is to ensure that all entities within the network have their passwords changed from the factory defaults. But don't stop there, because passwords can be determined through programs developed just for this purpose. The passwords should be changed as often as can be tolerated.

This then requires an entire password management initiative. Passwords should be as long as possible (the password length makes it more difficult to crack) and incorporate as many character types as possible (numbers, letters, and symbols). This extends out to the terminals that are used to access and configure the network elements.

One of the best methods of password control (at least for terminal access) is the use of token IDs. A token ID is a completely randomized password that changes every 30 seconds or so. The password is based on an algorithm that only the software application (which resides on the host) and the password generator know. The password generator (my term) is really a little key fob–like device with a display of numbers that change every 30 seconds or more.

The numbers displayed represent the newest password, and when combined with a user's access password, they become a very difficult mechanism to hack. I strongly recommend the use of these for any terminal access, and for use on any PCs used to access any network element. A compromised PC that later connects to a network element could put the entire network at risk, given the nature of many of today's bots and viruses.


Encryption solves a lot of problems. The best means of ensuring privacy while preventing message tampering is to encrypt the SIP message prior to sending it through the network. This does present some problems, though.

If forwarding a SIP message that is encrypted, the various routers and proxies in the network will not be able to read the addresses contained within the various headers. Therefore the entire SIP message cannot be encrypted, unless every network element is going to be provisioned with the proper decryption keys (not a very likely scenario).

The other issue is forwarding the SIP message outside of the trusted domain. Not everything can be encrypted, as this would make it impossible for the other networks to read the addresses necessary for routing. This is why there are headers that are not encrypted, while the remaining SIP message is encrypted.

Encryption does require all receiving entities to have the encryption keys so that they will be able to remove the encryption (decrypt) and return the message to its original state. Without the encryption keys, the network elements cannot do anything with the message, so care must be given in deciding how to encrypt and when to encrypt. There are numerous ways to implement encryption.

One approach is to encrypt only messages leaving the network. This means there are no encrypted messages internally, since all of the elements are within a trusted domain. The problem with this approach is that most attacks take place from within the network. Therefore encryption for outbound SIP messages does not solve anything. There should be encryption internally as well as externally.

When a message is encrypted, some headers will remain in "clear text," which means they are not encrypted. The headers that are encrypted include:

  • Subject
  • Accept
  • Alert-info
  • Expires
  • Supported
  • User-agent
  • Reply-to
  • Accept-encoding
  • Error-info
  • In-reply-to
  • Unsupported
  • Server
  • Organization
  • Accept-language
  • Authentication-info
  • Require
  • Retry-after
  • Warning

The message body itself is also encrypted, which could include the Session Description Protocol. Since the SDP is encrypted, any proxies that need to read the SDP portion of the message will need to be able to decrypt the message. This is another consideration when implementing encryption, since these elements will have to know the encryption keys. This may include firewall proxies as well.

And don't forget the network receiving the SIP message. The network elements receiving the SIP message will also have to know the encryption keys in order to process the SIP requests. This is another reason that network agreements have to be made to ensure that the interconnecting networks can be trusted.

Transited networks do not have to know the decryption keys, as they do not need to know anything more than where to route the message. The headers used for routing will contain enough information for the SIP message to reach its final destination. Transport Layer Security (TLS) is a good means of providing encryption between networks, while SIP Secure (SIPS) is designed for use within a trusted domain. TLS works at the TCP layer and is best when used between two networks where two network elements do not know each other. TLS cannot be used end to end.

SIPS is used in the request-URI to indicate that TLS should be used to transport the request/response to the designated domain. Once the domain is reached, local policy determines the treatment to be used within that domain. TLS can also be used within a network, although it is best suited for interconnections with other networks.

RFC 3261 specifies that TLS is to be used at proxies, redirect proxies, and registrars when interconnecting with other networks. They should also possess a site certificate for authentication. These proxies also must have the ability to validate certificates from other trusted sites, by storing the certificates from these sites (usually elements from within its own trusted domain).

IPsec is best within a network between trusted elements. IPsec works within an "enclave" or trusted network, implemented by each of the network elements at the operating system level. Security gateways can also be used to create virtual private networks (VPNs) to make the network more robust.

Another approach to encryption is tunneling a SIP message within another SIP message. The original SIP message is encrypted and then encapsulated within another SIP message for routing. The routing information from the original SIP message is used to populate the routing headers in the outside message, but nothing else is given in the outside message.

A proxy then will only read the request-URI, VIA, RECORD-ROUTE, ROUTE, MAX-FORWARDS, and PROXY-AUTHORIZATION. These are the only headers that can be modified as the message is routed through the network. When the UAS receives a message that has been tunneled in this fashion, it compares the encrypted tunneled message with the outer message. If there are any other changes to the contents, the message is considered compromised and the original message is rejected.

To allow the sender to remain anonymous, the FROM header in the encapsulated message can remain as is, but the outer message FROM header can be set to anonymous. This helps prevent the identity of the sender from being detected while the message is transiting other networks while still providing the identity once the message is received. Of course, this header should never be trusted to begin with, since it is too easily spoofed. The network should always rely and trust only the ASSERTED IDENTITY header.

Tunneling messages prevents messages from being hijacked, modified, and then replayed into the network. As the original message has been encapsulated and sent within an S/MIME body, it should not have been altered. When the UAS compares the encapsulated message with the outer message, it will identify whether or not there have been any other alterations to the original message. Both the encapsulated message and the outer message are duplicated.

If any of the headers in the outer message are different than the headers within the encapsulated message, the encapsulated message of course takes precedence. The headers in the outer message are discarded.

Everything we have talked about so far, encryption and tunneling, applies only to the SIP messaging and not the bearer traffic itself. The bearer traffic should also be encrypted to prevent unauthorized access. Obviously the bearer traffic contains much more value to the hacker than just the SIP signaling, so it should be adequately protected as well.

The exception to this is in the case of the MESSAGE method. Text messaging uses the MESSAGE method to deliver the "bearer traffic," which in this case is a text message. The text message itself is carried in clear text within the message body of the SIP request.

Since the text is in clear text, it becomes even more important to ensure that the message body is encrypted. S/MIME should also be used within the body text to further protect the message when it is transmitted across multiple networks.

The SIP protocol does support communicating between network elements regarding the security mechanism to be used. The security mechanism is encryption, and the communications between entities are necessary to communicate the encryption schemes supported by the various nodes.

There are three headers defined as extensions specifically to support the SIP security mechanism; SECURITY-CLIENT, SECURITY-SERVER, and SECURITY-VERIFY. These are used to communicate to either the UAC, UAS, or upstream proxies the method to be used.

A UAC can query an upstream node to determine the encryption methods it supports prior to sending a request. It does this by sending the OPTIONS header. The receiving entity then returns a response containing a list of methods it supports. If the responding entity is the UAS, it would return the SECURITY-SERVER header contained in its response.

The SECURITY-SERVER header would then list the methods supported. Possible values include TLS, DIGEST, IPSEC-IKE, and IPSEC-MAN. The receiving node then returns a request along with the SECURITY-VERIFY header containing the relevant security keys. A UAC uses the SECURITY-CLIENT header to send a list of support encryption methods to upstream nodes.

Authentication and Authorization

One method of authentication is through the use of certificates. This is implemented in many Web sites today. When you set your browser to check for certificates, and you access a network resource (such as a Microsoft Web site to purchase software), your browser will ask the Web site for its certificate.

These are public certificates that are advertised to "trusted" communities so that they are able to access the sites. This works by providing the browsers with the key for the "trusted" Web site. The key is used to determine if the certificate is valid or not. Only the key holder and the application accessing the site know the key.

The key can also be provided when a subscriber signs up for a new service, such as online banking. The online banking institution would exchange the key with the subscriber upon signup for the service. The subscriber and the online banking service then are part of a trusted domain.

The certificate is associated with a specific URI using a cryptic identity. Only the receivers with the proper key can decrypt the identity and therefore authenticate the site. This concept is not perfect by any means, but it is one way of at least making it more difficult to steal services from networks.

Anytime a service is being provided, and a subscriber sends a request that is of questionable origin (has not been authenticated before), the application server should reply with a 401 Unauthorized response, forcing the UAC to send the proper credentials prior to accessing the service.

When the UAC receives this response, it should resend the INVITE again but include the AUTHENTICATION header in the message. The CALL-ID should be the same as the original INVITE so that the server knows that this is a second attempt to access services and it is in response to a previous challenge.

The AUTHENTICATION header provides the application server with the necessary credentials so that the server can provide the subscriber with the requested services. This should be practiced in all networks to prevent unauthorized access to services.

Authentication can be applied to application servers as well. As when using a certificate, each application server would be configured with a unique encryption key. Only authorized UAs would receive the proper key. When they receive a request from an application server, they would then be able to challenge the application server (the same process used against the UAC in reverse).

This would help prevent rogue application servers from sending requests to unsuspecting subscribers, and it would allow devices to challenge the servers they access. Since it is encrypted, it should be more secure than certificates.

When the MESSAGE method is used for forwarding text messaging, application server and proxy authentication should be enforced to prevent spoofing and spamming. As mentioned in the earlier section "Encryption," the MESSAGE method is used to deliver a text message. The text message is delivered in clear text within the SIP message body. This makes it vulnerable to attacks unless encryption and authentication are enforced.

A DATE header should also be enforced to ensure that there is a timestamp for every message. Any time a MESSAGE is received with a timestamp indicating it is more than several minutes old, the message should be rejected by sending the response:

The exception is when a store and forward function is used to deliver these messages. When a store and forward server is being used, the message will of course always be more than a few minutes old, since it was delivered to be stored and forwarded when the subscriber became available.

Strict Routing

This is a concept that the 3GPP introduced to be used within IMS networks. In a SIP network, a proxy is able to use any available route. The routing decisions are made in real time by each of the routers in the path, based on current availability and traffic conditions. This means that a request may take one path, while its responses may take another path. This, of course, makes it impossible to trace any of the messages or to capture all of the messages related to one session without capturing everything in the network and using a correlation engine to associate each of the requests/responses.

The exception to this rule is when stateful proxies are used, since a stateful proxy must see every response for a request in order for the proxy to be able to monitor the state of the session. If the proxy does not see all of the responses, it will not be able to determine if the request was successful, and it will not be able to determine whether or not a session was terminated (unless it sees the relevant messages).

Because of this type of deterministic routing, hackers are able to use man-in-the-middle attacks to intercept sessions and have them rerouted to another address. They are able to use replay to send copied messages back into the network without detection, even if they suddenly route responses to a different address than what was registered.

With strict routing, the routing path is recorded as the subscriber registers in the network. The REGISTER message contains the RECORD-ROUTE headers, used to collect the addresses of each of the proxies in the path. These addresses are saved in the order they were added, so that a route list can be established for the subscriber.

The route list then becomes part of the subscriber's registration. Stateful proxies in the path then also store the route list for the subscriber so that they know how to route messages (both requests and responses) to the user identity. Even if a hacker attempted a session hijack, for example, the proxies would ignore the routing provided in the message, relying instead on the route list they recorded for the subscriber during the registration.

The hacker then would have to hijack a registration and successfully register his or her own address using the subscriber identity. This is still possible, unless the network is using encryption and authentication keys, in which case the hacker would be unable to read the intercepted messages (thereby being prevented from capturing the user identity) and would be unable to pass through authentication (not having the proper authentication keys).

Strict routing does have its drawbacks, though. This is not a very efficient means of network routing because it forces traffic through specific paths regardless of network utilization at that specific time. This means the network will have load imbalance, and many facilities may sit idle during certain periods of the day.

This, of course, goes against the grain of IP networks, where routing is determined according to the network conditions. It does align more with the circuit-switched network procedures, so switching engineers will be very comfortable with this form of routing, but IT engineers will not be so thrilled about strict routing.

If used with all of the other approaches we have talked about so far, this will certainly make the network a very robust and well-protected network. Nothing is perfect, and there is no such thing as a totally secure network as we have seen demonstrated time and time again. But remember that the object to security is to make it difficult for the hacker to fool the network, while allowing your subscribers to enjoy an easy and feature-rich, yet secure network experience.

Continue to the next section: Security solutions for SIP management

Read Chapter 7, "Security in a SIP Network" from Session Initiation Protocol (SIP): Controlling Convergent Networks in its entirety.

Excerpted with permission from Session Initiation Protocol (SIP): Controlling Convergent Networks, by Travis Russell, Copyright 2008. Published by McGraw-Hill, June 2008. For more information about this book and other titles, please visit McGraw-Hill Professional.

This was last published in September 2008

Dig Deeper on SIP and Unified Communications Standards



Find more PRO+ content and other member only offers, here.

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.