[VOIPSEC] CALEA Enforcement

Thu May 11 11:52:42 CDT 2006

I think he meant the access edge router - i.e., the BRAS, CMTS, etc.  So it
has guaranteed visibility because it's the only entry/exit path to the UA.
Whether it's pragmatic to do it on every one of those, and scalable to
control them, is a different question. (especially for non-packetcable
networks)

Obviously CMTS' already have the ability to open/close gates from a
northbound control (COPS) interface for qos, and the call rate per-CMTS has
been low enough to make it reasonable scale/performance. (Certainly the
volume of lawful interception is so low it doesn't matter)  Whether the
operators actually do COPS dynamic media gate control with their CMTS today
I cannot say, but I think I can say I haven't seen any doing LI on them yet.

-hadriel

> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Olivier GRALL
> Sent: Thursday, May 11, 2006 6:38 AM
> To: Shai Mohaban; Voipsec at voipsa.org
> Subject: Re: [VOIPSEC] CALEA Enforcement
> 
> Shai,
> 
> I'd like to know if in this case, how are you sure that  the edge router
> will see the media flow of a call ? If it is not forced thanks to the
> signalization, the media packets may be sent through many core routers
> between the 2 endpoints without  crossing an edge router.
> 
> Then to forward all the informations needed to the LIU, the edge router
> should decode messages at layer 5 to extract all the identifiers. Is it
> possible for this kind of product ?
> 
> Olivier.
> 
> Shai Mohaban a écrit :
> 
> >Geoff,
> >
> >Running the media _ALWAYS_ through an SBC is one way but definitely not
> >the only way and not even the best way. One other potential solution,
> >which is also undetectable and is much better in terms of traffic
> >engineering, optimal route, etc, is to deploy some LI capabilities in
> >the edge routers (or the BRAS, etc). As far as I know LI is not required
> >for internal calls (and this is not relevant at all in the residential
> >market as there are no "internal" calls in this case) and virtually all
> >external traffic, including the media, will go through the edge router.
> >So the edge router can be controlled by some external signaling entity
> >(P-CSCF, SBC, etc) and be provisioned in real time with flows that need
> >to be duplicated. In fact the new NGN architectures from TISPAN and the
> >ITU already have exactly this kind of control mechanism to open and
> >close gates (using H.248 in the case of TISPAN). Extending those
> >interfaces to enable LI should not be too difficult...
> >
> >	Shai.
> >
> >-----Original Message-----
> >From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> >Behalf Of Geoff Devine
> >Sent: Wednesday, May 10, 2006 10:51 AM
> >To: Voipsec at voipsa.org
> >Subject: Re: [VOIPSEC] CALEA Enforcement
> >
> >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.
> >
> >Geoff Devine
> >Chief Architect
> >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.
> >
> >Olivier GRALL.
> >NeoTIP SA.
> >
> >
> >
> >_______________________________________________
> >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