In a recent blog posting (“This is Not Your Father’s Phone Network“, by Adam Roach, June 30, 2009), my Tekelec colleague made a powerful argument that concepts such as SIP to SS7/CAMEL interworking make no sense at all.  However, I continue to come across highly knowledgeable telecom professionals from our customer base who see a clear need for it. So, I’d like to present a counter view respectfully disagreeing with my esteemed colleague. Even if one of us may be wrong, a healthy dialogue is always welcome.

The need or lack of need for SIP – SS7 interworking does not arise from the technology, but rather is driven by the business needs. It is an undeniable fact that there are 4+ billion mobile handsets today that are neither SIP-enabled nor served by SIP-enabled mobile switching centers (MSC).  Service transparency while roaming is a critical requirement for many operators. This imposes further restrictions in adopting new service delivery technology. These 4 billion handsets follow people wherever they go and offer a potential “instant” market for any type of new service. On the other hand, when we look at the service platforms SIP represents the better option vis-à-vis IN/CAMEL (particularly for real-time services such as voice and video). It provides better future-proofing of investment, offers a more flexible platform that enables quicker rollout of services and offers more subscriber control of the services. The bridging of these two allows operator to use the best technology for the service delivery platform and also provides instant access to the 4+ billion subscribers while at home or while roaming.

It is also important to understand that the need for SIP-SS7 interworking is not to replicate services such as 3-way calling, which are already solved. It is equally true that SIP offers several capabilities that are impossible to replicate in the pre-SIP world. But that should not stop us from identifying services that have common denominators. Numerous services are feasible using basic session control capabilities (Continue with a session, Redirect the session to a different address, Release the session, Play announcement, collect user input etc.) common to both SIP and SS7.  Business Voice services such as enhanced private dialing plan, residential Voice services such as parental call control are a few examples that have potential to take advantage of IP technology and provide higher subscriber control and therefore enhanced value.  These services can be implemented using SS7/CAMEL, but SIP is a better technology option. It is also practical to map the SIP call control features to the CAMEL call control features for these services.

To address Adam’s next concern – that SIP-SS7 interworking requirements are driving proprietary extensions to SIP – resulting ultimately in SIP failing to deliver on its promise of advanced services. That should not be the way, but unfortunately some SIP extension work does fall into this category. The evolution of SIP should not be hindered by the limitations of SS7, but it should be the other way. A subset of capabilities that is common to SIP and SS7 (as explained above) can be adopted to enhance the services that can be provided to non-SIP subscribers. Meanwhile, it should not exclude the possibility of bringing an avalanche of new IP-based services to a next generation of handsets.

The role of network as a dumb router vis-à-vis network hosted services is not going to be decided by the choice of protocol or technology. It is a business issue and business will find an answer for that and the technology will be the one to follow and adopt it. The answer may be in the middle. A smart handset may be the answer to implement a 3-way call, but network hosted service may be the choice when multi-party conferencing is required. It is  possible that a different business model may emerge around a new value chain that involve players providing network pipes, centrally hosted applications and smart clients. Let that not be the reason to prematurely invalidate SIP-SS7 interworking.

In conclusion, the need for SIP-SS7 is not an artificially created need due to the lack of understanding by the telecom industry of the SIP paradigm vis-à-vis the traditional telecom paradigm, but rather the opposite. Most telecom professional recognize that SIP offers the better service delivery platform and are eager to embrace it, but are faced with the challenge of how to make it more relevant to their existing business. SS7 to SIP interworking is a solution, at least in the view of some knowledgeable telecom professionals.

SIP is robust in the Internet environment.

SIP still works in predictable ways when packets are lost, when routes fail, and when endpoints fall off the network.

SIP achieves some of this robustness through a design principle to fail to a known-safe condition. The idea is that any change to the system has to be maintained through periodic refreshment. If the authority for a change isn’t available to maintain the change, then it’s not around to correct the change when new conditions cause it to be wrong.

For example, a presence user could post a presence document that says “I’m driving”. Somewhere along that drive, the user goes into a parking garage, losing connection to the network. The user leaves his car and makes it into a movie theater without reconnecting. In a less-robust system, that user’s presence will be wrong for the next hour or so. A SIP based presence system will notice, after some time, that the user is no longer maintaining the presence document and will fall back to a known safe default, probably “I don’t know anything about this user’s presence right now.”

This SIP-based presence user’s published presence is “soft-state”. It is information (state) the user put into the system that will go away if the user doesn’t maintain it. Stated another way, the information will expire unless it is refreshed.

By contrast, the position of a typical simple light-switch is “hard-state”. If you flip it up, it will stay up, possibly forever. It will only change back to down when you (or some other user) explicitly comes back to manipulate it.

