14 January 2009
Original URL now forbidding access:
Demystifying Lawful Interception and CALEA
January 9, 2007
Scott Coleman is Director of Marketing for Lawful Intercept at SS8 Networks.
He has been employed in the Telecommunications industry for 18 years and
involved in Lawful Intercept since 1999. Over those 18 years he worked his
way up from technical support engineer, to software developer, then to Product
Manager and finally to Marketeer. Scott has spoken at various industry
conferences, tradeshows and law enforcement forums on the current state of
lawful intercept technology and its future direction. In his role at SS8
he works with and advises both the largest and smallest carriers in the U.S.
and is spearheading an education campaign on lawful intercept, aptly named
July 20, 2007
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
). The article describes in detail how an illegal
wiretapping operation existed in
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
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
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
In fact, a report
last year from the Information Technology Association of America (ITAA) raised
that very issue:
into the communication system raises a fundamental security issue: can the
capability be controlled so that only authorized parties can employ
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
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
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
Expertise -- the software used in
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.
-- again this is not something readily available to the public, it took the
right person in the right position to gain access to the
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
Till Next time
... (when I will return to the subject of Data Retention as I promised last
posted at 9:15 PM
July 7, 2007
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
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
because I live in Connecticut and need a
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
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
It requires, among other things, the telephony service providers to store
call data information for two years and
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 ...
posted at 8:21 AM
June 15, 2007
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
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
So if it wasn't intentional, how did the over-collection (providing) of
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
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,
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 ...
posted at 4:20 PM
June 7, 2007
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
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
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
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 ...
posted at 7:16 AM
May 4, 2007
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
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 ...
posted at 10:59 AM
April 20, 2007
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
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 --
posted at 9:44 PM
March 13, 2007
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 ...
posted at 11:59 AM
February 28, 2007
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
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 ...
posted at 2:12 PM
February 9, 2007
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
Till next time ...
posted at 9:41 AM
February 1, 2007
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
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.
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
The reason for the Monitoring Report (455 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 455 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 455 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 455 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
Consultation with DOJ
TTP If so which one?
11. What items are causing delays?
Type of Equipment
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 ...
posted at 3:16 PM
January 30, 2007
Some of you may have seen articles 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
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
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 ...
posted at 4:16 PM
January 19, 2007
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 ...
posted at 1:28 PM
January 12, 2007
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
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 ...
posted at 9:25 AM
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
* 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
-- Secured interfaces (INI and HI)
-- 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.
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 ...
posted at 9:39 PM