Recently BICC became the protocol of choice for several wireless operators deploying VoIP trunking backbones. For many it is perceived as a temporary workaround solution.

What I’m asking myself is whether such a temporary solution might possibly stay for longer?

In the IP world we have quite a few examples of “temporary solutions” that have featured momentary advantage, real or perceived, and which have stayed with us. I consider NATs (Network Address Translators) the most important example. NATs translate IP addresses in packets from/to the public Internet to a private address range. This allows for the sharing of a scarce public IP address among multiple devices (real problem) and hiding these devices better. The latter is considered a perceived security feature as the same functionality can be implemented in firewalls without the side effect of changing IP packets. The changes to IP packets can cause dysfunctional applications, errors in security protocols and limitations to redundancy schemes. (See RFC3027 for more).

In the IETF standardization body NATs have therefore been considered as architecturally unsound, or even evil architecture. It shall be added that guarding an “architectural spirit” has allowed Internet technology to develop, stay manageable and prevail. In this spirit the “right answer” to the problem of scarce IP addresses has been proposed: IPv6. NATs have been labeled as a “temporary solution”. However, many years later it is as hard to find a user without NATs as it is a user with IPv6. NATs are to stay and the fate of IPv6 is all but clear.

I think a similar scenario is occurring with Session Border Controllers (SBCs). They solve real problems such as NAT difficulties that have bubbled up to the application layer. They solve temporary problems such as interoperability of immature implementations. They also solve perceived problems — we know yet too little about what security problems are out there but SBCs offer an answer already. However, the coincidence of solving real problems and claims they are of a temporary nature seems to me remarkably similar to NATs. I think this may lead to a similar ending, with SBCs staying and solving the problems that are compelling and permanent. Certainly, re-connecting disjoint IP addressing spaces would be one of those.

What is the next controversial architecture to stay? NATs are definitely staying, SBCs keep “temporarily” reconnecting disjoint address spaces. The capability to solve compelling problems has prevailed over desires for a consistent and presumably easier-to-maintain architecture. Recently, several BICC deployments have emerged — is BICC going to be the next protocol that is “architecturally unsound”, yet here to stay?

The BICC architecture is very special-purposed and therefore of limited applicability. Basically, it inherits encoding from ISUP, and transports it over IP or even ATM. Development beyond the purpose of trunking began stalling at “CS3″ (Capability Set 3). By any measure it is a real hybrid vehicle.

Still, as unappealing as it sounds, deployments are reported and continue to solve the MSC trunking scenario. We can soon witness again an architecture solving a real problem and prevailing over “grand architectures” in specific use cases.

It appears that the notion of hybrid vehicles is not exclusively owned by the automotive industry.

Happy New Years!

My last SIP Sessions post discussed the SDP offer/answer extensions used by MSRP in the peer-to-peer scenario. Today, we will look at how this changes when you introduce MSRP Relays into the mix.

RFC 4976 defines the MSRP relay extension. There’s quite a bit to talk about with MSRP Relays. Today we’re going to focus just on the parts that impact the offer/answer process. I’ll cover more about relays in a future post.

An MSRP client that needs to use an MSRP relay must first authenticate to the relay and request an MSRP URI that represents the session at that relay. It does this using an MSRP extension method called “AUTH”. We will dive into the gory details of AUTH after we discuss the general MSRP transaction model–also in future posts (Are you starting to see the pattern here?). But we need to understand it conceptually in order to explore how relays affect the offer/answer model.

The client sends the AUTH request to the relay over a TLS connection. The relay authenticates the client using a form of digest authentication much like that from HTTP and SIP. The client uses the TLS association to authenticate the relay.

Once the authentication completes the relay generates an MSRP URI that resolves to the relay itself. The relay puts this URI in a “Use-Path” header field in the 200 OK response that it sends back to the client in response to the AUTH request. The client then uses the relay’s URI in the session negotiation.

This is conceptually similar to how some other relay-based NAT traversal mechanisms work. For example. SOCKS and TURN each allow a client to request a relay device allocate a port on its behalf.

Once the client gets a “Use-Path” header value from the relay, it can then build the SDP path attribute by appending its local URI to the relay URI. For example, assume the client’s URI is “msrps://client.example.com:2855/asfd34;tcp” and the relay returned a Use-Path value of “msrps://relay.example.com:7212/d3asdf43;tcp” The path attribute would now look like the following: 

a=path:msrps://relay.example.com:7212/d3asdf43;tcp msrps://client.example.com:2855/asfd34;tcp

You’re probably wondering why “Use-Path” is not called “Use-URI”. The reason for this is, just like the SDP path attribute, “Use-Path” can contain more than one URI. There are few cases where a relay might need to return more than one URI. (You guessed it–we’ll talk about those in a future post.) But regardless of why it might happen, the relay-using client would build the SDP path header by taking the entire contents of “Use-Path”, reversing it, then adding its own URI to the end. Thus, the SDP path attribute becomes an assertion to “to get to me, follow this path from left to right. My local URI is on the end.”

