Mark, your info is 3 years old....

We have to be ready to "tap our lines".  Even IMs.
marlon

----- Original Message ----- From: "wispa" <[EMAIL PROTECTED]>
To: "WISPA General List" <wireless@wispa.org>
Sent: Monday, March 26, 2007 8:54 PM
Subject: Re: [WISPA] CALEA compliance methods


On Mon, 26 Mar 2007 19:49:43 -0400, Adam Greene wrote
Hi,

As a new member of WISPA I am reading with interest all of the
postings about CALEA from the past few weeks.

Thankfully, we have designed our network in such a way that all
customer IP traffic passes through at least one Cisco switch before
it can be bridged to any other customer or routed to the Internet,
so I think we'll be able to SPAN all customer traffic and from there
manipulate the data streams and hand them off to law enforcement.
The only exception to this case might be our Waverider CCU's, which
are routing packets between various end-users. I am going to contact
them to see what their take is on implementing LI -- we might need
to stop using the CCU's as routers.

The main questions I have for the forum are ... assuming we can at
least make a copy of a given customer's traffic without the customer
realizing it
(i.e. non-intrusively), how are we going to be able to format the
data to be able to hand it off to law enforcement? We obviously want
to do this in the most cost-effective way possible (read: open
source solution). http://www.opencalea.org/ definitely looks
promising, but it is just getting off the ground as far as I can
tell. I wonder if there are any other groups out there working on this.

As far as compliance standards go, as far as I can tell, the one
that most fits us might be ATIS -T1.IPNA -ISP data, but I'm still
confused about that. When I visit
http://www.askcalea.net/standards.html, I see a link for "Wireline:
PTSC T1.IAS" which takes me to
https://www.atis.org/docstore/product.aspx?id=22665. Is this all the
same as ATIS -T1.IPNA -ISP? Somehow I don't have the feeling that
paying $164.00 for this standard is going to help get me in the
right direction ....

We do have a couple savvy Linux guru-types in house that could
deploy a good open-source solution and keep it updated, I think. But
I don't think we're up to developing such a solution ourselves from scratch.

I did find a device made by a company called Solera

(http://www.voip-news.com/feature/solera-calea-voip-packet-capture-
031907/) which looks like it could be cost-effective (read:
~$7000.00) for a small ISP (read: ~1,000 customers) like us.
Obviously we would prefer open source, but at least it was a relief
to see that we might be able to avoid the $40,000 - $100,000
solutions I've been hearing about from TTP's and other
(larger) ISPs.

Matt Liotta, you mentioned that you "have the ability to provide
lawful intercept in compliance with CALEA for our single-homed
downstream ISP customers assuming there is no NAT involved." Would
you be willing to share some details about the solution you've been
able to come up with?

I do see the opportunity that this whole CALEA thing could provide
to some ISP's who figure out a way to develop a cost-effective
solution and then offer consulting services or **affordable** TTP
services to other companies ...

