voip calea interfaces

Tue Jun 20 17:33:41 UTC 2006

I'm willing to reply on-list, but obviously any business or legal  
contacts have to be off-list. For those, I can point you to the  
product manager for the technology, but it would frankly be better  
for one to go through one's account team, for scaling reasons.

Yes, the vendors are aware of this. Our legal people track it pretty  
closely, and we have been dealing with the issues in Europe,  
Australia, and a number of other places for quite a while. We talk  
directly with legislators, regulators, and various police entities.  
Before you ask whether we speak with China, I'll point out that we  
deliver a common technology that people using it configure to the  
applicable laws and warrants, and the laws we looked at in designing  
it were the laws and regulations of the various countries that signed  
the CyberCrime treaty. We designed it the way we did to meet the laws  
and regulations of western democracies like the US and EU.

RFC 2804 requested that anyone that designed a Lawful Intercept  
technology please publish it so that it could have open review. We  
did so:

http://www.ietf.org/rfc/rfc3924.txt
3924 Cisco Architecture for Lawful Intercept in IP Networks. F. Baker,
      B. Foster, C. Sharp. October 2004. (Format: TXT=40826 bytes)  
(Status:
      INFORMATIONAL)

This has also been submitted to ETSI, as an alternative to the model  
initially proposed there, which was "why don't we just split every  
fiber and run one instance under the appropriate agency's door?". I  
am not personally involved in that effort, but someone from my  
company is and I understand that ETSI is considering the model.

What this describes is the interface from a router or switch, or from  
a control application like a SIP proxy, to a third party mediation  
device. The interface from the mediation device to the law  
enforcement agency is different, and differs by country. The  
fundamental principle that we are trying to design to is "give the  
LEA what the warrant says they should get, no more and no less"; in  
some cases, that means that the mediation device will get a superset  
of the warranted data and have to edit it appropriately. There are  
various technologies for lawful intercept that exist that require a  
site visit to the POP to respond to the warrant or deployment of a  
stack of equipment in each POP in case an LEA ever asks; we try to  
make this a feature of the router or switch that can be configured  
the same way anything else is, but the information regarding the  
intercept kept appropriately private.

You might also take a look at http://www.cisco.com/pcgi-bin/search/ 
search.pl?searchPhrase=lawful+intercept

On Jun 20, 2006, at 9:48 AM, Eric A. Hall wrote:
> I'm looking into the FCC ruling to require CALEA support for  
> certain classes of VoIP providers, as upheld by the DC circuit  
> court a couple of weeks ago [1]. The portion of VoIP that is  
> covered by this order is pretty narrow (ie, you provide telephony- 
> like voip services for $$ [read the specs for the real  
> definition]), and the FCC is looking at narrowing it down further  
> but has not done so yet. Meanwhile, the deadline for implementation  
> -- May 14, 2007 -- is starting to get pretty close.
>
> The operational part of this subject, and the reason for this mail,  
> is the implementation of the wiretap interface. Obviously there are  
> going to be a range of implementation approaches, given that there  
> are a wide variety of providers. I mean, big-switch users probably  
> just enable a feature, but small providers that rely on IP PBX gear  
> with FXO cards will have to do something specific. Are vendors  
> stepping up to the plate? Did you even know about this?
>
> Off-list is fine, and I'll summarize if there's interest.
>
> Thanks
>
> [1] http://pacer.cadc.uscourts.gov/docs/common/opinions/ 
> 200606/05-1404a.pdf
>
> -- 
> Eric A. Hall                                        http:// 
> www.ehsco.com/
> Internet Core Protocols          http://www.oreilly.com/catalog/ 
> coreprot/