One of the largest difficulties people with a strong telecom background have when first encountering SIP is understanding that SIP is not just “another telecom protocol.” From the advent of automatic switching in the early 1900s, telephones have operated in a rather predictable way: the phone communicated hookstate and dialed digits to a central office, and the central office told the phone when to ring. All of the intelligence lived in the network, so that’s where the services lived.

This changed slightly with the introduction of mobile phones, which needed to know a bit more about what was going on with the call. But the protocols used by mobile phones were designed to closely mimic the way early-20th-century phones worked – all the way down to having a “hook flash” message.

So, as long as you’re younger than 100 years old, anything you ever learned about telecom protocols generally had a direct conceptual translation into the protocols that came after it. Electromechanical exchanges gave way to channel-associated MF switching, which eventually evolved into digital switches; but the basic flow of information remained unchanged. Services always had to live in the network, because that was the only place smart enough to do anything useful.

SIP changed all that.

SIP’s model for service interaction was not the telephones of the 1920s; it was that of the Internet. On the Internet, applications run in the clients, so that’s where the intelligence is. The network’s job is to route traffic efficiently and otherwise stay out of the way. For example, if you look at the various ways that three-way calling can be implemented, you’ll notice that the key players are the SIP terminals, not the network.

This is a radical shift, and it means that everything you know about telecom protocols no longer applies. It means that questions like “how do you interwork SIP with CAMEL?” don’t just lack answers, but actually make no sense at all. You’re asking how the network can provide services in a protocol that relegates services to the client. It’s the functional equivalent to asking, “how do you implement call waiting in a old-fashioned PSTN phone with no support from the end office?”

That’s not to say people don’t try to find answers to these questions. Many a SIP network architecture has been designed to emulate, as closely as possible, the PSTN. Most of the time, these networks require proprietary extensions to SIP and ridiculous contortions to fit SIP’s round peg into the PSTN’s square hole. The end result is a network that cannot live up to SIP’s promise of advanced services and interoperability, while having a tortured time of even providing the same basic services the PSTN can already provide.

What this means is that, when thinking about how to provide services in a SIP network, you must step back and ask “what is the problem we’re trying to solve, and how do we solve it with the tools that SIP provides,” instead of staying focused on how to directly translate the existing protocols into SIP procedures. Otherwise, you’ll end up asking nonsense questions and proposing ridiculous solutions.

When talking about fraud in communication networks we can roughly distinguish two types: stealing from the operator and fooling a subscriber.

According to the Communication Fraud Control Association (CFCA) in traditional telecommunication networks it is estimated that fraud accounts for annual losses at an average of 3% to 5% of operators’ revenues and is still increasing at a rate of more than 10% yearly. Hence, with the openness of VoIP technology one can expect an even higher threat of fraud and higher losses of revenue. Actually, there have already been various press reports about identity stealing and misuse of services, which makes fraud the biggest threat to VoIP providers currently{1}.

The other kind of fraud, i.e. the one targeted at subscribers, is commonly called phishing. Phishing can be defined as impersonating a trusted organization or a VoIP provider and asking customers for some private information in order to fix a “pretend” problem.

Identity management has been often hailed as the magic pill against all kinds of security illnesses with the Internet. Being able to make sure the identity displayed by our phone is not stolen or manipulated is great.

But does it really solve all fraud problems. I doubt this.

Looking at fraud in the context of network operators we can observe that the PSTN had a kind of identity management for ages. It is not really trivial to use a different phone number when making a call than the one allocated to us by the operator. However, we still have these statistics about revenue losses of 3% to 5%. Looking at the type of fraud conducted we can easily conclude that it was not based on the manipulation of identities but on the stealing of identity. A fraudster that has access to the components securing our identity whether these components are a credit card or a password can conduct fraud regardless of the strength of the identity.

Identity management is probably most useful in ensuring that when juliana@sisalem.de is displayed on my phone, I can be sure that it is really my dear daughter. But what would happen if I get a call from berlin@police.com telling me that my daughter is being held in custody and that I should come over and pick her up? Would I think, well this cannot happen as my daughter would never do something wrong and that the official address of the police is anyway berlin@police.de and not berlin@police.com or would I rush to the police station? Well I do not know what I would have done but considering that I know that my phone only displays authenticated identities, I might not have noticed that small difference in the ending and might have rushed to the police station to happily find out that my daughter is not there. I would be, however, upset when I come home to find that someone else was there during my absence and has relieved me of all my valuables.

