ISP compliance < LEAs - tech and logistics [was: snfc21 sniffer docs]

Wired posted what are suppossedly the docs Mark Klein wrote 'bout the
NSA sniffing project. Interesting read...

http://blog.wired.com/27BStroke6/att_klein_wired.pdf

John

Indeed. To be honest, I am more interested in NANOG-related operational
issues involved, which I am not sure many here will be able to discuss in
case they had experience on the subject. So let us put privacy and legal
issues aside for the purpose of this discussion.

How does a service provider handle the requirement to meet a law
enforcement agency with their wiretapping needs? The logistics and
technology can be exerting, annoying and business-wise, even prohibiting.

As I just mentioned somewhere else, I should probably point out that if I
was a major ISP often asked to answer the call of law enforcement with
legal wiretaps, this could be very annoying as well as technologically
a killer to my network architecture.
Just sticking some hub somewhere in my network may not cut it, and will
certainly not cover all of the communication. What about different lines
and locations?

As a large provider, AT&T probably had to find better solutions to the
call of the law, or reply on the law's technology to not kill their
business.

This indeed happened before. As some of you may remember, according to one
NANOGer at the FBI's Carnivore presentation a few years ago, "sticking"
just such a hub is what caused his network to break-down.

Creating a centralized wiretapping point under strict security may be just
the thing to both comply and save costs, not to mention staying on the
air.

I don't see how that _by_itself_ is wrong of AT&T. There are other issues
here as well.

The Internet Infrastructure in a significant way sits in the US. We all
know that. Is it really a surprise to anyone that the NSA, which states it
listens to the Internet, is using a local resource such as that on US
soil? They would be crazy not to.

They rivals and enemies in other countries certainly won't think
twice.

There is the issue of separating domestic communication from the rest, but
that's just something they have to deal with and US citizens have to be
paranoid about. This whole situation will probably result in better
supervision/monitoring of activities rather than stopping any of them
(i.e. simply more people in-the-know of what the NSA is up to).

That said, I am not a US citizen nor up-to-date on the details of this
ATT/NSA issue or the privacy implications, and I am sure enough of the US
folks here are.

  Gadi.

See RFC 3924, "Cisco Architecture for Lawful Intercept in IP Networks."

In the US, see 18 USC 2518(4):

  Any provider of wire or electronic communication service,
  landlord, custodian or other person furnishing such facilities or
  technical assistance shall be compensated therefor by the
  applicant for reasonable expenses incurred in providing such
  facilities or assistance.

  --Steven M. Bellovin, http://www.cs.columbia.edu/~smb

The NANOG meeting archives are full of presentations as the result
of very sophisticated network monitoring. Like most technology,
it can be used for good and evil. You can't tell the motivation
just from the technology.

Sean, please drop this subject. You have no experience here and it's
annoying that you keep making authoritative claims like you have some
operational experience in this area. If you do, please do elaborate
and correct me. From what I understand from the folks at SBC, you
did not run harassing call, annoyance call, and LAES services. I would
appreciate a correction.

-M<

>The NANOG meeting archives are full of presentations as the result
>of very sophisticated network monitoring. Like most technology,
>it can be used for good and evil. You can't tell the motivation
>just from the technology.

OK, so he says in a roundabout way that you are
already paying for some sophisticated network monitoring
and it probably won't cost you much to just give
some data to the "authorities".

Sean, please drop this subject. You have no experience here and it's
annoying that you keep making authoritative claims like you have some
operational experience in this area. If you do, please do elaborate
and correct me. From what I understand from the folks at SBC, you
did not run harassing call, annoyance call, and LAES services. I would
appreciate a correction.

Huh!?!?!?
Are you saying that people should buzz off from
the NANOG list if they change jobs and their latest
position isn't operational enough? Are you saying that
people should not be on the NANOG list unless they
have TELEPHONY operational experience?

What is the world coming to!?

--Michael Dillon

The guy wants to say, please raise your eyes above the horizon of your
plate and view a not yet existing country named europe. Here our
infrastructure is a lot more advanced and we have standardized a
common eavesdropping api. That makes sense with shifting points of
view from IRA and Basque Separatists to the European Central Bank
everybody can use the standart API and start listening. Of course
nobody except the European Central Bank is allowed listening, but -
who cares?

I am told china too is very advanced. But I am shure North America
will catch up fast.

Or does he mean Operations, the IRA guys who are running the London
Docklands eavesdropping facility, that connects europe via the glc
fibre?

</ranting> <? remember where we started ???

Cheers
Peter and Karin

The guy wants to say, please raise your eyes above the horizon of your
plate and view a not yet existing country named europe. Here our
infrastructure is a lot more advanced and we have standardized a
common eavesdropping api.

We have? News to me.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

> The guy wants to say, please raise your eyes above the horizon of your
> plate and view a not yet existing country named europe. Here our
> infrastructure is a lot more advanced and we have standardized a
> common eavesdropping api.

We have? News to me.

You missed a line later in his message:

Of course
nobody except the European Central Bank is allowed listening, but -
who cares?