The soft-state concept is reused in many parts of the SIP protocol. Registrations expire. Subscriptions expire. Presence documents (or any other published SIP Event documents) expire. The time it takes to expire is negotiated between the element providing the state, usually an endpoint, and the element keeping the state, such as a registrar or presence server. That negotiation goes like this:

Handset: “Would you please send requests for me to this Contact for the next hour?”

Registrar: “Yes, I’ll hold onto this Contact for you, but I’ll only keep it for 5 minutes.”

When making that request, the handset’s user is also saying “If something unexpected happens, I’m willing for the state I’ve handed you to be wrong for up to an hour”. The server is replying “I’m only willing to let things be wrong for 5 minutes”.

This points out why the Registrar above cannot say “Yes, I’ll hold onto this Contact for you, and to save you some trouble, I’ll keep it active for a month”. The handset user is only willing for things to be wrong for an hour. Half a month from now, that handset might not even exist.

Once soft-state is accepted, it must be refreshed or it will be deleted. That means that before the negotiated time passes, the element placing the state into the system must return and say “please hold onto this state a little longer”. In SIP, this refresh also re-negotiates the next expiration time.

In the figure below, Phil subscribes to Robert, asking for an hour. Robert grants the subscription, but limits the expiration of the subscription (the soft-state) to 5 minutes. Four minutes into the subscription, Phil refreshes it, asking for another hour, but again getting another 5 minutes. This time Phil doesn’t refresh the subscription, letting it expire. Note that the total subscription time was 9 minutes, not 10. Phil’s second 5 minutes started at the point of negotiation, not when the first 5 ran out.

As SIP networks mature (established public deployments are way beyond the one million subscriber mark), they begin to attract malicious attention as well. Reports on Edwin Pena [1], German “midnight attack” [2], and “Egyptian story” [3] make apparent that security, unlike in the early pioneering days of VoIP, is of paramount importance.

Of particular importance is confidentiality — the ability to make sure that no one other than the intended recipient can listen to your phone call over the Internet. Obviously, this is not trivial as the path between two parties is long, and there are many parties along the way — your network administrator, your ISP, your ISP’s upstream provider, backbone provider, anyone on the air (should you be using a wireless link), and possibly more. For many, concerns about unlawful use of legal interception facilities and industrial and political spying are also important. All of these potential interception points sit along the path of your voice packets. Confidentiality seems a battle of one against crowds.

Still, even when outnumbered, the privacy battle can be won using mathematics, if wrapped in carefully designed communication protocols.  Encryption techniques and protocols have been with us on the Internet for decades and make it very hard for privacy intruders to understand intercepted IP packets.

While the existence of an encrypted phone call remains apparent, the content is perfectly hidden.

In the rest of this post, I try to forecast which technology will prevail for securing the confidentiality of VoIP calls. I’m leaving the debate about appropriateness and downsides of hard-to-break to some other post. One of the reasons is simply that I believe that good privacy mechanisms are too disruptive to be stopped, whether they are used for just purposes or not.

IETF, the Internet standardization organization, has put enormous effort over the last decade into hard-to-break protocols for conveying encrypted traffic. Particularly, SRTP (RFC 3711) came out as a suitable protocol for transporting encrypted VoIP. While the capability to convey encrypted packets is necessary, it is not sufficient. Over time it became apparent that the yet-to-be-understood piece is actually “keying,” also known as key exchange or key agreement protocols. This is the mechanism in which two or more parties can agree on a “key” for encryption/decryption even in the presence of malicious parties. A variety of protocols have been debated over the years and abandoned mostly on the grounds of complexity, which is generally considered security’s and adoption’s enemy. Eventually two dueling protocols, ZRTP [4] and SRTP-DTLS [5], remained in the play.

The zRTP protocol was invented and advocated by Phil Zimmermann, famous for his brilliant PGP privacy software for email. SRTP-DTLS has been promoted by Eric Rescorla, known for his work on TLS. While both protocols have the potential for achieving confidentiality, zRTP seems a far simpler design and, therefore, a more likely winner.

zRTP uses Diffie-Hellman (DH) key exchange to create a key when a call is being set up. The DH-keying is multiplexed in the RTP stream. That in a nutshell is all it does; its beauty and power lies in its simplicity. As a result, it does not require any enhancements to the signaling infrastructure and bypasses problems that have been troubling SIP deployments since inception — NAT traversal, in particular. As it is rather straightforward, several implementations exist today that are publicly available for use, testing and expert audits.

The competing protocol, SRTP-DTLS, has chosen a more sophisticated approach for key exchange, which uses Public Key Infrastructure (PKI). It leans on SIP negotiation features and needs further security protocols such as SIP extensions for IDentity (RFC4474) and updated Identity (RFC 4916). These extensions have so far experienced very limited, if any, adoption, presumably because of their use of PKI and excessive message integrity protection [6]. The gain is these protocols (if used and deployed together) buy us a notion of identity. We not only know that we speak in privacy but also that a trusted provider vouches for the identity of the other party. Isn’t it comforting to know you are actually having a private conversation with a family member of yours?

