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