Illegal Wiretapping - Not so Easy

Recent news coverage of the Greek cell phone wiretapping scandal should put to rest some of the fears that people have over illegal wiretapping. Renewed interest in this story was sparked by an extensive analysis in the IEEE’s online magazine Spectrum (http://www.spectrum.ieee.org/jul07/5280 ). The article describes in detail how an illegal wiretapping operation existed in Greece, at cell phone carrier Vodaphone, for over nine months. In reading the news coverage and the IEEE article “The Athens Affair “ by Vassilis Prevelakis and Diomidis Spinellis, one can’t help but be amazed at the significant effort it took to illegally take advantage of the lawful intercept capabilities that existed on the phone switches.

Please understand that I’m not talking about the now infamous “warrant-less wiretaps” done by the Bush administration but rather the illegal use of technology to wiretap individuals where no authorization, warranted or otherwise, existed (except maybe in the mind of the perpetrators) to do the wiretaps.

For a long time now, skeptics have claimed that having an automated, centralized, standardized platform for performing lawful intercept, at carrier locations, actually creates a security risk rather than reducing it. The argument concludes that if a lawful intercept system is easy to use by the phone carriers, then surely the bad guys out there will be able to easily defeat the system and manipulate it to their own ends. On first glance the Greek incident seems to support this concern.

In fact, a report last year from the Information Technology Association of America (ITAA) raised that very issue: “Designing wiretapping into the communication system raises a fundamental security issue: can the capability be controlled so that only authorized parties can employ it?” However, the report concluded that for traditional wired and wireless telephony, such as the Greek Vodaphone system, it wasn’t a problem. The ITAA study even referenced the Greek incident and concluded that information available at the time pointed to an inside job instead of a malicious outside hacker.

The IEEE report carefully and fully reveals the lengths taken to achieve this feat, and justifies the assertion that this was not a trivial or easy thing to do. Through this revelation it becomes obvious just how much time, commitment, expertise and undetected access had to be garnered in order to defeat a system like this.

The experts will tell you there is no such thing as an absolutely impregnable system; rather, security is really a matter of making a system sufficiently difficult to breach. Hacking the Vodaphone system was certainly no cakewalk and it would be very difficult to replicate. Consider these four factors:

Time – significant time planning, designing and writing software went into this effort. This wasn’t an afternoon or weekend project someone thought they would throw together.

Commitment – since the software development work had to have gone on for weeks, if not months, surely this was a very committed effort and not an amateur’s hobby or prank

Expertise – the software used in the Ericsson switches is not a common programming language that the average software developer off the street can be successful with. In fact very few people know the language or the design of the system well enough to write code that will work, never mind secret code that is undetectable.

Undetected Access – again this is not something readily available to the public, it took the right person in the right position to gain access to the systems.

Even just looking at these factors quickly, the argument about how secure these solutions are becomes self-evident. Clearly this is not the stuff that the average bad guy or even organized crime could pull off. Based on this evidence the general public in Greece, the rest of Europe, North America, Asia or any where else in the world where these systems are used, should be reassured that they are secure and when used properly, can certainly benefit them.

Till next time ... (when I will return to Data Retention as I promised in my last post)

Google's Data Retention Policy Under Scrutiny and part of a Contradiction

Not only Google but now the data retention practices of all the big search engine companies (Yahoo, Ask etc.) are being reviewed. This is mainly coming from the European community, with Spain being the latest to announce an investigation.

Generically, data retention is the storing of communication session related information. This amounts to call data records in the telephony world and transaction logs (from routers/switches) in the IP world, with the possibility of also storing things like URLs and email headers. The point of these policies is to be able to determine, after the fact, who was communicating with whom and what sites were being visited. Data Retention policies do not include storage of the actual content of the communication or the information that was viewed/retrieved from a website but they do store information for all subscribers. This type of information proved to be very useful in investigating incidents like the Madrid train bombing and the UK subway bombing.

So why would a search engine company need this info? Presumably it is used to improve the accuracy and appropriateness of searches. Not only the searches of individuals based on previous searches but also the searches of people that fall generically into similar groups. Example: I search for "limousines in Connecticut" because I live in Connecticut and need a limousine, but out of the search results that are returned I pick the company that goes to New York City and so do a majority of other people. So this information can then be used to "tune" the results of future requests for people looking for limousines in Connecticut because they are probably either going to the airports in New York or the theater district in NYC for a show.

Ok, so they are storing my information and using it to improve their product, what is the problem? Well, there are very strict privacy protection rules in place in Europe that dictate how long information can be stored, who can view and how it can be used, so advocates for the different countries are trying to balance those requirements (which may have been on the books for many years now) against the commercial needs of today's service providers.

The thing that makes this even more interesting (and here is the contradiction), there was an EU Directive passed in March of 2006 that requires all EU member states to pass specific, national legislation supporting Data Retention of telephony service providers and ISPs. It requires, among other things, the telephony service providers to store call data information for two years and ISP event data for 6 months. The deadline for passing legislation is September 15th of this year with implementations starting in March of 2008.

So while the EU community is examining practices and working with the search engine companies to reduce the amount of data retained, they are at the same time under the gun to pass legislation that requires service providers to store more information.

This is a fairly broad subject and I'll continue on this subject in my next post. Till then ...

National Security Letters and the FBI

There has been a lot of hub bub this week over the FBI's use of National Security Letters and the Dept. of Justice's audit that was performed revealing that in over 1000 cases incorrect or additional information was collected.

A couple of points on this issue stood out in my mind:

1. The Audit concluded that in none of the cases did the agents intentionally over-collect info
2. Most of the extra information provided was done accidentally by the service provider / enterprise
3. This really had to do with static subscriber information not dynamic call information, which really means it had little to do with lawful intercept/wiretapping since addresses etc. are not provided as part of electronic surveillance

So if it wasn't intentional, how did the over-collection (providing) of information occur?

Now I don't have specifics on the actual use and implementation of the NSLs in these cases but if we look at the way CALEA based wiretapping is done and compare it to the use of the NSLs, you can draw some conclusions on what might have happened and why the over-collection occurred and why it doesn't occur for CALEA based wiretaps.

In CALEA based electronic surveillance, the fundamental concept is that the information is collected in real time as the communication session occurs. If that is to happen then specific target identifiers need to be articulated, the type of information to collect and directions on where to send the information need to be provided, otherwise the systems simply won't work. As long as those directions are followed then the system rules (not a person) within the Mediation/Delivery Functions control what information can be sent. In addition the protocols and standards (J-STD, PacketCable, ATIS etc.) only allow certain information, in specified parameters, with specified formats to be sent. And finally the collection function at law enforcement only accepts information that follows the prescribed formats and standards. Using this methodology, the information provided to law enforcement is very specific and well documented and significantly reduces the possibility of over-collection. Obviously over-collection could occur if someone put in the wrong end date etc. but in general the system has many checks and balances to ensure that CALEA based intercepts provide exactly what is permitted.

In contrast, the NSLs were more free form in their directions and use, and didn't have well established industry standards to fall back in the collection and delivery of information to law enforcement. It fell to the knowledge and capabilities the person receiving the NSL to determine what information was appropriate to send, how much to send and how to send it. Since it was determined that this was not intentionally done, clearly the problem was with the process and not the intention.

Till next time ...

DoJ Files Deficiency Petition with FCC over J-STD-025B

On May 15th 2007, the Dept. of Justice (as represented by the FBI, DEA and National Security Division) filed a "Petition for Expedited Rulemaking to Establish Technical Requirements and Standards Pursuant to Section 107(b) of the Communications Assistance for Law Enforcement Act", specifically in regard to J-STD-025B where it covers CDMA2000 packet data wireless services.

So what does this mean? Section 107 of CALEA covers the "Technical Assistance" portion of the CALEA law and during 2003 when the TIA and ATIS standards bodies were developing the JSTD25B standard, Law Enforcement (represented by the FBI at those meetings), raised several concerns over what they felt were technical deficiencies in the standard. Those concerns were never adequately satisfied in their opinion but the standards bodies moved forward anyway and the standard became effective in January of 2004. In March 2004 the standard (which at that point was only a "Trial Use" standard) was submitted for ballot to become an ANSI standard. In August 2006, J-STD-025B was adopted as an ANSI standard. At that time Law Enforcement began formulating a response to articulate the deficiencies they felt were still part of the standard. On May 15th (coincidence that it was the day after the May 14th deadline for Broadband and VoIP compliance? Probably not) they filed their official request for rulemaking to address these technical concerns.

So what are they asking for? On the technical side they are asking for 4 things:

1. Addition of Packet Activity Reporting - this would provide, among other things, the protocol in use, the Originating and Terminating IP address, the IP version and the Port number. The same types of things that are available as Call Data (or CII) for circuit switch calls today

2. Timing Information (Time stamping) - currently J-STD025B does not require any time stamping and they would like it to match the guidelines set forth by the commission for circuit switch time stamps (time stamp within 200ms and delivery to the LEA within 8 seconds).

3. More granular Location Information - currently cell site and sector are available but with the proliferation of location based services, it seems that more granular location information would be "reasonably available" (the metric used to determine what LI information can be made available to law enforcement).

4. Increased Security, Performance and Reliability of Delivery - these are fairly wide ranging items but the bottom line is that they want established rules over the protection of sensitive information and processes (internal as well as technical), along with assurances that they are receiving all of the packets from a communication session

On the process side, they are looking for an expedited ruling from the FCC along with a compliance deadline of 12 months after the FCC makes its' ruling.

Last week's ISS World conference didn't shed any new light on the subject even though the FBI, FCC and DEA were all represented there. They continued to reference the filing and the information contained within it.

So what does the timeline and next steps for this look like? Well this process has been followed before with both the Report and Orders over Broadband and VoIP compliance and with the original J-STD-025 (which is why J-STD-025A now exists). There is a response/comment period that is now underway and that will lead to a review period by the FCC. There is also a possibility that a second round of response/comments and review will take place. At some point the FCC will make a ruling, this will probably be somewhere between 8 and 18 months away. When the ruling occurs the standards bodies can then address the content of the ruling and implement any necessary changes to the standard. I say "necessary changes" because remember, as I noted above, this has happened before and just because capabilities are requested doesn't mean they are automatically granted. The original request for additional capabilities for J-STD-025 was for 11 items but only 7 were actually granted in the "Punchlist".

So how long will the changes to the standard take? Again it depends on how the FCC rules, but most likely 8 - 12 months. Which then begs the question, if compliance needs to be achieved within 12 months of the ruling but the standards body may take up to 12 months to modify the standard, how will compliance be achieved on time? Sound familiar?

Till next time ...

What is a Mediated Probe?

I've talked about probes in the past, both in the context of Active vs. Passive and with regard to doing VoIP intercept. And now as the May 14th date for compliance approaches for both broadband and VoIP providers, I'm taking a look at another category of probe, the Mediated Probe, since they seem to be popular with the ISPs.

As noted in previous entries, probes are typically used to fill a need when the network isn't able to provide Access to intercept traffic or if in some cases the network solution isn't cost effective. However, this new comer to the space tries to combine both the Access and Delivery (Mediation) components of the LI architecture into one device (harkening back to the days when switch manufacturers were putting an LI solution on every switch instead of letting the service provider own and operate one solution). Utilizing some type of packet sniffer or "Deep Packet Inspection" technology (the new buzzword for probes) the Mediated Probe identifies and replicates the traffic but instead of sending it to a central Mediation platform for correlation, formatting and delivery to the LEA(s), it sends it directly to the LEA.

This sounds reasonable but there are again several concerns, just like there were for probes in a VoIP environment. First concern is what if I need more than one probe? Law Enforcement now needs to connect to all the deployed devices? Second, what if I offer more than one type of service (VoIP, broadband, wireless data etc.)? How do these services get correlated and do I need a second solution for the other types of services? Will all delivery standards be supported on the probe or just a select one or two? What if there are multiple intercept access points for a session? Is this technology really an LI solution or is it some other kind of technology morphed to take advantage of the May 14 deadline?

Now it isn't all bad news as these products do have a place. For very small carrier's (ISPs) that only plan on being an ISP and don't want to offer other services, this may be a viable solution for them. A small compact, and theoretically, cost-effective solution.

So as long as you recognize what your needs are and what the limitations of a Mediated probe are, it could be a solution for you.

Till next time ...

New LI Standard for ISP data

On April 2, 2007, the ATIS Standard on Lawfully Authorized Electronic Surveillance (LAES) for Internet Access and Services (ATIS-1000013.2007) was approved. This standard has been defined primarily for use in the US for broadband (ISP, WISP) service providers in response to the FCC’s 2005 and 2006 Report and Orders. Those Report and Orders require all “facilities based broadband and interconnected VoIP” service providers to be CALEA compliant by May 14, 2007 (which is just around the corner). The FCC issued the Report and Orders after the FBI, DOJ and DEA filed a joint petition outlining the need to access communications deemed “information services” in the original CALEA legislation. Clearly broadband services today (email, video, chat, VoIP etc.) are no longer the one way data access “information services” that defined the internet in the early 90’s when CALEA was passed.

This standard is the latest standard to be adopted globally and is in keeping with international trends to keep law enforcement’s capabilities current with advancing technologies. The European standards body (ETSI) adopted a similar “data” standard several years ago as legislation there has existed for many years, with the Netherlands leading the way and passing legislation in 2001 that defined the very first data standard which was TIIT (Transport of Intercepted IP Traffic).

As would be suspected, like other standards, the ATIS standard covers the Handover interfaces (HI-2, HI-3) between the Mediation (Delivery) Function at the service provider and the Collection Function at law enforcement. Historically HI-2 for US standards has been primarily tasked with delivering call/signaling data (start of call, DTMF digits, call waiting signals etc.) for voice calls but obviously in the world of IP/data communications, the character of those “call” data messages has changed. In this standard the HI-2 data messages focus on network “access” (Attempt, Reject, Session End, Failed etc.) and “session” progress (Start, End, Failed, Already Established).

In addition, HI-3 has been defined to carry the “content” of the session. Again traditionally in a voice world this carried TDM voice (wireless or wireline) but now it is carrying the packets of the broadband sessions so that they can be recreated at the LEA.

Other standard bodies also continue their work, including PacketCable for PacketCable 2.0 (VoIP and data), ATIS-PP-1000678.2006 for wireline VoIP, and TIA-1066 for VoIP in CDMA networks.

As things evolve I’ll keep you posted. Till next time …

How Long Do I Get To Implement A Wiretap Request?

As carriers and service providers new to the world of Lawful Intercept start to implement their LI solutions in order to meet the May 14, 2007 deadline, one question that gets asked repeatedly centers on how fast an individual court order needs to be implemented. While no specific requirement exists, expectations do. And these expectations do not include a “10 day grace period for broadband intercepts” that is rumored to exist.

In seeking and receiving approval for a wiretap (typically a lengthy and intensive process) law enforcement and the court system assume that given the amount of work put into it, that it will start as soon as possible. In fact, the directions given to the carriers on the court order provide both a start and end date and instruct them to implement the intercept “expeditiously”. This is important because the start and stop dates bound the duration of the wiretap and everyday spent waiting for the wiretap to start is one less day law enforcement has to work on the investigation.

Normally with an active solution (see earlier entries) starting the intercept quickly isn’t an issue but as carriers consider “just in time” passive solutions, that include moving probes from one location to another, time constraints may become a consideration. Just in time solutions can prove to be a cost effective solution for carriers, but certain implementation strategies may not meet the intention and desire of law enforcement for an expeditious start to the intercept.

Till next time …

Do Probes Provide Complete Solutions for VoIP?

In my last entry I talked about Active vs. Passive intercept and the use of probes from a high level perspective. In this entry I want to identify a couple of cautions with regard to the use of probes to intercept VoIP calls.

Probes can be useful in VoIP LI solutions when positioned appropriately in the network. Typically they will need to be deployed to capture both the content (near the edge of the network) and the signaling (near the core). However, even with the appropriate positioning of probes they most likely won't be able to capture all call scenarios.

One of those scenarios includes calls that are forwarded or redirected off of the carrier's VoIP network to the PSTN (or any other network for that matter). In this scenario, the target has forwarded his phone to a number off of the VoIP carrier's network. An associate then calls the target's phone, the target's network determines that this call is forwarded to a number off of its' network and immediately redirects the call back out to the PSTN for proper termination. In this scenario the call content only reaches the gateway at the edge of the network and a probe solution wouldn't be able to access it.

Another area of caution includes the carrier's responsibility to provide Dialed Digit Extraction (DDE). DDE was one of the Punchlist requirements established with J-STD-025A. This requires that any DTMF digits entered during a call be identified, isolated and sent to the LEA as Call Data. Preferably these digits are extracted from the in-band content so that they can't be spoofed. Most probes don't have any DSP resources and therefore can not extract these digits and send them to the LEA as required by J-STD.

Just a few more reasons to make sure any investment in an LI implementation is comprehensive in nature and covers all scenarios, not just most.

Till next time ...

Doesn't a Probe actively intercept traffic?

When deciding on the proper technique for implementing an LI solution, quite often the question of "Active" vs. "Passive" comes up, especially in IP based networks. In order to understand what this means we have to understand that in lawful intercept parlance, Active and Passive have their own meanings.

An active solution is one in which the Mediation/Delivery Function has a defined interface with an Access Function (network element: router, SBC, switch etc.) that allows provisioning of target information, the exchange of session information and the replication of communication traffic (example: Cisco SII). This interface is called "active" because the network element (AF) is actively identifying and replicating target traffic based on requests from the Mediation Function (MF). Since the connections between the AF and MF are typically IP based, no special connectivity is needed and the AFs can be activated very quickly.

A passive solution employs a probe (sniffer) to identify and replicate traffic. To gain access to network traffic the probe requires either a network tap (like NetOptics) or a "SPAN" type of interface. The probe then uses the same targeting information to dynamically identify and replicate traffic. It isn't called a passive solution because it isn't actively working; it is passive because it isn't an inherent part of the active network and it sits outside of the network looking in.

Both solutions have pros and cons; an active solution is quickly implemented but only works on certain models and may require software upgrades. Probes can be expensive but are easily moved around a network and don't care about software releases or models of equipment.

Active = network element with support for a lawful intercept interface
Passive = probe attached to the network but not actively involved with network switching

Till next time ...

Filing date for CALEA "Monitoring Report" upon us

Everyone involved in CALEA and Lawful Intercept should be well aware of the May 14 CALEA compliance deadline for "facilities-based broadband" and "inter-connected VoIP" providers. But one of the other intermediary dates is fast approaching (only 11 days to go). February 12th is the deadline for the filing of Monitoring reports. And as such I thought a quick refresher and review of this form and its' purpose might be useful.

Back on December 12th the OMB (in compliance with the Reduction in Paperwork Act) authorized the FCC to move forward with requiring service providers to file Monitoring reports. The FCC's declaration of the approved dates and the forms themselves can be found at the link below.

http://www.fcc.gov/Daily_Releases/Daily_Digest/2006/dd061214.html

and look for:

Released: 12/14/2006. OMB APPROVES CALEA COMPLIANCE MONITORING REPORT FOR PROVIDERS OF FACILITIES-BASED BROADBAND INTERNET ACCESS AND INTERCONNECTED VOIP SERVICE; REPORTS ARE DUE FEBRUARY 12, 2007. (DA No. 06-2513). (Dkt No 04-295). PSHSB. Contact: Thomas J. Beers at (202) 418-0952 DA-06-2513A1.doc DA-06-2513A2.doc DA-06-2513A3.doc DA-06-2513A1.pdf DA-06-2513A2.pdf DA-06-2513A3.pdf DA-06-2513A1.txt DA-06-2513A2.txt DA-06-2513A3.txt

The reason for the Monitoring Report (445 form) filing is so that law enforcement understands the progress being made by carriers to reach compliance. In the late 90's when carriers were working to reach compliance for the first CALEA deadline(s), law enforcement had no idea where everyone stood until the deadline was reached. This time they are requiring "progress" reports to give them a better idea of where things stand.

For a 445 filing, there are 3 relevant documents:

DA-06-2513A1 - this describes the ruling and the fact that the Office of Management and Budget has now fulfilled the requirements of the Reduction in Paperwork Act (the item that held the dates up to begin with) and the reports can now be filed

DA-06-2513A2 - This is the instructions document. This describes each of the lines in the actual 455 form, what should be filled in, where copies are to be sent and by when.

DA-06-2513A3 - This is the 445 Form itself. This is a brief 4 page document with 12 line items (the first 7 really don't count) to fill in and a small glossary. No essay questions, no multiple choice, no true/false, just simple questions as described below.

Form 445 Questions:

1 -7 Contact information: Name, State, FCC #, 499 Id, affiliate names, parent company, address

8. Will your networks be compliant by May 14?
Type of facilities

9. Which networks will not be compliant?
Type of facilities
Expected date to reach compliance
Reasons for delay

10. Compliance Method(s) being used
Industry standard
Proprietary/custom
Consultation with DOJ
TTP If so which one?

11. What items are causing delays?
Type of Equipment
Installation
Manufacturer
Other
Mediation Actions being taken to resolve the delays

12. Signature of company officer


So all in all pretty simple. Take a look and feel free to comment. Till next time ...

FBI's Carnivore went quiet but methods under scrutiny again

Some of you may have seen articles ( http://news.zdnet.com/2100-9595_22-6154457.html ) about a presentation made by Professor Paul Ohm (former trial attorney at the Justice Department) at the "Search & Seizure in the Digital Age" symposium held at Stanford University last Friday. Professor Ohm, currently a law professor at Univ. of Colorado, spoke about the new "full-pipe recording" approach the FBI is now using when doing a broadband intercept.

His description asserts that instead of just intercepting the IP traffic of the target, they are collecting traffic from a point in the network that includes other user's traffic as well. I would suggest that in an environment that hasn't achieved CALEA compliance yet (the FCC CALEA deadline is May 14, 2007 see earlier entries) this may be necessary. But once true LI solutions are in place this will no longer be necessary. Current LI technology provides for both active and passive solutions that can identify the specific traffic of a target, assuming the target is known. There may be challenges with some enterprises in identifying their users but certainly all service providers know who their users are since they have to bill them :-)

And don't be surprised if you continue to hear about "full-pipe" intercepts even after CALEA compliant solutions are in place. In LI circles "full-pipe" actually has a different meaning and references the traffic on the "pipe" that goes to the target's location. This is in contrast to an intercept that would intercept a specific type of traffic (email, VoIP, chat, http etc.).

An example makes this clear. I happen to use Charter as my cable/broadband provider and Vonage as my VoIP provider. Because Vonage operates within the U.S., law enforcement could get a warrant, serve Vonage with it and only intercept my voice IP traffic. Now if my VoIP provider happened to be out of the country, then law enforcement could go to Charter and intercept the "full pipe" going to my house in order to access the voice traffic that is embedded in the IP stream going across the pipe I have from Charter. They would have the "full-pipe" but it would only be my traffic, not any one else's.

Feel free to comment. Till next time ...

Bush Administration Changes Stance on "Unauthorized" Wiretapping

Ever since the Foreign Intelligence Surveillance Act (FISA) was passed in 1978 there have been two processes for obtaining and implementing wiretaps. One utilizes the traditional court system while the other uses a secret court system, but in both cases the judicial branch has acts as one side of the "check and balance" in the request and approval process of obtaining wiretaps.

For normal criminal activity and investigations sworn law enforcement agents, with the appropriate training and certification, build portfolios with information that allows them to justify to a judge why a wiretap is needed. The judge then either approves or denies the request, but even with approval puts restrictions on the duration and use of the wiretap. For cases involving foreign targets/communication, the same process is followed but due to the highly sensitive nature of foreign intelligence, the requests are taken out of the public system and processed through a separate and distinct Foreign Intelligence Surveillance Court system.

An issue arose at the end of 2005 when it was discovered that the Bush administration, under the umbrella of executive war time powers, authorized wiretaps without the review or approval of any court system. Now I'm not a legal authority so I'm not in a position to comment one way or the other on the legality of the action but it is clear to see why this raised concerns with many Americans.

However, this past Wednesday the administration has reversed their position and has apparently worked out an agreement to work with the FISA court system to obtain expedited authorization for the intercepts they need.

I think this agreement is good news for America. It allows the government to keep doing what it needs to do to protect the citizens of the U.S. in a timely manner while also protecting the privacy rights and concerns of those same citizens.

Please feel free to comment. Till next time ...

LI Evolution - the pace quickens

I was cleaning out my basement this weekend and came across an assortment of telephony equipment from my past (butt set, continuity tester, bridge clips, punchdown tool, 66 blocks etc.), a little museum of sorts. The last time I used any of it was when I was teaching my son's Cub Scout den how phones and phone networks work (no I wasn't teaching them how to wiretap anyone). As I reflected on my past and my father-in-law's career at New York Telephone (way back before Verizon and Bell Atlantic), it impressed me with how significantly and how rapidly things have changed in the past 20+ years.

In the 80's most everything was still analog and services like caller id, call forwarding were just being introduced. I remember getting "Total Phone" in 1982 in Connecticut, just after we replaced our rotary phone with a touchtone. Of course this was all prior to CALEA and wiretapping was still done by bridging on a copper pair or using a "loop around" trunk that terminated on analog recorders. But by the late 80's digital technology was on a tear and law enforcement was starting to realize what it was potentially missing and asked for help.

CALEA was passed and new solutions were implemented that were able to access call forwarding, conf calls etc. and most of it was done right on the "big iron" switches of the day. But by the late 90's IP services were making their presence know and a new generation of LI needed to be deployed. No longer was traffic going to be delivered over POTS dial up lines, new IP connectivity for data and content was needed and implemented.

And it appears we're on the brink of another change, another generation. Forget the centralized softswitches and media gateways of today's VoIP services, communication is now done with simple SIP clients using standard broadband pipes. So what does that mean for LI solutions? Well they have had to adapt and include "application" servers so that things like conference calls, prepaid calls and PTT talk groups are captured. Deep packet inspection has also become a critical component of these solutions as communication traffic needs to be filtered out as these broadband pipes become consumed with the transfer of entertainment media. And forget about using "well known ports" to identify traffic, protocol characterization is now the key to finding and tracking the targeted traffic.

From the use of butt sets for decades, to nationalized standards in 2 decades, to 2 new generations of IP LI in one decade, the pace of technology advancement, and the equivalent advances needed within LI, certainly is increasing rapidly.

Please feel free to send comments or questions. Till next time ...

A call for more standards

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 ...