Today the Federal Communications Commission (FCC) issued a release announcing its new rule expanding the reach of the Communications Assistance to Law Enforcement Act (CALEA). The ruling is a reinterpretation of the scope of CALEA and will force Internet broadband providers and certain voice-over-IP (VoIP) providers to build backdoors into their networks that make it easier for law enforcement to wiretap them. The Electronic Frontier Foundation (EFF) has argued against this expansion of CALEA in several rounds of comments to the FCC on its proposed rule.
CALEA, a law passed in the early 1990s, mandated that all telephone providers build tappability into their networks, but expressly ruled out information services like broadband. Under the new ruling from the FCC, this tappability now extends to Internet broadband providers as well.
Practically, what this means is that the government will be asking broadband providers - as well as companies that manufacture devices used for broadband communications � to build insecure backdoors into their networks, imperiling the privacy and security of citizens on the Internet. It also hobbles technical innovation by forcing companies involved in broadband to redesign their products to meet government requirements.
"Expanding CALEA to the Internet is contrary to the statute and is a fundamentally flawed public policy," said Kurt Opsahl, EFF staff attorney. "This misguided tech mandate endangers the privacy of innocent people, stifles innovation and risks the functionality of the Internet as a forum for free and open expression."
Practically, what this means is that the government will be asking broadband providers
- as well as companies that manufacture devices used for broadband
communications � to build insecure backdoors into their networks,
imperiling the privacy and security of citizens on the Internet.
I'm sorry, but this is simply an unsupportable statement. What is
required of routers is that the provider be able to configure the device
to make copies of certain packets to a monitoring port. Assuming that
the monitoring port is duly managed, how does this qualify as "insecure"?
It also hobbles technical innovation by forcing companies involved in
broadband to redesign their products to meet government requirements.
As opposed to hobbling innovation by meeting customer requirements?
There are many issues with CALEA that one can object to, primarily
having to do with the checks necessary to ensure that appropriate
warrants are obtained and that the traffic is appropriately filtered
before monitoring. I'm disappointed that EFF is so off the mark here.
It also hobbles technical innovation by forcing companies involved in
broadband to redesign their products to meet government requirements.
As opposed to hobbling innovation by meeting customer requirements?
who's paying the bill? and sorry to hear from a vendor that meeting
the customers' requirements is such a negative thing.
You mistake my meaning, Randy. Implementing features ARE innovation.
Not hobbling it.
sorry if i misinterpreted.
i opine that some features are innovation and others not. i.e.,
x.25 support on modern kit seems a not innovative and a waste of
resources i would rather see applied elsewhere.
but every feature has its cost in complexity and resources to build
and maintain. resources are finite and complexity has super-linear
cost. so i would much prefer that the vendors concentrate on the
features *i* want <g>. and i am quite skeptical of features which
non-paying non-customers want.
We all pay the bill with higher equipment costs, the maintenance of configurations, and possible storage costs. CALEA was bound to include VoIP services - given the definition telecom carrier in the act; however, as I recall -- and I may be wrong -- when CALEA was first passed the carriers were given tax breaks and subsidies to implement changes. Is such financial help being offered today?
i opine that some features are innovation and others not. i.e.,
x.25 support on modern kit seems a not innovative and a waste of
resources i would rather see applied elsewhere.
Probably a fairer characterization.
but every feature has its cost in complexity and resources to build
and maintain. resources are finite and complexity has super-linear
cost. so i would much prefer that the vendors concentrate on the
features *i* want <g>. and i am quite skeptical of features which
non-paying non-customers want.
Well, I'm even skeptical of features that paying customers want. But
that doesn't pay the bills.
While complexity has super-linear cost, not all features introduce
significant complexity. It's very much a function of the architecture.
In a highly partitioned, loosely coupled system, adding a feature that
interacts with only a single other component in a trivial way may be
quite simple. In a monolithic system, adding a feature that permeates
the system may be so complex as to be unimplementable.
The features to avoid are those where the complexity cost outweighs the
revenue. If only we could evaluate this properly!
Who said the user end needs to support a "tap" being done? They can
just force ISP's to log everything at the headend. Your phone doesn't
need a specialized device to tap it right now does it; cell phones
either; the FBI can call the NSA anytime they want without a tap order
and get them to trigger ECHELON when your voice is apparant on any
line.
I'm sorry, but this is simply an unsupportable statement. What is
required of routers is that the provider be able to configure the device
to make copies of certain packets to a monitoring port. Assuming that
the monitoring port is duly managed, how does this qualify as "insecure"?
It qualifies as "insecure" because if that rather dubious assumption fails to
be true, you have a big problem.
If any port on a router is not duly managed, you have a big problem.
the FBI can call the NSA anytime they want without a tap order and
get them to trigger ECHELON when your voice is apparant on any
line.
Not me, I wrapped my cellphone in tin foil.
--matt@snark.net------------------------------------------<darwin><
The only thing necessary for the triumph
of evil is for good men to do nothing. - Edmund Burke
> I'm sorry, but this is simply an unsupportable statement. What is
> required of routers is that the provider be able to configure the device
> to make copies of certain packets to a monitoring port. Assuming that
> the monitoring port is duly managed, how does this qualify as "insecure"?
It qualifies as "insecure" because if that rather dubious assumption fails to
be true, you have a big problem.
Then you'll have to conclude that a lot of managed switches are insecure
since they include some form of packet mirroring capability.
but every feature has its cost in complexity and resources to build
and maintain. resources are finite and complexity has super-linear
cost. so i would much prefer that the vendors concentrate on the
features *i* want <g>. and i am quite skeptical of features which
non-paying non-customers want.
Agreed. However, in this case it matches a fature I've wanted for
years. Being able to mirror packets to a different port is pretty
common for managed switches, and is rather useful sometimes in
tracking abuse and similar. I *want* the same capability for my
routers.
Unfortunately, things are never as simple as they appear. The department
of justice/fbi/dea/etc wish lists have been published/leaked with a
suitable google search. Port mirroring may not be considered sufficient.
I think the EFF is missing the important part of the wish list items. The
wish list items aren't for wiretaps, but defining as many things as
possible as "non-content." Its important for network operators because
they will end up doing a lot more work digging through packets for
non-content information, and important for lawyers because it lessens the
legal requirements for non-content information. What is the "expectation
of privacy" of non-content information?
hopefully sticking some header on that packet to determine input
interface/lsp as well. hopefully also not dumping to a physical interface,
but to a 'vpn' interface so truckrolls to kalamazoo don't have to happen
each time 'elterrorista' moves from internet cafe' to internet cafe'
please
no real 'security' implications in the copy though, sure. (assuming
appropriate controls on config changes exist, and controls on the exit
point/storage of the copied data.
shiny side out one hopes? Seriously though, I'm not a telco/phone person,
but I was once told that the phone switch equipment does the tap
'automagically' to special ds-1 facilities inn LEA-land... which means the
cell phone can be wrapped in anything you'd like. If the calls get
completed a copy is silently made to the right folks (not the nsa, they
aren't LEA).
shiny side out one hopes? Seriously though, I'm not a telco/phone person,
but I was once told that the phone switch equipment does the tap
'automagically' to special ds-1 facilities inn LEA-land... which means the
cell phone can be wrapped in anything you'd like. If the calls get
completed a copy is silently made to the right folks (not the nsa, they
aren't LEA).
At least from the experiences I've indirectly gained, if the call terminates on a switch with tap gear, it's similar to a SPAN port. Not only does the recipient's phone ring, but the magic phone rings and outputs the information from both sides of the call, while inputting nothing. The federal folks spent big money to have the switch manufacturers implement the software functionality, but the telcos do have to acquire the equipment (or rights to it via contract). It was funny watching Siemens try to tell our employee (former Siemens employee, and experienced in CALEA) that we'd have to buy the feature...it was less than an hour before they were calling back asking to be able to add the feature.