So what is the punch line: Identity management is important but just as with PSTN or the banking system, by itself it will not solve all fraud problems. Even secured identities can be stolen or people can be fooled into believing that the fraudster’s perfectly authenticated and valid identity is the identity of someone they trust. So deploying identity management will not relieve us from using our common sense and being careful as technology by itself is unfortunately not a magic pill.

{1} References & Other Resources

• Voxilla – VoIP Fraud: The Industry’s Best-Kept Secret
• Egyptian Story: A cat-and-mouse story from a SIP provider in response to questions about the nature of a security incident reported in 2007
• SIP Security Book

SIP itself is not a transport protocol. It relies on other protocols to carry it from element to element. SIP was designed to allow almost any transport protocol to be used. Currently, the specifications define how to carry SIP using the User Datagram Protocol (UDP), the Transmission Control Protocol (TCP) (which is also used for SIP using Transport Layer Security (TLS)), and the Stream Control Transmission Protocol (SCTP). There are extension points built into the protocol that will allow new transports to be used as they become needed.

SIP transactions (request-response exchanges) use state machines to ensure the various transports get used correctly. These state machines are designed to take advantage of transport reliability when it exists, and to ensure reliable delivery of messages themselves when the underlying protocol does not offer that guarantee.

A given request may be carried over several different transports as it makes its way through SIP proxies towards its destination. A pair of state machines work in tandem along each SIP-stateful “hop” to ensure the message is transported successfully. In the following figure, a request starting at the caller traverses a UDP hop, an SCTP hop, and a TCP hop before reaching the callee. The callee’s response is returned along the path the request created. The leftmost pair of state machines will use timers to periodically retransmit messages to protect against dropped packets over the UDP hop. The other state machine pairs will only run timers to measure how long to wait for a response and will not cause retransmission to happen.

The SIP messages exchanged by those state machines carry a record of what transport is being used. Each element sending a request adds information about itself to the Via header field by adding a value before any other values. The messages traversing the right-most hop in the figure would have a set of Via header field values similar to the following:

Via: SIP/2.0/TCP P2.tekelec.com;received=10.0.0.3;rport=5060;branch=z9hG4bK939ddn23d
Via: SIP/2.0/SCTP P1.tekelec.com;received=10.0.0.2;rport=5060;branch=z9hG4bK33u9c9wjnn32s
Via: SIP/2.0/UDP caller.tekelec.com;received=10.0.0.1;rport=5060;branch=z9hG4bK776asdhds

A given request may also encounter very different protocol hops down different branches of a forked request

Each of the different transport protocols has advantages and shortcomings. UDP, for instance, does not provide congestion control and networks may behave badly when packets fragment. TCP exhibits head-of-line blocking by design, potentially resulting in high latency for many messages when things don’t go smoothly for just one of them. The choice for which protocol to use depends very much on the network properties and application goals for each hop. Service providers can use the DNS-based mechanisms defined in “Locating SIP Servers” (RFC3263) to let an element know which transport to use.

It has been nearly two years since 3G Americas published its whitepaper, Why SIP-I – A Switching Core Protocol Recommendation for GSM/UMTS Operators, providing a strong argument for using SIP-I as the recommended voice call control for GSM and 3G networks. The whitepaper compared SIP-I with ISUP encapsulation, SIP-T (IETF standard) with ISUP encapsulation and Bearer Independent Call Control (BICC); and provided a convincing argument in favor of SIP-I. All the standard bodies, including 3GPP, ITU, ETSI and ANSI, have chosen SIP-I as the session control protocol for the reference architecture.

But when we look at network deployments, BICC continues to show strong deployment presence in many 3G networks. Many of the investments in BICC-based core networks are recent and continue today. Therefore, it will be a long time before this infrastructure is written off by operators. However, it is more likely that BICC will remain confined within an administrative network domain, with a Network-to-Network interface between domains using SIP-I. This necessitates interworking between BICC and SIP-I.

While a Softswitch gateway-based solution was suitable for ISUP-SIP interworking, it is not the most efficient solution for BICC-SIP interworking. ISUP-SIP interworking must handle media incompatibility, whereas BICC-SIP interworking could take place purely in the signaling domain (provided there is media compatibility), since both use RTP for voice. The ideal place to implement such interworking is at a Signaling Proxy. There are three potential proxies where such interworking could take place:

1. The Signal Transfer Point (STP) that acts as a routing hub for the BICC messages at the SCTP layer
2. The Call Mediation Node (CMN) defined in the 3GPP R4 architecture. This is the BICC equivalent of the SIP Proxy Server
3. The SIP Proxy Server

