[VOIPSEC] CALEA Enforcement

[Shai Mohaban]

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