January 09, 2004

Legal Intercept and VoIP: Impact on the Architecture

news.com has posted a story saying that Feds seek wiretap access to VoIP. It is not clear why they decided to publish the story today, even though Department of Justice, DEA and FBI submitted their comments to the FCC VoIP Forum on December 15th and has been available on FCC’s website since then.

We still do not know what will be FCC’s position on this matter. Early indications seems to be that the classification of VoIP will be a function of whether there is interworking with PSTN is involved or not. Legal intercept requirement will necessitate change in the network architecture. There are two components to legal intercept requirement: the first is delivery of signaling information and the other is delivery of call (media) information. Since the service provider is necessarily in the signaling path, it is easy to meet the first requirement.

To meet the second requirement, the service provider must be able to redirect a copy of the RTP packets to the monitoring agency. Since normally, the media stream does not pass through a network node, the end-points must be instructed to route RTP packets through a designated node. But there is a catch. The subject should not be able to discern that the monitoring is on. This means that all calls must be routed through a network node. This could be handled by what are called Session Border Controllers. Deploying SBCs is not a simple matter. The service provider needs to engineer the number of SBCs and must have sufficient network capacity to route the traffic.

Posted by aswath at January 9, 2004 10:54 AM
Related Posts Widget for Blogs by LinkWithin
If you do not have an OpenID, then please use www.enthinnai.com/unauopenid/anyblog.

 

Comments

And of course the other issue is those running their own SIP proxies, running their own SIP domain (or sub-domain) and that could (in the not too distant future) include residential end-users. Think it's that far fetched? Who thought we'd be running our own PIX boxes? Or remember when phones used to say "Property of Western Electric" on them?

Posted by: David Beckemeyer at January 10, 2004 02:18 AM

I agree with you that the capability of hosting ones own SIP service will be commonplace. I am hoping that soon I can make much stronger staement than that :-). So LEAs need a monitoring capability like Carnivore as you mention in your blog.

So let us take the Carnivore scenario. It is collecting the full data. But when a court authorizes legal intercept there are all kinds of
restrictions; one of them is LEA can access only certain data. If they have call control information from the SP, then they can focus on the relevant data.

I suppose one can argue that why place this burden on the SP. I submit that we place additional responsibility on public carriers, be they communication oriented or transport or utility etc.

Posted by: Aswath at January 10, 2004 09:01 AM

Hmmm. I'm quite interested the 'strong statement'.

In terms of a Carnivore-like capability for SIP, I think ultimately it will be the way things go, and it will be able to do more than SIP. There's still an issues if end-to-end encryption becomes general.

Rumors say the feds have managed to get back doors put into a lot of vendors products to address this, but that's a challenge for them to keep up with. Other rumors suggest every SSL type encryption scheme in use has already been cracked and that's why you don't hear much complaining about encryption from lae enforcement anymore.

One issue with application level gateways (ALGs) or SBCs, is that they fundamentally break a major benefit of SIP, that of separation of session establishment from session description. A SIP proxy isn;t supposed to know or care what the end-points are going to do, or how they're going to talk to each other. That's between the end-points. When a nifty new thing comes out, SIP proxies don't have to be updated to accommodate or support it. But a ALG that is handling media won't understand the nifty new thing unless it is upgraded or recoded.

Posted by: David Beckemeyer at January 12, 2004 12:57 PM



Copyright © 2003-2014 Moca Educational Products.