Law enforcement: you can’t always have what you want

This article on how the FBI is seeking expanded surveillance powers for “cloud”-hosted Internet communication services reiterates the frustration of law enforcement agencies feel at the way technological evolution has caused many interception capabilities hitherto taken for granted to slip from their grasp.

First, let’s get something out of the way: people who are at least somewhat technologically aware understand and take for granted that security services and intelligence agencies have the means to intercept almost anything you do on the Internet–at least, if your means of doing it are even remotely conventional. I assume this is not a novel thesis to most readers. The difference is that this type of interception activity is rarely subject to the same kind of restrictions as evidence-gathering operations whose product must be admissible in court. So, we’re not talking about interception here per se; we’re talking about lawful interception”.

Essentially, what the police are mad about is that CALEA, the last big legislative initiative, passed in 1994 to force technical cooperation from service providers and provide standardised data interfaces for streamlined tapping, simply doesn’t keep pace with modernity in the way they would like. It originally applied only to phone companies. It has been expanded to VoIP providers and ISPs, of course, but it’s still a mechanism that was fundamentally designed with a view to the state of the telecommunications world in the early nineties. CALEA proceeds from a PSTN-oriented view of communications networks, which is one in which they are hierarchical, highly centralised, despotically controlled by a very limited cadre of individuals and entities, and meticulously standardised.

That paradigm doesn’t begin to cover all the diffuse packet-switched, federated, multi-jurisdictional, and above all, increasingly distributed and peer-to-peer communication transports that the world has diverged into since then.  Essentially, they’re upset that there’s no conveyor belt on which your Gtalk (XMPP) messages or your World of Warcraft voice-over conversations can be fed straight into a large-scale FBI tap, in real time, on demand.

Worse yet, this multi-protocol, multi-service, multi-topology landscape is only getting more complex and diverse, not less.  Fifteen years ago, how many different ways did you have to communicate person-to-person online? AIM, ICQ, e-mail? I could list dozens of mainstream methods now, and the list is only growing.

Of course, the technically minded among us have done these agencies a huge favour by opting for the convenience of “cloud”-hosted e-mail (Gmail), documents (Google Docs, Dropbox, etc.), messaging (Gtalk, Facebook Messenger, etc.). Those of us who have the knowledge and capability to run our own IM and e-mail servers, as we used to have to do, are, in my opinion, quite irresponsible for opting not to do so in the name of economics. However, this was never even a point of discussion for most people; most ordinary Internet users have always been stuck with whatever services some large company (AOL, Mirabilis, Google, Facebook, Twitter) fed them.

Certainly, the police and the FBI can–and do–subpoena your data from these companies. Their complaint here is really that the process is not streamlined or real-time. It’s not enough that they can, in principle, get at the data.  They want to get at it quicker, better, faster. In other words, they want to reap some of the same efficiency increases that you’re reaping. Why should you get to send encrypted IMs through dozens of services straight from a burner phone with a 3G data plan, while they have to chase their tail and jump through antiquated, time-consuming legal hoops to try to piece some of what you’ve just done together?

The only effective strategy for bolstering public support for increased surveillance ventures is through scare-mongering, invoking the usual bogeymen of terrorism, identify theft–pick your fashion of the hour.  Law enforcement asks you the rhetorical question: Do we really want IT to provide an unprecedentedly untraceable and profoundly effective mechanism for the next 9/11 hijackers to collaborate?

My view: yes, we do.

They government just needs to get over it. The march of technological progress often brings unpleasant realities for certain institutions. A significant and growing portion of the population of the developed world has an Internet-connected 1+ GHz multi-core computer in their left pocket. That’s going to put unprecedentedly powerful encryption and encapsulation capabilities in the hands of everyday people–capabilities that have increased by several orders of magnitude in just two or three decades.

For the most part, this is all good news for information privacy, civil rights, freedom of expression, and financial data protection. I am convinced that the net social benefit of being able to send information in ways that are not trivially interceptible greatly outweighs the downside of criminals also doing so.  On the whole, I feel much better about having a conversation with a friend now about politics, confidential family problems, and sensitive financial details than I did ten or fifteen years ago.

From a technical point of view, I don’t see a realistic way for government agencies to keep up with the magnitudinal increases in communication complexity.  It is starkly at odds with the way the distributed way the Internet and its constituent layers of abstraction are organised–even if it is more centralised at the physical layer than most of us think or would like to admit. Yes, I’ve heard of the Bluffdale Data Centre, but I cannot imagine how one would need to reorganise the Internet, topologically, or what kind of tentacular monstrosity one would need to build, in order to have a reasonable chance of actually tapping all of its communications.  The biggest obstacles are not physical, but rather the sheer diversity of protocols and applications that would need to be understood by The Behemoth in order to make this process anything like scalable, which is the real problem for law enforcement.  The resources already exist to spin their wheels on wiretapping someone as an expensive one-off.  As I mentioned above, what the government wants is something closer to the economies of scale that have been reaped everywhere else.  It stands to reason that in their ideal world, they’d want to force everyone to take their data, in all its heterogenous patchwork, and massage it into a standard format and spoon-feed it to them.  They want wiretapping to be easier, and are upset that instead, it’s gotten harder.