With these thoughts, I’d like to open up the discussion to our reader community. Here are a few questions to get the dialogue going:

• Do you agree that BICC-SIP interworking at the signaling plane makes sense and not in a Softswitch or an MSC Server?
• If so, in your view, which of the three nodes above is better suited architecturally? And why?
• Do you think that more standards work is necessary and where should it be done.

This is the third (of three) blog posting on the topic of “identity management” in SIP-based networks. The first posting was on March 10th, 2009 and the second posting was on March 24th, 2009.

This time I would like to pay attention to phenomena I have observed for years in the industry: technology adopters seeking to solve compelling problems by purchasing a “magic bullet box.” However, does this really work for security problems with Internet telephony?

Is there a Magic Bullet Box for SIP Security?

It would certainly be nice if there were. Clearly operators would like to spend time on increasing service portfolio and subscriber base, as opposed to solving technical problems. Technical problems are a liability and ideally such a liability can be removed by a “liability remover”. Nicely packaged, plug-and-play, served in a gift wrap — a problem-solving box is a compelling value proposition.

• Can we have such a box that addresses VoIP security threats?

• Can we have a box that detects security attacks and stops them without impacting legitimate traffic? Can the so well publicized “deep packet inspection (DPI)” provide us with effective help?

• Can “hardware solutions” be a cure for denial of service (DoS) attacks? Particularly, can a Session Border Controller (SBC) make your network secure?

The Bad News

The bad news is that all these fascinating tools are more placebo than an effective cure. Unlike with medicine however, a false feeling of security can have a devastating impact on the actual system which remains exposed to threats from the public Internet. Securing networks is a constant battle between attackers and defenders. This is in fact an ultra-dynamic war, rather than a static one in which fortresses used to play a role.  Attackers generally do not tick in quarterly cycles, many box manufacturers do however. As attacks become more sophisticated, so do the protection boxes — yet with an inherent delay and increasing complexity, which is in turn an inherent enemy of security.

In particular, do you think that a “deep packet inspection” vehicle (i.e. software) put in front of applications (software too) can improve reliability of the whole system? Do you see a parallel with improving reliability of a light bulb by putting another bulb with it in series? In general in software engineering, the number of lines of code is quite unlikely to increase a system’s reliability.

Establishing a Secure System

I think that for building a secure system, you really have to work hard on simplicity. Simplicity is easy to audit and hard to crack. Security by simplicity is not about building grand architectures consisting of fascinating baroque boxes. It is about systematic elimination of all unnecessary stuff.

A well established service system has three parts: transport, application, and policy.

Transport security is a well understood phenomena addressed by conventional firewalls. They have a set of static rules that allow them to discriminate trusted traffic from untrusted traffic.

Frequently they also can provide effective means of preventing well known attacks such as SYN attacks. So far, so good. If they come with “Application Level Gateways”, just turn them off.

The most likely though undesirable outcome of leaving them on is that they will drop legitimate traffic their builders have not anticipated.

Application security is, measured by number of incidents, most importantly about robustness of server software in use. Too frequently we witness software that is not mature enough to deal with rough traffic coming from the public Internet. I’m personally rather conservative in this matter and believe that you cannot beat open-source software that has benefited from public scrutiny, rather than proprietary software. (On this note I feel compelled to mention that Tekelec’s SIP routing products have in their heart the open-source SIP Express Router (SER) foundation.) Of course, regular maintenance and updates are a necessary part of the story.

Last but not least the application policy comes in play: who can talk with whom, who may get a “VIP service”, which calls are forbidden, a.s.o., a.s.f… This is a part of the definition of a provider’s service and cannot be addressed by anyone else other than the provider. Occasionally it involves some low-level protocol decisions such as disallowing call redirection.

In Conclusion…

What is the conclusion? First of all, security does not come for free. A box cannot replace a hard-thinking analytical process. It takes an accurate definition of the transport-level and application-level policies, and choice of software that has been built for use in the public Internet. (A group of us recently published a book about SIP Security, which hopefully will help to create a more thorough understanding of all the delicate aspects.)

If you are really worried about security of a SIP service, learn a lot about it first. Then choose software that has been known to operate in harsh Internet conditions. Keep it well maintained. Surround it with conventional firewalls that don’t do deep packet inspection and cannot damage applications. Spend time on defining your application policies – no one else can do it for you.

Where is the SBC here? It is funny, but it seems that you just built a secure and SBC-free network, like in fact many other public SIP service providers did. Congratulations!