While the notion of identity appears appealing, it is not clear yet if it provides any value. It requires additional security vehicles, which are not in place, and can therefore hinder deployment of the system as a whole. It still has its limits. For example it cannot reliably ensure that an office-mate won’t answer a phone call for your family member and impersonate her. In fact, the notion of identity on the Internet is still rather vague after all these years, and it will take a long time until we have a viable sort of “DNA match” for a VoIP call. In many real-world cases, use of common sense to identify a phone call peer seems “good enough”.

What remains though is the argument of complexity, which strongly speaks in favor of zRTP. We have learned in the past that simplicity is the winning ingredient. Simplicity keeps the number of boxes, configuration files, and other pieces to learn, buy and manage, at a minimum. At the same time, the low number of dependencies on other functions keeps the system simple and virtually resilient against failures, interop problems and security attacks.

Perhaps even more important from the adoption point of view is the number of parties that are needed to support the functionality. Keeping it as low as one is the key to success. You don’t have to run from one vendor to another, request commitments and roadmaps and pray they will be mutually in sync.

I personally believe that simplicity has been THE ingredient that allowed the Ethernet to win its race against Token-Ring, SMTP against X.400, and IP against ISO. Simplicity goes hand-in-hand with rapid adoption, public and proprietary implementations, field experience, public audits and subsequent improvements targeting real problems. My observation is that when simple technologies reach V2.0, their more complex (and possibly more “perfect”) counterparts still remain at stage 1.0, fighting for adoption.

In conclusion, I think that zRTP’s amazingly simple design (and simple by no way means simplistic!) will very quickly make it the confidentiality protocol of choice. Simplicity is just too appealing and disruptive to be ignored during new protocol adoption.

References:

[1] http://www.infoworld.com/d/networking/man-charged-selling-hacked-voip-services-800

[2] http://www.ipcom.at/fileadmin/public/2008-10-22_Analysis_of_a_VoIP_Attack.pdf

[3] http://www.sipsecurity.org/?page_id=151

[4] http://tools.ietf.org/html/draft-zimmermann-avt-zrtp

[5] http://tools.ietf.org/html/draft-ietf-sip-dtls-srtp-framework-07

In my previous post, I refuted the PKI criticisms against the SIP identity mechanism described in RFC 4474. This week, I will describe a real issue.

One very real issue is the venerable phone number. Much of the industry has forgotten that SIP is not about phone numbers. The SIP URI takes a form more like an email address. It has one critical component that phone numbers do not have–that is, the authority. My email address (ben.campbell@tekelec.com) tells you two things. The obvious is that my email user name is “ben.campbell”. But more importantly, it tells you that “tekelec.com” is the only legitimate authority on what the “ben.campbell” part means. There might be a “ben.campbell” at some other domain. That person is probably not me.

The same is true of SIP URIs. Imagine the URI of “sip:foo@bar.baz”. Only the domain of “bar.baz” knows what “foo” means. Furthermore, using RFC 4474, only “bar.baz” can authoritatively tell you that a SIP INVITE request really came from “sip:foo@bar.baz”. More concretely, RFC 4474 requires an entity owning a certificate bound to “bar.baz” to digitally sign a hash across several important bits of the INVITE request.

So let’s look at another example. Imagine you receive an INVITE from “tel:+1234567890″. Who is the authority now? RFC 4474 doesn’t handle this scenario. From a SIP purist perspective, this is a corner case. (Remember, SIP is not about phone numbers.) But from a real deployment perspective, phone numbers are the rule, not the exception.

One way around this is to have the calling domain use a SIP URI of the form “sip:+1234567890@bar.baz; user=phone” rather than using a “tel:” URL.  Now we’ve got a bona fide authority that can sign things. But what does that signature mean? In the “sip:foo@bar.baz” case, the authority is saying something to the effect of “I promise on my reputation that foo is calling you. If you trust me, you can be sure of it.”

But the most common scenario where you get a SIP INVITE from a phone number is when the call originated on the PSTN and crossed a PSTN-to-SIP gateway. In this case, an RFC 4474 signature would mean something more like “I received a PSTN call with a calling party ID of +1234567890. It’s probably legit, but you’ve heard about all those Caller ID spoofing attacks, right?”

There’s been a lot of discussion about this issue in the Real-time Application and Infrastructure area of the IETF. I believe this can be solved pretty easily–we just have to agree on how. The issue is pretty esoteric–and considering that one of the major applications of SIP Identity is to provide the VoIP equivalent of caller-id, we can probably live with it in the short run. Hopefully we can do better in the long run.

Next up from me: The Identity vs SBC Smack down.