[VOIPSEC] An issue of trust?

[Geoff Devine]

Shawnmer at gmail.com gives a stab at analyzing the Cisco and SS8 lawful
intercept solution:

The Cisco CMTS bugs aren't particularly earth-shattering.... 

* No way of setting the DiffServ Code Point on replicated packets
streamed to the SS8 delivery function box.

* A couple of redundancy bugs when lawful intercept is enabled.

Maybe a little tutorial on how this works would be useful....  

Lawful intercepts are controlled by the Softswitch... the CMS in
PacketCable-speak.  The rules at the Softswitch are the same as those
found on any North American Class 5 office.  Administering a lawful
intercept is done under password control.  The service provider is
required by the court order to maintain the confidentiality of the
wiretap order.  In practice, this means that only one employee is
supposed to be the wiretap administrator for a particular switch and
they can be tossed in jail if they talk about it.  Access to the CMS for
administrative operations is supposed to be through a private management
interface.  If wiretaps are administered via a CLI interface, access
will likely be through SSH/Telnet.

When a wiretap trigger is installed, the CMS transmits RADIUS-based
event messages to the SS8 CALEA delivery function to provide J-STD-025
call detail channel information.  This RADIUS interface is 'supposed' to
be secured with IKE/IPSec but, in practice, nobody has ever turned this
on in a live network.  

As part of the PacketCable DQoS mechanism, the CMS also pushes a lawful
intercept object down to the CMTS for a particular phone call.  This
instructs the CMTS to replicate RTP packets for a particular flow, place
them in an envelope, and relay them to the SS8 delivery function.  This
is a transient function that only lives for the duration of a particular
phone call.  The DQoS interface between the CMS and CMTS are 'supposed'
to be secured with IKE/IPSec but, in practice, nobody has ever turned
this on in a live network.  If you managed to hack into the CMTS and had
a lot of internal knowledge, you could find the IP addresses of the MTAs
that are currently in phone calls that are being wire tapped.

You'd expect that the SS8 delivery function box would be sitting behind
a firewall.  The only traffic that should be allowed to get to it is
RADIUS messages from various PacketCable core elements and the
replicated RTP packet streams from CMTSs and (in some corner cases)
media gateways.

The biggest security risk, like usual, is the physical security of the
CALEA administrator and the physical security of the SS8 delivery
function box.  It would be really difficult to hack into a CMTS or
Softswitch to get access to wiretapping information.

This solution is workable as long as you're running in PacketCable
islands where all the core elements cooperate in the schema.  In
practice, this means that CMTSs and Media Gateways need to support the
packet replication and forwarding mechanism.  The problem comes when you
start bridging islands together or start interworking with SIP networks.
If you read the PacketCable CMSS spec (SIP between CMSs), it's possible
to pass wiretapping responsibility to another soft switch.  This
typically happens in a call redirection case.  

Example: 
Three PacketCable islands operated by Comcast, Charter, and Rogers in a
SIP peering arrangement.

*The MTA administered by Comcast has an intercept trigger.

*Call to MTAcomcast comes from MTAcharter in another PacketCable island.

 
*The call gets forwarded to a third MTArogers in another PacketCable
island.  In the SIP INVITE message between Comcast and Rogers, there is
a special PacketCable lawful intercept header that instructs the 3rd
island to conduct the intercept.

The problem is that the PacketCable islands may very well cross state or
even national borders (Canadian operators Rogers and Shaw are interested
in peering arrangements with the US cable operators).  You're also
transmitting lawful intercept information over the IP network between
soft switches that are beyond your corporate trust boundary.  We haven't
needed to address this yet since SIP peering is still a year+ away.  One
could imagine that the easiest solution is to push all this peering
traffic through an SBC to establish a trust boundary, police SLAs, and
provide CALEA for the obscure redirection corner case.

My company opted out of all of this.  Our motivation is that our product
handles both PacketCable VoIP traffic and traditional TDM Class 5 office
traffic.  For the Class 5 office TDM traffic, we have no choice but to
support the traditional J-STD-025 solution.  It was easier for us to
simply pass all RTP media streams through our box (an integrated SBC
function) rather than have two lawful intercept mechanisms in the same
box.  Along the way, we also anonymize MTA IP addresses which we think
is important as soft SIP clients get merged into cable product
offerings. Our solution is also more secure since we are not signaling
lawful intercept information around the managed IP network.

Geoff Devine
Chief Architect
Cedar Point Communications