In an adversarial court system with a judicial presumption of innocence, they want you to make their job easier.

I don’t any reason why it would be socially desirable to allow law enforcement to try to move this immovable object.  I can’t see what good results can come from it, even if we completely sidestep the issue of massive abuses of law enforcement power and grant that there is a morally legitimate application of wiretapping by state agencies in at least some cases.

It seems to me that the greatest danger in all this is not that money launderers might use Tor to plot and scheme or that professional clubgoers might buy ecstasy on Silk Road, but rather the drag that costly bureaucratic boondoggles impose on economies and livelihoods. Anyone aware of the true state of CALEA compliance in the VoIP industry–or, to be precise, the elaborate motions of compliance–knows that there is no hope of achieving full compliance with such initiatives, and no hope that they will, in the grand scheme, achieve their ostensible goals.

Impossible boondoggles not only cost money, but have the effect of turning everyone into criminals or civil defendants, since nobody is actually in compliance. And, as usual, small companies suffer the most, since they don’t have the resources of large companies to put on elaborate charades of complying with Byzantine requirements. And, as usual, the big companies buy their way out, while the small companies are shaken down in the great cosmic lottery of selective enforcement.  It all starts to be reminiscent of the cynical “we pretend to work and they pretend to pay us” mantra in my native USSR. 

As progress moves forward, some institutions adapt, but some certain legal and civil artifacts of previous historical frames fall away. Sometimes they just have to. Maybe you can’t trivially tap one or two ubiquitous methods of communication anymore, but so what? You can’t own slaves or torture people anymore, either.

From our friends in North Carolina

Ringfree Communications, a leading VoIP operator and provider of hosted PBX and SIP trunking services in the Asheville, NC area, sent me this inspiring homage.


Kamailio as an SBC (Session Border Controller)

One of the most common enquiries we get is about using Kamailio as an SBC.  I don’t think it’s an exaggeration to say it’s our top FAQ, as a consulting organisation.

“SBC” is a term that has a lot of different meanings to different people in different contexts.  To answer this question, you need to:

  • Develop a proper understanding of “SBC”.
  • Determine whether you actually need an SBC, enlightened by a correct understanding of the concept.
  • Evaluate the extent to which Kamailio can play this role.

I think it’s safe to say, from my observations, that there are two primary understandings of the concept of an SBC: a pedestrian understanding, and a professional one, as used in an intra-industrial/domain-specific context.

  • Pedestrian definition: some kind of network edge proxy, administrative border and/or call transit element at the edge of a voice network, designed to face carriers and/or peer networks.  It is expected to provide routing functionality and some security and rate-limiting type capabilities, to shield the internal network elements from DDoS attacks and so on.

When most people come along and ask me, “Can you deploy Kamailio for us as an SBC?”, they are proceeding from the pedestrian definition, and haven’t had to look at the terminology critically.  It often turns out that they are just looking for an aggregation point to condense their variable IP endpoints to a single signaling endpoint, in order to interface with a carrier.  Many other customers are looking for LCR (least cost routing) gateway functionality, or some other type of internetwork routing intelligence.  They, too, some reason choose to put the “SBC” label on it, because that’s what industry marketing has taught them to do for anything that sits at the network edge.

That’s not what an SBC is, at least, not to professional VoIP topology architects and network implementors.

  • Professional definition: an appliance with a SIP B2BUA (back-to-back user agent) core, usually able to do some combination of policy-based access control, transcoding, topology concealment, call accounting (usually via RADIUS), QoS and call quality statistics, etc.