Let’s look at a more complete example from RFC 4976. Alice invites Bob to an MSRP session. Alice does not use a relay, but Bob does. Alice’s offer looks something like the following:

v=0

o=alice 2890844526 2890844526 IN IP4 alice.example.com

s= 

c=IN IP4 alice.example.com

t=0 0
m=message 7654 TLS/TCP/MSRP *
a=accept-types:text/plain
a=path:msrps://alice.example.com:7654/asfd34;tcp

When Bob sees the offer, he connects to his relay (relay.example.net), and performs an AUTH transaction. He gets back a 200 OK response containing, among other things, the following:

 Use-Path: msrps://relay.example.net:8211/asfioef;tcp

Bob’s SDP answer then looks something like this:

v=0

o=bob 2890844542 2890844542 IN IP4 bob.example.net

s= 

c=IN IP4 bob.example.net

t=0 0
m=message 6581 TLS/TCP/MSRP *
a=accept-types:text/plain
a=path:msrps://relay.example.net:8211/asfioef;tcp msrps://bob.example.net:6581/asfd34;tcp

Note that in this case, Alice’s client does not have to implement RFC 4976 at all. It won’t know how to use the AUTH method, but even basic RFC 4975 clients can still talk to relay-using peers.

That’s enough for now. Next time, we will talk about how these SDP path attributes get used inside MSRP proper.

This post continues the
series on SIP-I and SIP-T deployment challenges. You may wish to read
the Introduction to SIP-I and SIP-T post for some general background on these two
protocols before continuing.

One of the most powerful
features built into the core of the SIP protocol is called “forking.” Forking
allows any SIP proxy to send an inbound request – such as an INVITE request –
to more than one destination. It can send these multiple requests either all at
once, sequentially, in groups, or use any arbitrary combination of those options.

This feature allows the
implementation of services such as “find me, follow me,” parallel ringing,
delivery of instant messages to multiple devices, and several other interesting
capabilities.

When SIP forking occurs
during session establishment, the INVITE messages involved in setting up the
call actually travel all the way to the called party’s devices, and establish a
protocol relationship directly between the calling device and the called
devices.

The reason this was built
into the core of the SIP protocol is that, unlike many other technologies used for
real-time communication, SIP inherently supports the concept of having a single
user potentially available via several devices simultaneously. Callers are
generally interested in contacting a user, not a device – so, to support
mapping from one user to several devices, we decided to inherently provide functionality
for contacting several devices.

While it is immensely
useful, SIP forking has proven to be one of the most difficult challenges we
face when developing SIP protocol extensions in general. SIP-I and SIP-T are no
exception: forking causes problems for both signaling and for audio.

The signaling problem
arises from the fact that ISUP and BICC have no inherent protocol behavior that
is analogous to SIP forking. Implementation of parallel ringing services in an
ISUP network requires termination of the call at an application server, which
re-initiates the call towards the various target devices. So, for example, if a
parallel ringing call alerts three devices, there are four ISUP calls involved:
one from the caller to the application server, and one from the application
server to each of the three devices. There is no direct relationship, from an
ISUP perspective, between the caller and the devices.

Consider the case in which
a SIP-I or SIP-T call arrives at an ingress gateway, and is forked by a
SIP proxy to two different egress gateways. The messaging looks something like
this (I’ve omitted PRACK transactions for the sake of clarity):

The INVITE messages sent
to the two egress gateways will contain the IAM message that started the call, which
is sent to both of the called end offices. (Note that the egress gateways will
adjust the called party number in the IAM according to the SIP URI in the
INVITE, so it will end up indicating the two different devices the call is
being sent to).

Assuming that both of the
called devices are available, both egress gateways will receive ACM messages from the called end offices,
which get mapped into SIP “180 Ringing” messages. Both of these messages arrive
at the ingress gateway. The first one that arrives – message 5 in the above diagram
– will have its ACM extracted by the ingress gateway, and sent back towards the
calling party. However, the gateway must be careful not to send the second ACM
(from message 7) into the ISUP network: doing so would be a protocol error,
which would cause the calling end office to tear down the call.

Depending on how much ISUP
signaling occurs prior to the called party answering, there may be several
tunneled ISUP messages that arrive at the ingress gateway while the SIP forking
is still active. The ingress gateway is responsible for taking the two
different streams of ISUP messages and converting them into a coherent set of
messages for the calling party’s end office. This can be tricky to get right,
and any errors will cause the call to fail.

The media-related issue
with forking arises from the difference between when SIP expects media to start
flowing and when ISUP expects media to start flowing (see my
earlier entry about early media for a summary of the general issue).
Forking makes this problem much more difficult, since there can be more than
one media stream present. If both media streams are simply ringback, it doesn’t
typically make much difference which one the ingress gateway plays. But there’s
no way for the ingress gateway to know ahead of time what might arrive in the
media – it could contain ringback, an announcement, or even playout of an IVR
menu.

