CALEA

Martin Hannigan hannigan at gmail.com
Tue May 31 07:12:22 UTC 2016


Misfire. Sorry, early in the AM. The URL I intended to send is here:

    http://www.uscourts.gov/statistics-reports/wiretap-report-2014


Best,

-M<

On Tue, May 31, 2016 at 9:10 AM, Martin Hannigan <hannigan at gmail.com> wrote:
> CALEA isn't a type of request, it's a law that enabled par function
> access for LEO's e.g. "the ladder" pin register, trap+trace, DTMF
> translation, three-way/off hook ops and the call content (not
> necessarily in that order).
>
> You can see the non national security activity here:
>
>
> On Sat, May 28, 2016 at 5:37 AM, Mike Joseph <mj at doze.net> wrote:
>> I can say via firsthand knowledge that CALEA requests are definitely
>> happening and are not even that rare, proportional to a reasonably sized
>> subscriber-base.  It would be unlawful for me to comment specifically on
>> any actual CALEA requests, however.  But if you have general questions
>> about my observations, feel free to reach out directly.
>>
>> -MJ
>>
>> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel <bmengel at gmail.com> wrote:
>>
>>> My comments were strictly limited to my understanding of CALEA as it
>>> applied to ISPs, not telcos.  A request for a lawful intercept can entail
>>> mirroring a real time stream of all data sent to/from a customer's Internet
>>> connection (cable modem/DSL/dedicated Ethernet) to a LEA.  AFAIK this
>>> requires mediation before being sent to the LEA and it is the mediation
>>> server itself that initiates the intercept when so configured by the ISP.
>>> Perhaps some LEAs have undertaken the mediation function so as to
>>> facilitate these intercepts where the neither the ISP nor a third party can
>>> do so.  If that were the case then very little would be needed on the part
>>> of the ISP in order to comply with a request for lawful intercept.  I can
>>> say with certainty that these types of requests are being made of broadband
>>> ISPs though I agree that they are very rare.
>>>
>>> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam <jfbeam at gmail.com> wrote:
>>>
>>> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel <bmengel at gmail.com>
>>> > wrote:
>>> >
>>> > AFAIK being able to do a lawful intercept on a specific, named,
>>> >> individual's service has been a requirement for providers since 2007.
>>> >>
>>> >
>>> > It's been required for longer than that. The telco I worked for over a
>>> > decade ago didn't build the infrastructure until the FCC said they were
>>> > going to stop funding upgrades. That really got 'em movin'. (suddenly
>>> "data
>>> > services" people -- i.e. ME -- weren't redheaded stepchildren.)
>>> >
>>> > have never heard of a provider, big or small, being called out for being
>>> >> unable to provide this service when requested.
>>> >>
>>> >
>>> > Where existing infrastructure is not already in place (read:
>>> T1/BRI/etc.),
>>> > the telco can take up to 60 days to get that setup. I know more than one
>>> > telco that used that grace period to actually setup CALEA in the first
>>> > place.
>>> >
>>> > did not perform intercepts routinely.
>>> >>
>>> >
>>> > The historic published figures (i've not looked in years) suggest CALEA
>>> > requests are statistically rare. The NC based telco I worked for had
>>> never
>>> > received an order in the then ~40yr life of the company.
>>> >
>>> > The mediation server needed to "mediate" between your customer
>>> aggregation
>>> >> box and the LEA is not inexpensive.
>>> >>
>>> >
>>> > And also is not the telco's problem. Mediation is done by the LEA or 3rd
>>> > party under contract to any number of agencies. For example, a telco tap
>>> > order would mirror the control and voice traffic of a POTS line (T1/PRI
>>> > channel, etc.) into a BRI or specific T1 channel. (dialup was later
>>> added,
>>> > but wasn't required in my era, so we didn't support it.) We used to test
>>> > that by tapping a tech's phone. Not having any mediation software, all I
>>> > could do is "yeap, it's sending data" and listen to the voice channels
>>> on a
>>> > t-berd.
>>> >
>>> > --Ricky
>>> >
>>>
>>>



More information about the NANOG mailing list