I also read with interest the "Baller law group's Key Legal and
Technical Requirements and Options for CALEA
(http://www.baller.com/pdfs/BHLG-CTC_CALEA_Memo.pdf)" that Peter
Radizeski forwarded to the list. I had not taken seriously the
possibility of filing a section 109(b) petition, but if we do due
diligence and really do not find an affordable solution to deploy on
our network, I think we may have to seriously consider that (for
example, the part about asking to be considered compliant as long as
we can meet most of LI's requirements, if not all of them).

Please excuse the long and rambling post ... I'm just having a hard
time finding out how to grab a hold of this CALEA beast.

Hi, let me quote from www.askcalea.com

"On March 17, 2004, we published a press release regarding our joint petition.

Q: Does the petition for CALEA rulemaking propose to apply CALEA to all types of online communication, including instant messaging and visits to websites?

A: No. The petition proposes CALEA coverage of only broadband Internet access
service and broadband telephony service. Other Internet-based services,
including those classified as "information services" such as email and visits
to websites, would not be covered.

Q: Does the petition propose extensive retooling of existing broadband
networks that could impose significant costs?

A: No. The petition contends that CALEA should apply to certain broadband
services but does not address the issue of what technical capabilities those broadband providers should deliver to law enforcement. CALEA already permits those service providers to fashion their own technical standards as they see fit. If law enforcement considers an industry technical standard deficient,
it can seek to change the standard only by filing a special "deficiency"
petition before the Commission. It is the FCC, not law enforcement, that
decides whether any capabilities should be added to the standard. The FCC may
refuse to order a change in a standard on many different grounds. For
example, a capability may be rejected because it is too costly. Therefore
CALEA already contains protections for industry against paying undue
compliance costs.

Q: Did law enforcement ask the FCC to curtail its usual review process to
implement the petition?

A: No. Law enforcement asked the FCC to give the proposed rulemaking
expedited treatment. Such treatment is often requested and granted when
urgent matters are brought to the FCC's attention. Some FCC rulemaking
proceedings can take years to complete. Law enforcement believes expedited
treatment is warranted in this case based on evidence that terrorists,
criminals, and/or spies are already exploiting the networks of broadband
communication providers to evade lawful electronic surveillance.

Q: Is Law enforcement trying to dictate how the Internet should be engineered
to permit whatever level of surveillance law enforcement deems necessary?

A: No. Law enforcement does not seek the power to dictate how the Internet
should be engineered or even to decide how broadband communications networks
should be engineered. As explained above, CALEA already allocates those
decisions to industry and any resulting capability disputes between industry
and law enforcement are decided by the FCC. Moreover, the level of
surveillance is not an issue raised in the petition, is not within the scope
of CALEA, and is not decided by law enforcement. Based on a statute known
as "Title III," before a law enforcement agent or officer is permitted to
engage in lawful electronic surveillance, he or she must seek an appropriate
court order from a judge or magistrate. Only if a judicial order is issued
can the lawful surveillance take place, and the level of surveillance is
prescribed by the order.

Q: Does the petition ignore the letter or spirit of CALEA's "information
services" exemption by seeking to apply CALEA to such services?

A: No. The petition notes that CALEA contains a definition
of "telecommunications carrier" that is different from and broader than the
definition of that term in the Communications Act, which governs most FCC
actions. The petition therefore asks the FCC to decide the scope of CALEA
coverage based on the CALEA definition, not the Communications Act
definition. As a result, some carriers classified as "information service"
providers for purposes of the Communications Act would be simultaneously
deemed "telecommunications carriers" for purposes of CALEA.

Q: Would the petition force carriers to decode data that might be encrypted?

A: No. The petition does not raise the issue of encryption. That issue is
already addressed by CALEA. The statute states that if encryption is provided
by a telecommunications carrier and the carrier possesses the information
necessary to decrypt the communication, it must decrypt the communications
subject to an order for lawful interception. But if the encryption is
provided by a subscriber or customer, the carrier is not responsible for
decrypting the targeted communications. "


What you read this...  It conflicts considerably with a lot of information
gathered in other places.

Read this carefully, it says that website visits, IM, etc, are NOT included in the information you must capture. Yeah, yeah, it says the companies that provide those services need not be compliant - if that's the case, then that
data is not included in the required types.  Only specific types of
information, mostly being VIOP calls are detailed.  Since VOIP calls are
tapped at the provider's end, it appears that really IS NO INCLUDED DATA that
needs to be tapped at the ISP's end, unless somehow we're supposed to find
peer to peer voice data buried in the packet flow or something.

Of course, this conflicts to some degree with other information published
elsewhere... and here, too.

I'm not sure it doesn't conflict with the FCC's and FBI's recent comments,
too.

What is definitely scary, is that it says that the level of intrusion or
actual availability of data from your network's operation is going to be
decided BY INDUSTRY.

Who the heck is that?

Me?

AT&T?  Earthlink?   AOL?

Disputes between providers and law enforcement will be mediated by the FCC,
it says.  So the FCC has placed itself as the mediator... the one who
decideds post facto what is required, and then can levy fines.  Talk about
being able to capriciously "nail" anyone they feel like!

The more I read this, the more we should be telling them this bit of
regulatory manture should be buried forever.



--------------------------------------------
Mark Koskenmaki  <> Neofast, Inc
Broadband for the Walla Walla Valley and Blue Mountains
541-969-8200

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

--
WISPA Wireless List: wireless@wispa.org

Subscribe/Unsubscribe:
http://lists.wispa.org/mailman/listinfo/wireless

Archives: http://lists.wispa.org/pipermail/wireless/

Reply via email to