[c-nsp] What are other SPs doing about CALEA?

Justin Shore justin at justinshore.com
Tue Feb 6 21:14:43 EST 2007


I'm sure this has been a hot topic around your local water dispenser, 
coffee maker or Mountain Dew machine.  It's been a hot topic in our 
office for many months.  How do we support this unfunded and 
ill-conceived mandate with our existing hardware?  What follows is a 
plethora of thoughts and questions.

This particular network consists of 2800 series branch routers (2821s, 
not the 2851 LI-supported model), 3660s for DSL aggregation and T1 
leased lines, 7206VXRs for DSL aggregation and another as a border 
router, AS5300s for dialin and some other misc routers, firewalls and 
SBCs for non-access-layer tasks.  Our newest addtions are 7600s and 
ME6524s for core routers at 2 POPs, ME3750s for aggregation at a POP, 
3845s for SSL VPN termination, and another 3845 that will deployed as a 
border router.  We also have Arris C3 CMTSs and are deploying Pannaway 
ADSL2+ products.

The only equipment in this list that support any form of LI for data are 
the C3s, 7206VXRs, 7600s in an upcoming IOS release, the 3845s, the 
3660s if we downgrade to a 12.3 release (and only voice then from what 
I've been told), and the Pannaway devices (only voice).  All VoIP 
provided by this provider/telco can be pulled off a class-5 switch which 
meets the voice CALEA requirements.

We been in discussions with trusted 3rd-party vendors over their 
possible solution, all of which are cost prohibitive (I swear we must be 
in the wrong business).  The most recent and most reasonably-priced 
vendor turned out to be very expensive when they told us that each 
LI-enabled device and each probe placed on the network to assist with 
non-LI-enabled devices would require a license.  That's for each capture 
point.  They recommended the use of probes and port mirroring or RSPAN 
where possible to capture data and to shunt it off to the mediation 
device.  All of my reading about LI makes me believe that the transport 
between the LI-enabled edge devices is encrypted, stuffed into UDP 
datagrams, addressed to the MD and routed back out onto the wire.  I'm 
not sure how a tcpdump can meet CALEA's requirements (not that the FCC 
really defined any requirements other than read our minds and make it 
work).  Am I missing something here?

I've been told that most SPs aren't replacing non-LI-compliant hardware 
and are simply planning on getting the data upstream of those edge 
devices.  For example our 3660s that are terminating customer T1s aren't 
compliant.  It was suggested that we simply get the traffic upstream of 
the 3660.  Does this meet the spirit of LI though?  What if one T1 
customer talks directly with another T1 customer and never leaves the 
3660 (same goes for cable, DSL, etc)?

This question was asked of me and I'll forward it to the group.  Can the 
7613s act as a LI-aggregation point and take stream of LI data from 
other LI-enabled devices and send it to the MD or act as the MD?  I'm 
doubting it; it sounds like LI stream have to be punted  to the MD 
directly.  Does Cisco make a MD or are they all 3rd-party devices?

What exactly is a LI stream composed of?  Is it a GRE tunnel, IPSec 
tunnel, a tunnel at all?  The docs have not gone into it at all.  I 
suppose I should just read the RFC for myself.

Does anyone know of an open source project to build a MD?  This strikes 
me as something a group of individuals would turn into an OSS project.  
It meets all the usual requirements to spawn an OSS project:  canned 
solutions are prohibitively expensive, mass problem for large groups of 
geeks, sufficient complexity, etc.  I can't imagine it being all that 
complicated if the protocols are standardized and published.

Has anyone found a decently priced trusted 3rd-party that knows how to 
implement LI correctly?  We've found many that really don't know how but 
they are sure willing to bill us to try.

I know we're not alone in this.  How are the rest of you fairing?

Thanks
  Justin




More information about the cisco-nsp mailing list