Sounds like typical lunatic ravings to me.
I guess anything goes on this list now...

--Michael Dillon

sthaug@nethelp.no wrote:

The guy wants to say, please raise your eyes above the horizon of your
plate and view a not yet existing country named europe. Here our
infrastructure is a lot more advanced and we have standardized a
common eavesdropping api.

We have? News to me.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Institut europ�en des normes de t�l�communication

>>The guy wants to say, please raise your eyes above the horizon of your
>>plate and view a not yet existing country named europe. Here our
>>infrastructure is a lot more advanced and we have standardized a
>>common eavesdropping api.
>
>
> We have? News to me.
>
> Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Institut européen des normes de télécommunication

Login Page

I see a list of documents. I see no sign that these documents are
standards, nor that they are actually *implemented*. I know for a fact
that the service provider I work for has not implemented this on the
IP side.

Steinar Haug, Nethelp consulting, sthaug@nethelp.no

Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard.

:wink:

Best regards,
Christian

> >The NANOG meeting archives are full of presentations as the result
> >of very sophisticated network monitoring. Like most technology,
> >it can be used for good and evil. You can't tell the motivation
> >just from the technology.

OK, so he says in a roundabout way that you are
already paying for some sophisticated network monitoring
and it probably won't cost you much to just give
some data to the "authorities".

> Sean, please drop this subject. You have no experience here and it's
> annoying that you keep making authoritative claims like you have some
> operational experience in this area. If you do, please do elaborate
> and correct me. From what I understand from the folks at SBC, you
> did not run harassing call, annoyance call, and LAES services. I would
> appreciate a correction.

Huh!?!?!?
Are you saying that people should buzz off from
the NANOG list if they change jobs and their latest
position isn't operational enough? Are you saying that
people should not be on the NANOG list unless they
have TELEPHONY operational experience?

What is the world coming to!?

[ rescued from the killfile ]

As far as archives being chock full of information,
Chip Sharp of Cisco made a factual presentation on CALEA years
back. The rest of the "discussion" has been mostly hyperbole. Emotional
fodder on political agendas instead of technical, operational,
or otherwise. I'd characterize 90% or more of it as junk. If I
want to read about politics, I can open my newspaper with my coffee
- and I do, but that's the extent I need to see it all day long.
We're already bombarded with this stuff elsewhere.

No, someone should not quit NANOG's list because they change jobs.
Changing jobs has nothing to do with it. Being a subject matter
expert is. It's arguable who the SME's here on the list are related
to CALEA. There aren't more than 2 or 3 and they aren't usually talking
about these types of posts. Not because there's a big secret to be kept.
There isn't. It's all public. It's because the thread will always turn
to politics and disinformation and it's a bad use of everyones time.

Perhaps a bit too harsh on the prior response, but the "quality" of
some of the posting here has become arguably low as of late. Maybe
it's because of too much rain? I don't know, but NTP, geo-location,
and CALEA have all been subject to this.

/me back to our regularly scheduled programming

Christian Kuhtz wrote:

I see a list of documents. I see no sign that these documents are
standards, nor that they are actually *implemented*. I know for a fact
that the service provider I work for has not implemented this on the
IP side.

French and german ISPs keep complaining about what it has cost them and
they keep informing us (customers) that it is on us to pay the bill.

I remember one german ISP who was helpful enough to mention the cost
for spying in his bill. It was a mistake and the money was refunded ...

Whenever mailservers are down here in germany somebody mentions the
delay is because all email is routed via the german gouvernement again :slight_smile:

Now, now, Steinar, we all know that cannot be true. Case and point, everyone has implemented RFC 3514, just because it has been published as a standard.

:wink:

Best regards,
Christian

I just tested my NAT-router and made shure it is RFC 3514 compliant.
Yes the NASTY bit is set :slight_smile:

Cheers
Peter and Karin

Actually, it's Informational rather than Standards Track. However, since
there were patches for both a *BSD variant and Linux, we can probably scare
up two interoperable implementations so we can move it along Standards Track. :slight_smile:

Now, now, Steinar, we all know that cannot be true. Case and point,
everyone has implemented RFC 3514, just because it has been published
as a standard.

Actually, it's Informational rather than Standards Track.

Nitpicky bugger, good grief. :wink: It's an RFC, therefore it is gospel. :wink:

However, since
there were patches for both a *BSD variant and Linux, we can probably scare
up two interoperable implementations so we can move it along Standards Track. :slight_smile:

Stop, Vladis, stop, you're scarying me.

:wink:

Except for routing protocols, you don't need running code for Proposed
Standard. But yes, I received several implementation reports. I was also
told that Junipers can almost do the filtering:

    Technically the CF does have the ability to see 'any bit in the
    first 21 bytes' of an IP packet... (I believe it's 21 bytes at
    least). The limitations on the software installed, however,
    keep you from doing the arbitrary bit field/offset business.

See http://www.cs.columbia.edu/~smb/3514.html -- and note that it already
mentions Lawful Intercept. Yes, it's all from real email

    --Steven M. Bellovin, http://www.cs.columbia.edu/~smb