[VOIPSEC] CALEA Enforcement

Wed May 10 20:39:21 CDT 2006

The recent FCC notice excludes non facilities based VoIP providers (Skype).

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On Behalf Of
> Gupta, Sachin
> Sent: Tuesday, May 09, 2006 8:48 AM
> To: Olivier GRALL; Karthik Srinivasan
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] CALEA Enforcement
> 
>  Please see comments inline
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On Behalf Of
> Olivier GRALL
> Sent: Tuesday, May 09, 2006 5:38 AM
> To: Karthik Srinivasan
> Cc: Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] CALEA Enforcement
> 
> Skype partners for SkypeIn or SkypeOut are VoIP providers. So, they should be included.
> 
> Skype is clearly a problem to legal interception functions. But it is not alone. Beyond that, a
> simple call between two IP addresses won't be on the responsibility of a Telecom Service
> provider. But it can be the Internet Service provider responsibility. Then, a solution is that
> the ISP watch for all the traffic looking for VoIP signalizations. If the ISP can identify
> Skype traffic then it can forbid it. But I think it is hard to identify clearly Skype traffic. For
> the moment, I think an ISP can't verify all the traffic on its network.
> 
> For VoIP Service provider, there is another issue. For instance, for SIP, if ICE methodology
> is deployed then media packets won't be available to be duplicated in most cases. And if we
> modify the media packets usual way then a detection of the interception is possible.
> 
> [Sachin] : Can you elaborate more on this
> 
> 
> Olivier GRALL
> NeoTIP SA
> 
> Karthik Srinivasan a écrit :
> 
> >Ok.. Just read the note better. It does include VoIP providers. So, I guess Vonage gets
> included. How about Skype? Does SkypeIn/SkypeOut contribute to being a VoIP provider
> with interconnects?
> >
> >  Has anyone done a study on financial ramifications of such regulatory deployments? Can
> such deployments be built in a way as to leading to improved services?
> >
> >  -- Karthik
> >
> >Karthik Srinivasan <karsrini1973 at yahoo.com> wrote:
> >    The order has targeted the telecom carriers. But what about providers like Vonage or
> services like Skype. If someone is "on the wall" as far as the law is concerned, they may as
> well use these services and escape any intercept.
> >
> >Geoff Devine <gdevine at cedarpointcom.com> wrote:
> >  If you look at standards bodies like 3GPP and TISPAN, the EU is
> >certainly treating lawful intercept as a core requirement for VoIP
> >networks. The US requirement that all service providers offer the
> >equivalent of J-STD-025 call content and call detail also exists in
> >ETSI documents. Class 5 offices have been required to support lawful
> >intercept for years. That requirement is now being pushed to edge
> >devices like media gateways, CMTSs, DSLAMs, and edge routers. Not only
> >is it feasible, but it's already implemented in North America for all
> >the voice over cable deployments (approaching 3 million VoIP lines and
> >growing exponentially).
> >
> >PacketCable uses an SDESCRIPTIONS-like key exchange where the media
> >keying is passed in the clear within the SDP. Call signaling is
> >encrypted between the client device and the walled garden. It's more
> >secure than today's telephone network since you have to be at the cable
> >head end (inside the walled garden) to see decrypted signaling traffic.
> >With a butt set, I can listen in on any analog phone line by tapping in
> >anywhere on the copper loop.
> >
> >Geoff Devine
> >Chief Architect
> >Cedar Point Communications
> >
> >----------------------------------------------------------------------
> >
> >Date: Sat, 6 May 2006 14:29:53 +0200
> >From: "Voiceline"
> >
> >Subject: Re: [VOIPSEC] CALEA Enforcement
> >To: "Gupta, Sachin" ,
> >Message-ID: <000f01c67108$c70d1c00$0b01a8c0 at patrick>
> >Content-Type: text/plain; format=flowed; charset="iso-8859-1";
> >reply-type=original
> >
> >The fourth order: "call-identifying information" and "call content
> >information"
> >Call content information is taking it to fare in my opinion (Not even
> >getting in to the "protecting subscriber privacy" issue), the ISP would
> >have to store all the content of all calls, not feasible in any
> >practical sense.
> >The EU is seemingly not taking it that fare, only call-identifying
> >information is on the table, "at the moment"...
> >
> >
> >/Patrick
> >
> >----- Original Message -----
> >From: "Gupta, Sachin"
> >To:
> >Sent: Friday, May 05, 2006 10:33 PM
> >Subject: [VOIPSEC] CALEA Enforcement
> >
> >
> >
> >
> >>I came across an article which mentions the enforcement of CALEA .
> >>
> >>
> >Would
> >
> >
> >>this mean no end-to-end security ?
> >>How would any kind of legal intercept be possible if there is
> >>
> >>
> >end-to-end
> >
> >
> >>security ?
> >>
> >>http://hraunfoss.fcc.gov/edocs_public/attachmatch/DOC-265221A1.pdf
> >>
> >>Sachin
> >>
> >>
> >
> >
> >
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >---------------------------------
> >  How low will we go? Check out Yahoo! Messenger's low PC-to-Phone call rates.
> >
> >
> >---------------------------------
> >Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls.  Great rates starting at
> 1¢/min.
> >_______________________________________________
> >Voipsec mailing list
> >Voipsec at voipsa.org
> >http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
> >
> 
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.392 / Virus Database: 268.5.5/333 - Release Date: 5/5/2006
> 