The most exhaustive list of SBC capabilities I’ve seen lately was compiled by Mark R. Lindsey in this post on the VoiceOps list, which I will quote here (with his prior permission):

  • Ability to gracefully single-source and distributed handle attacks from the Internet
  • Traffic from numerous VRFs (so that customer A’s is not the same as customer B’s
  • Hosted NAT Traversal
  • Transcoding media
  • Lawful Intercept hooks
  • Demultiplexed SIP trunks (so that each SIP “path” can come from a different IP address or port)
  • Constraints like Calls-per-second or Concurrent-calls (so legitimate customers don’t cause a failure)
  • Failover from one SBC to another
  • Distributed SBC models where one box handles signaling and many more handle media
  • 802.1q VLAN tagging support
  • Support for failover to BroadWorks-style registrar redundancy (where the mated registrar servers have distinct IP addresses)
  • SNMP management
  • Interworking SIP/UDP and SIP/TCP
  • Jumbo SIP (SIP datagrams over 1300 bytes, out of compliance with RFC 3261)
  • SIP/TLS and SRTP, and decryption thereof
  • Configurable media management (to release media when possible, steer it through the SBC when not)

Higher-end SBCs usually also incorporate at least for ASIC (application-specific integrated circuit)-assisted RTP relay and transcoding, in order to achieve higher port densities.

This is the sort of thing I, and others in my profession, hear when customers say “SBC”.  In most cases, that’s probably not what they mean, but it’s what we hear.  When I tell people all this, they usually say, “no, no, I don’t need all that”.  If you don’t need the bulk of the aforementioned capabilities, you don’t need an SBC, and you shouldn’t call it that.  Perhaps this meta draft can help with the classification of the network element itself.

Kamailio fails out of the gate on the B2BUA aspect, which seems to be a requirement of the SBC concept.  A B2BUA accepts one logical call leg A, and creates another, logically unrelated call leg B, and bridges signaling events between them in as transparent or opaque a manner as it desires.  A proxy receives logical call leg A, and pushes call leg A right back out, and by and large, that’s what proxies do–they proxy; garbage in, garbage out.

There are relatively few things that a proxy can modify in a SIP request or reply, formally speaking.  It can modify the Request URI and a few other message fields, and it can attach custom headers.  However, critically, it cannot rewrite or fundamentally regenerate the request or reply, as a B2BUA might.  This makes it a rather poor mediator for interoperability issues and security purposes–a key selling point of SBCs.

Kamailio has some hacks that allow it to go a bit beyond these limitations, in defiance of its standards-prescribed role as a proxy element, such as the UAC module’s ability to statefully rewrite the From and To header, and the topology hiding module‘s stateful encryption of topology-revealing details in Record-Route header parameters. However, these should be understood for what they are: hacks with limitations–limitations that a B2BUA does not have.

Kamailio can use rtpproxy to relay RTP on commodity hardware, which is mostly done for far-end NAT traversal (which Kamailio supports through the nathelper module) and topology concealment reasons (combined with topoh). This horizontally scales rather well, but is not exactly like the port-dense ASIC-driven RTP forwarding setup of a commercial SBC.  Also, there is no transcoding capability in rtpproxy.

With some effort, Kamailio can be set up to bridge signaling between multiple network interfaces, and rtpproxy can operate in a “bridging mode” which allows it do to the same.  However, implementing this is challenging, and does not provide the multi-realm flexibility of an SBC; it is, by its nature, a hard-coded setup, and if you’re expecting to maintain “realms” in half a dozen subnets, as with an SBC, you’re setting yourself up for a world of pain.  It is technically possible, but just because some things can be done does not mean they should, methodologically speaking, be done.

Kamailio can relay REGISTER messages upstream, and supports the Path extension.  Whether the upstream registrar supports it is another question; many do not.  It is possible to do some clever hacking involving encoding of the original Contact URI received from the registrant into the Contact header, but this is a dirty hack, not a true registrar front-end.

In sum, it is possible to deploy Kamailio in select subsets of an SBC role, but the probability is quite high that “SBC” is not really what is meant when the term is used.  Things I’ve seen classified as SBCs in the context of Kamailio project requisitions include:

  • Far-end NAT traversal gateways.
  • Load balancers.
  • Registrars.
  • Proxy-based security elements.
  • Traffic aggregation proxies.
  • Intelligent routing gateways for voice application silos.
  • Least Cost Routing gateways.
  • Class 4 carrier trunking interfaces.

None of these things, in and of themselves, an SBC make. In fact, most of these things are functions that an SBC would not directly perform, though it is likely to front-end network elements that do perform them.

On the other hand, trying to front-end a classic Class 5 type SIP subscriber softswitch, such as a Metaswitch or a Broadsoft assembly, ought to be classified as an anti-pattern. While it is possible, in principle, cajole a reluctant proxy into a mostly-functional role doing that, it is the wrong tool for the job, it will create as many management problems as the technical objectives it crudely achieves.  There are lots of threads on sr-users from hapless souls who got stuck in the quagmire of multiple Record-Route headers corresponding to different forwarding network interfaces, and conditional rewriting of SDP based on the originating and terminating subnet, and keeping it all straight by encoding it in some sort of dialog-persistent parameters.  From a best-practical point of view, you really don’t want to go there.

Bottom line: Kamailio is not an SBC.  Not at all.  It’s a proxy with some SIP server features inside. However, depending on what you’re actually looking for and whether you’re using the term correctly, that may not be a problem.