To further complicate
matters: if the gateway elects to play the media stream from one gateway, but
the call is answered by another gateway, the called party’s media won’t be
played out immediately. This will clip off the beginning of whatever the called
party says upon answering the phone. Even worse, it isn’t always possible to
tell which media stream belongs to which call, which means the gateway might
have to wait for the “incorrect” media stream to completely stop before it can
switch over to the proper stream. Since the only way to detect the end of an
RTP stream is via timeout, it may be a full second or longer between the called
party answering and the media being established.

Unfortunately, neither
SIP-I nor SIP-T provides guidance for handling the issues that arise from
forking. Implementations are left to handle the problems how they best see fit.
And, in many cases, there aren’t any good answers.

Stealing the identity of another user allows the attacker to use some service with the costs getting charged to someone else. However, the attacker would be limited to the privileges of the stolen identity and all calls conducted by the attacker would have the user’s identity as the originator or recipient. Fraudsters would, however, in general like to conduct fraud on a larger scale, e.g., by selling stolen services to other people and, hence, gaining from the fraud not only free calls but also monetarily. This can be achieved by getting access to the infrastructure components of the SIP service, e.g., SIP proxies, databases or gateways to the PSTN. With such access, the attacker can manipulate the authentication process so that his calls are not authenticated or are considered as legitimate or can simply ensure that no billing records are generated for his calls.

Recently, there have been two patterns for conducting this kind of fraud, namely password guessing and credential emulation.

Password Guessing

SIP components usually have an administration interface that allows the administrator to configure the system, control the privileges of different users and actions and set the logging and billing criteria. This interface is usually protected through a password. Often, all devices manufactured by the same company share the same password. Administrators often forget to change this password during the installation process at the provider’s premises. By knowing this default password, an attacker can assume the identity of the administrator, which would allow him to receive the needed privileges for misusing the service. Such fraud can be prevented by changing the password of the SIP components and protecting the administration interface so that it is only accessible over a trusted network link.

Credential Emulation

A popular setup for VoIP services is presented in the figure below. In this setup the proxy is responsible for authenticating the incoming requests and forwarding legitimate requests to the PSTN gateway. To indicate to the gateway that a request is legitimate, the proxy adds special information in the forwarded requests. This information is then used by the gateway as an indication of the legitimacy of the request and would, hence, only initiate calls to the PSTN if a request included this information. A fraudster can detect this information either by guessing or by brute force. By including this information in his own requests, a fraudster can fool a gateway into believing that his requests are legitimate. By running his own proxy server and adding this information to the requests of his customers, the fraudster would receive access to the PSTN without having to pay for it.

In general, this kind of attack is more complex. The fraudster needs to detect gateways that accept SIP signaling requests directly from the Internet and use this kind of authentication approach. Further, to cover their traces, fraudsters need to first gain access to a VoIP server of an enterprise or university with wideband Internet access and then route the calls through these servers.

To protect against such fraud, the communication between the proxy and the gateway must be secured. This can be achieved by having the gateway all SIP requests arriving from any other IP address than that of a set of trusted proxies. This could, however, be circumvented by having the fraudster spoof the IP addresses of his requests. Higher security can be achieved by establishing a secure tunnel, e.g., using IPSec or TLS, between the proxy and gateway and rejecting all SIP traffic not arriving over this secured link.

Over the last several years, I’ve had many conversations about building a certification program for SIP, including trying to define a few. All of those conversations have ended either in frustration or the conclusion that such a certification program is not the right thing to build.

The proponents of such a program came in each time with a lot of energy and excitement. The conversations got tough when we looked closely at what the program would actually certify. What do you test? What do you require a passing system to do? Each time, it turned out that the proponents really had a single, focused use of SIP in mind (usually simple telephony replacement). The motivation statements tended to look like “I want to buy a phone from and have it work with my service”. The participants quickly became mired in arguments about what the tests to ensure that should cover. They discovered that they really wanted to test for a lot of end-user visible behavior that the SIP specification itself leaves undefined.

As we tried to work further through the details, we’d frequently see arguments to profile the protocol. In very early conversations, there was pressure to not require (or even penalize) the implementation of SIP over TCP or the use of the 100rel/PRACK extension, usually driven with a “nobody really does that” argument. It’s worth noting that both of those are required in many deployments today. The folks focusing on simple telephony didn’t want to be burdened with testing the parts of the protocol needed for presence and vice-versa. The business telephony oriented people had an entirely different idea of what a program should look like than the single-line replacement oriented folks.

In short, what people really wanted was a certification program for their particular application, not for the protocol itself. Unfortunately, at the time, I don’t think anyone involved realized that was the root of why such programs weren’t coming together.

With that realization, I’ve become even more convinced that a generic SIP certification program isn’t feasible – it wouldn’t produce a useful tool for making our ecosystem(s) better. The energy would be better focused on how the protocol is used rather than trying to certify implementation of the protocol itself.

There are a few new programs under discussion now, in the SIP Forum and other organizations, which are trying the approach of defining certification programs for an application. Those conversations seem to be going further than the earlier attempts, and I think some of them have a chance of succeeding.