Demystifying Lawful Intercept and CALEA TMC

A call for more standards

January 9, 2007
As noted in previous posts, I both attended and spoke at ISS World in December '06. At the conference my speaking topic was "Centralized Management - We missed the boat ". I'd like to briefly address that subject again here.

The original intent and concept for the Mediation (Delivery) Function, by the standards bodies, was to create a single, centralized point in the network, with clear demarcation points that would handle all interfaces needed to perform lawful intercept. The benefits of this are fairly well known and include at a high level:

• Centralized control
• Scaling across systems
• Support of legacy systems
• Securing sensitive information
• Reducting the amount of “technical” support needed to actually implement an intercept
• Software license expansion instead of incremental hardware to support new equipment
• Single point of interface for Law Enforcement

And for the most part the industry has done a good job in creating and implementing Mediation Functions, however there is an area where I think the industry has missed the boat. With the exception of Packet Cable, for the cable industry, none of the standards bodies have created standards for the INI (network side) interfaces. And even Packet Cable hasn't defined INI-1 (provisioning). The result is that almost every network element (router, gateway, wireless switch, PDSN, SGSN, AAA, DSLAM, softswitch etc.) has a unique or proprietary interface.

How did this happen? As with many things it was about money. When CALEA was first passed, wireline and wireless communications were the norm and switching manufacturers saw an opportunity to grab a share of the $500 million that congress set aside for implementation. So instead of creating INI interfaces that would support a single unified LI interface they built proprietary interfaces into their switches and charged the government for it. Now however the government money is gone and carriers are paying for CALEA capabilities.

The effect of this is that solution costs are higher and implementation schedules are longer because new interfaces have to be continually created in order to support LI on the various technologies that are being deployed. And in some cases it is even worse. No only do certain "old school" switch manufacturers still have proprietary interfaces, but they are also tightly guarding them and requiring their customers to pay a premium to open them up. When compared to a next generation company like Cisco, that has readily published and supported a consistent LI interface, it is obvious that these companies are not acting in the best interest of their customers.

Recommendation: Follow PacketCable's example and define interfaces on both sides of the Mediation Function. This will afford the following benefits:

• Allow Mediation Function developers to focus development efforts on:
–Security of sensitive information
–User experience
–Correlation of data and content
–Identification of IAPs (Intercept Access Points) in the new, complex IP networks
–Secured interfaces (INI and HI)
–Encryption
–Separation of applications/services
(movies, TV etc. from valuable transactions or communications)

• Lower total cost of ownership
–Single DF
–Reduced development for new network element support

• Higher quality products and solutions

• Quick integration and support of new “probe” technologies and capabilities

• Certification and qualification could occur faster and easier, similar to what has been done at Cable Labs in the past.


Summary

LI solutions have come a long way towards meeting the initial intent but aren’t there yet when it comes to the creation of standards based INI interfaces. In order to help push this effort forward, service providers need to change expectations and demand open, standards based INI interfaces from equipment manufacturers. And finally, the standards bodies should define a single INI standard, fully embracing the concept of separated AFs, MFs and CFs and removing equipment providers from undue influence over a function that is non-revenue generating for service providers.


Please send me any comments or thoughts. Till next time ...



Related Tags: , , , , ,

Listed below are links to sites that reference A call for more standards:

Trackback Pings

TrackBack URL for A call for more standards:
http://blog.tmcnet.com/mt3/t.fcgi/31509

Comments to A call for more standards


(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)