[VOIPSEC] CALEA Enforcement
olivier.grall at neotip.com
Thu May 11 08:31:35 BST 2006
I completely agree with you : the SBC is the best way to solve all the
legal interception issues for a VoIP service provider.
When I was speaking about TURN server, it was just if ICE methodology
would be used. I don't think it is a good idea to amalgamate these 2
concepts or products : a TURN server is not a SBC.
Geoff Devine a écrit :
>The only way to make lawful intercept undetectable is to _ALWAYS_ run
>the media through a session border controller. You can call an SBC a
>TURN Server if you like and put the intercept function there.
>PacketCable islands solve the problem in a slightly different way.
>Rather than require an SBC in their network, they make the ingress &
>egress points on their network deal with the problem. The cable
>operator owns their own CMTSs (the cable access network device) and
>Media Gateways. They have the CMTS and MG sniff intercepted RTP flows
>and redirect a copy of the flow to a lawful intercept delivery function.
>If the RTP stream is encrypted, the soft switch relays the keying
>information to the delivery function on another interface. End to end
>key exchange uses an SDESCRIPTIONS-like method where the keys are
>embedded in the SDP of the call signaling. The call signaling is made
>private using transport mode IPSec.
>In that architecture, once you have SIP peering relationships between a
>PacketCable island and some other network, you pretty much have to put
>an SBC on the border to get lawful intercept. Otherwise, you can defeat
>the lawful intercept via a call redirection mechanism like call
>forwarding or call transfer.
>Cedar Point Communications
>Date: Wed, 10 May 2006 12:14:19 +0200
>From: Olivier GRALL <olivier.grall at neotip.com>
>Subject: Re: [VOIPSEC] CALEA Enforcement
>To: Voipsec at voipsa.org
>Message-ID: <4461BCFB.20200 at neotip.com>
>Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>With ICE methodology, an optimized path for RTP/RTCP streams is decided
>by SIP UA even if there is a NATed access to the VoIP service.
>In most cases, this results in an exchange of RTP/RTCP packets directly
>between 2 UA perhaps through NAT boxes. In other cases , the media
>packets need to be relayed by a dedicated server (TURN) which won't have
>any connectivity to a LIU (Legal Interception Unit).
>So a solution may be to force the relay of media packets through a
>server with LIF or LIU connectivity. This can be done changing SDP
>offers/answers in a border element (SBC) speaking SIP. This media relay
>may have a fixed IP address. If the VoIP service provider activates
>this when a legal interception is needed, then all the media traffic
>will come from the media relay. I think if the person under surveillance
>used to have a look at the network flow then he can detect that the call
>is different than before legal interception activation.
>Voipsec mailing list
>Voipsec at voipsa.org
More information about the Voipsec