Root Server Operators (Re: What *are* they smoking?) of "Wed, 17 Sep 2003 00:48:09 -0400." <[e-mail]>

[Paul Vixie]

> So, Verisign just returns a NS pointer to another name server Verisign
> controls which then answers the queries with Verisign's "helpful" web
> site.
>
> Half-life of the patch: 1 day?

i don't think so. verisign is on public record as saying that the reason
they implemented the wildcard was to enhance the services offered to the
internet's eyeball population, who has apparently been clamouring for this.

in this story, for example...

http://story.news.yahoo.com/news?tmpl=story&u=/ap/20030916/ap_on_hi_te/internet_typos_4

...it was thus spake:

VeriSign spokesman Brian O'Shaughnessy said Tuesday that individual
service providers were free to configure their systems so customers
would bypass Site Finder. But he questioned whether releasing a patch
to do so would violate Internet standards.

Vixie acknowledged that it could -- standards call for operators like
VeriSign to have complete control over their directories -- but he
said not releasing a patch would create greater chaos.

therefore i believe that while they may have to change the A RR from time to
time according to their transit contracts, verisign won't insert an NS RR
into the sitefinder redirection. if they do, and if bind's user community
still wants to avoid sitefinder, they can declare the second server "bogus",
with no new code changes from isc. but that all seems terribly unlikely.

[Sean Donelan]

On Wed, 17 Sep 2003, Paul Vixie wrote:
> > So, Verisign just returns a NS pointer to another name server Verisign
> > controls which then answers the queries with Verisign's "helpful" web
> > site.
> >
> > Half-life of the patch: 1 day?
>
> i don't think so. verisign is on public record as saying that the reason
> they implemented the wildcard was to enhance the services offered to the
> internet's eyeball population, who has apparently been clamouring for this.

Verisign is on public record as saying many things over the years.

Following Internet Standards and to improve performance for all Internet
users, what if Verisign decided to start including other A records
directly in the .COM/.NET zones?

For example, the A records for the servers for the .COM/.NET zones? Or
"interesting" sites that Verisign has a relationship with?

What would it do to website's Keynote performance to eliminate another
name lookup by having their www.something.com records served directly
from Verisign's gtld-servers?

Of course, ISC's non-standard BIND change will break Verisign's
attempt to "improve" the Internet's performance by including A records
in the .COM/.NET zones.


Verisign's lobbyists are 3,000 miles closer to Washington DC than
ISC's lobbyists. And history has demonstrated what Verisign lacks
in Internet clue, they make up for in Washington clue.


I wouldn't be surprised if tomorrow, Verisign is the playing the victim
and calling ISC the out-of-control hooligans.

[John Brown]

On Wed, Sep 17, 2003 at 01:39:56AM -0400, Sean Donelan wrote:
>
> I wouldn't be surprised if tomorrow, Verisign is the playing the victim
> and calling ISC the out-of-control hooligans.

Paul an out of control hooligan, say it isn't so ! :)

Actually I'd trust ISC/Vixie/ to always do the real
right thing when it comes to root-ops and global DNS.

and I'd trust the Verisign people that run A and J to
do reasonable things with those boxes. They are good
people, when they wear those hats.

I'd almost never trust Verisign to do whats right for
the public / internet when it comes to dealing with
.COM, .NET and such. Thats their cash cow and they
will milk it for all its worth, and then some.

speaking as a shareholder of Verisign, I'm NOT HAPPY
with the way they handled this wildcard deal, nor
am I happy about them doing it all. As a *shareholder*
I'd cast my vote that they *remove* it.

[Vadim Antonov]

On Wed, 17 Sep 2003, John Brown wrote:

> speaking as a shareholder of Verisign, I'm NOT HAPPY
> with the way they handled this wildcard deal, nor
> am I happy about them doing it all. As a *shareholder*
> I'd cast my vote that they *remove* it.

You have no control over operations of the company. However, you may vote
Verisign officers out of the office... if you can get other shareholders
to see the benefits of giving business ethics preference over short-term
profits.

--vadim

[Paul Vixie]

> Following Internet Standards and to improve performance for all Internet
> users, what if Verisign decided to start including other A records
> directly in the .COM/.NET zones?
>
> For example, the A records for the servers for the .COM/.NET zones?

funnily enough, that would work fine, since it would be in-zone glue, and
would arrive in referrals, rather than arriving in answers. the zone would
still be "delegation-only" according to the functionality we're releasing.

> Or "interesting" sites that Verisign has a relationship with?

that would not work very well for a recursive server who had declared com
or net to be delegation-only.

> I wouldn't be surprised if tomorrow, Verisign is the playing the victim
> and calling ISC the out-of-control hooligans.

that's doubtful. i've seen people here today advocate "wet teams", null
routing, patches that hard coded A RR values, cutting off uncooperative
root name server operators from internet connectivity, and even writing
letters to congress. isc's actions are at best a minor sideshow here.

the question you should be asking yourselves is, what will aol and uSoft
do? will microsoft add "delegation-only" features to its recursive dns
implemenation? will aol or msn enable this in the recursive servers that
face their customers? i guess what i'm trying to say is, the folks who
are complaining about this wildcard on nanog, are not the ones verisign
was probably hoping would buy stuff. "these aren't the eyeballs you're
looking for." the real action is occuring somewhere else entirely.

[Andy Dills]

On Wed, 17 Sep 2003, Paul Vixie wrote:

> i don't think so. verisign is on public record as saying that the reason
> they implemented the wildcard was to enhance the services offered to the
> internet's eyeball population, who has apparently been clamouring for this.

My question is, if this was to serve some need of internet users, why does
port 25 work and not port 80?


So, I'm curious as to your opinion about the bigger issue. Maybe it has
been stated somewhere else, and if it has, please direct me to it. I've
read all of your posts about this on nanog, and you do an excellent job of
staying neutral. You point out that what Verisign is doing is technically
valid and therefore shouldn't be addressed with a technical "solution",
but you also release a patch for Bind to accomodate obvious demand (and to
save users the hassle of implementing half-assed patches with hardcoded A
records). However, you do so without actually stating whether or not you
think the wildcards are a (policy) problem or not.

You point out that there is high-level ambiguity about the relationship
between DOC, ICANN, and Verisign, and about whether or not Verisign should
have the public's interest in mind. Do you think they should have the
public's interest in mind? And do you think the wildcards are in the
public's interest?

I can certainly empathize with wanting to stay neutral, but I think we
need somebody who carries substantial influence in the name resolution
community to have strong opinions about such a poor policy decision.

Andy

---
Andy Dills
Xecunet, Inc.
www.xecu.net
301-682-9972
---

[Paul Vixie]

> Is it possible for the client resolver code to distinguish between a
> wildcard answer and an explicit answer?

no.

> If this was available, it would mail clients and other things
> interested in the specific domain name could get the answers they
> want. While other stuff would get the wildcard answers.

right.

[Sean Donelan]

What happens when Verisigns monopoly registry agreement for .COM and .NET
expires on November 10 2007?

http://www.icann.org/tlds/agreements/verisign/com-index.htm


According to the contract signed between ICANN and Verisign, Zone File
Data is defined as

13. "Zone File Data" means all data contained in DNS zone files for the
Registry TLD, or for any subdomain for which Registry Services are
provided and that contains Registered Names, as provided to TLD
nameservers on the Internet.


A "wildcard" name does not meet the definition of Registered Name in
the Verisign/ICANN contract.

6. "Registered Name" refers to a domain name within the domain of the
Registry TLD, whether consisting of two or more (e.g., john.smith.name)
levels, about which Registry Operator or an affiliate engaged in
providing Registry Services maintains data in a Registry Database,
arranges for such maintenance, or derives revenue from such
maintenance. A name in a Registry Database may be a Registered Name
even though it does not appear in a TLD zone file (e.g., a registered
but inactive name).

Because "wildcard" names are not Registered Names, Verisign appears
to be in breach of their contract with ICANN by including them in the
Zone File Data.

ICANN can seek specific performance of the agreement by Verisign, or
seek to terminate Verisign's contract as the .COM/.NET registry operator
and transfer the operation to a successor registry.

IANAL, ICANN and Verisign should seek the advice of their own legal
advisors.

[Paul Vixie]

> > ICANN can seek specific performance of the agreement by Verisign, or
> > seek to terminate Verisign's contract as the .COM/.NET registry operator
> > and transfer the operation to a successor registry.
>
> Quiet honestly I'd like to see all of the GTLD servers given to neutral
> companies, ones that ARE not registrars. [...]

frankly i am mystified as to why icann awards registry contracts to
for-profit entities. registrars can be for-profit, but registries should
be non-profit or public-trust or whatever that specific nation's laws allow
for in terms of requirements for open accounting, uniform dealing, and
nonconflict with the public's interest.
--
Paul Vixie

[Henry Linneweh]

My view would concur with this, these are really old battles starting back in the
netsol days and now the verisign has taken the same short sighted path.

It is time that neutral party is in charge
-Henry R Linneweh

Paul Vixie <***@vix.com> wrote:

> > ICANN can seek specific performance of the agreement by Verisign, or
> > seek to terminate Verisign's contract as the .COM/.NET registry operator
> > and transfer the operation to a successor registry.
>
> Quiet honestly I'd like to see all of the GTLD servers given to neutral
> companies, ones that ARE not registrars. [...]

frankly i am mystified as to why icann awards registry contracts to
for-profit entities. registrars can be for-profit, but registries should
be non-profit or public-trust or whatever that specific nation's laws allow
for in terms of requirements for open accounting, uniform dealing, and
nonconflict with the public's interest.
--
Paul Vixie

[Jared Mauch]

On Sat, Sep 20, 2003 at 11:23:04PM -0700, Henry Linneweh wrote:
> My view would concur with this, these are really old battles starting back in the
> netsol days and now the verisign has taken the same short sighted path.
>
> It is time that neutral party is in charge
> -Henry R Linneweh

I was thinking this earlier this week.

This is a public-trust that should be operated by people
whose sole job is to keep it up and working, not by a dual-role
entity as it is today.

Perhaps we can get someone to make a not-for-profit
for this sole role.

- Jared

> Paul Vixie <***@vix.com> wrote:
>
> > > ICANN can seek specific performance of the agreement by Verisign, or
> > > seek to terminate Verisign's contract as the .COM/.NET registry operator
> > > and transfer the operation to a successor registry.
> >
> > Quiet honestly I'd like to see all of the GTLD servers given to neutral
> > companies, ones that ARE not registrars. [...]
>
> frankly i am mystified as to why icann awards registry contracts to
> for-profit entities. registrars can be for-profit, but registries should
> be non-profit or public-trust or whatever that specific nation's laws allow
> for in terms of requirements for open accounting, uniform dealing, and
> nonconflict with the public's interest.
> --
> Paul Vixie
--
Jared Mauch | pgp key available via finger from ***@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only mine.

[Brian Bruns]

----- Original Message -----
From: "Robert Blayzor" <***@inoc.net>
To: "Sean Donelan" <***@donelan.com>; <***@merit.edu>
Sent: Saturday, September 20, 2003 5:01 PM
Subject: Re: When is Verisign's registry contract up for renewal


> Quiet honestly I'd like to see all of the GTLD servers given to neutral
> companies, ones that ARE not registrars. Verisign is already engaging in
a
> lot of unfair business practices because they hold the GTLD servers for
> net/com. The wildcard SNAFU is just one of their tactics to patch the
> financial hole since people have been switching registrars in droves.


I've had long discussions with my admin team at the SOSDG on what would be
the best way to prevent stuff like this from happening in the future. We
came to the following conclusion:

* Root servers or any critical DNS servers should not be in the control of
companies. It should be handed over to Non-profit/not-for-profit orgs who
will not be tempted to do the things Verisign has done. We feel
completely comfortable with the root servers being in control of a group
like the ISC or even govt. agencies like NASA.

There is too much at stake here for people to be playing games with TLDs,
especially ones as important as .com and .net.

--------------------------
Brian Bruns
The Summit Open Source Development Group
Open Solutions For A Closed World / Anti-Spam Resources
http://www.2mbit.com
ICQ: 8077511

[Robert Blayzor]

On 9/20/03 6:09 PM, "Brian Bruns" <***@2mbit.com> wrote:

> * Root servers or any critical DNS servers should not be in the control of
> companies. It should be handed over to Non-profit/not-for-profit orgs who
> will not be tempted to do the things Verisign has done. We feel
> completely comfortable with the root servers being in control of a group
> like the ISC or even govt. agencies like NASA.

Of course. Putting trust into big money corporations; look where that got
us. (Hi Worldcom, Enron, Tyco, etc.) They have no respect for public
interest, just the bottom line.. Hell and some don't even care about that.

I don't believe in any one organization running the GTLD servers either. I
believe giving it to two or three would be good. That way if one seems to
do something seemingly stupid, we can effectively negate the perps and move
on.

There are lots of good organizations that can handle (and would be proud to
handle) the GTLD servers. I don't know if I'd throw NASA in that group.
(or any government agency for that matter)

--
Robert Blayzor, BOFH
INOC, LLC
***@inoc.net
PGP: http://www.inoc.net/~dev/
Key fingerprint = A445 7D1E 3D4F A4EF 6875 21BB 1BAA 10FE 5748 CFE9

Supercomputer: Turns CPU-bound problem into I/O-bound problem. - Ken
Batcher

[Mike Damm]

This sort of not-for-profit is exactly what I proposed when the VeriSign
discussion started. A non-technical response to a non-technical problem.
Since my inital email, I've recruited a few other NANOG folks and put up a
website: www.alt-servers.org.

-Mike

(Please excuse any formatting oddities, sent via OWA)

-----Original Message-----
From: Jared Mauch
To: Henry Linneweh
Cc: Paul Vixie; ***@merit.edu
Sent: 9/21/2003 12:28 AM
Subject: Re: When is Verisign's registry contract up for renewal


On Sat, Sep 20, 2003 at 11:23:04PM -0700, Henry Linneweh wrote:
> My view would concur with this, these are really old battles starting
back in the
> netsol days and now the verisign has taken the same short sighted
path.
>
> It is time that neutral party is in charge
> -Henry R Linneweh

I was thinking this earlier this week.

This is a public-trust that should be operated by people
whose sole job is to keep it up and working, not by a dual-role
entity as it is today.

Perhaps we can get someone to make a not-for-profit
for this sole role.

- Jared

> Paul Vixie <***@vix.com> wrote:
>
> > > ICANN can seek specific performance of the agreement by Verisign,
or
> > > seek to terminate Verisign's contract as the .COM/.NET registry
operator
> > > and transfer the operation to a successor registry.
> >
> > Quiet honestly I'd like to see all of the GTLD servers given to
neutral
> > companies, ones that ARE not registrars. [...]
>
> frankly i am mystified as to why icann awards registry contracts to
> for-profit entities. registrars can be for-profit, but registries
should
> be non-profit or public-trust or whatever that specific nation's laws
allow
> for in terms of requirements for open accounting, uniform dealing, and
> nonconflict with the public's interest.
> --
> Paul Vixie
--
Jared Mauch | pgp key available via finger from ***@puck.nether.net
clue++; | http://puck.nether.net/~jared/ My statements are only
mine.

[Paul Vixie]

> This sort of not-for-profit is exactly what I proposed when the VeriSign
> discussion started. A non-technical response to a non-technical problem.
> Since my inital email, I've recruited a few other NANOG folks and put up a
> website: www.alt-servers.org.

what a BAD idea. worse than anything else on the table or in existence today.
--
Paul Vixie

[Haesu]

A lot of people try the alternative root servers since their existance. And I have yet to see one that really worked to convince majority of internet to find it authoritative...

alt-servers seems to be emotional response to the problem. No matter how hard you try, I doubt even 20% of all ISP's on the internet will use it :(

-hc

--
Haesu C.
TowardEX Technologies, Inc.
Consulting, colocation, web hosting, network design and implementation
http://www.towardex.com | ***@towardex.com
Cell: [phone] | Office: [phone] Ext. 174
Fax: [phone] | POC: HAESU-ARIN

On Sun, Sep 21, 2003 at 07:37:03PM +0000, Paul Vixie wrote:
>
> > This sort of not-for-profit is exactly what I proposed when the VeriSign
> > discussion started. A non-technical response to a non-technical problem.
> > Since my inital email, I've recruited a few other NANOG folks and put up a
> > website: www.alt-servers.org.
>
> what a BAD idea. worse than anything else on the table or in existence today.
> --
> Paul Vixie

[John Palmer (NANOG Acct)]

That may soon change. Seeing as how bad things are getting with VRSGN and ICANN
resources are being lined up to solve this problem once and for all.
----- Original Message -----
From: "Haesu" <***@towardex.com>
To: "Paul Vixie" <***@vix.com>; <***@merit.edu>
Sent: Sunday, September 21, 2003 3:33 PM
Subject: Re: When is Verisign's registry contract up for renewal


>
> A lot of people try the alternative root servers since their existance. And I have yet to see one that really worked to convince
majority of internet to find it authoritative...
>
> alt-servers seems to be emotional response to the problem. No matter how hard you try, I doubt even 20% of all ISP's on the
internet will use it :(
>
> -hc
>
> --
> Haesu C.
> TowardEX Technologies, Inc.
> Consulting, colocation, web hosting, network design and implementation
> http://www.towardex.com | ***@towardex.com
> Cell: [phone] | Office: [phone] Ext. 174
> Fax: [phone] | POC: HAESU-ARIN
>
> On Sun, Sep 21, 2003 at 07:37:03PM +0000, Paul Vixie wrote:
> >
> > > This sort of not-for-profit is exactly what I proposed when the VeriSign
> > > discussion started. A non-technical response to a non-technical problem.
> > > Since my inital email, I've recruited a few other NANOG folks and put up a
> > > website: www.alt-servers.org.
> >
> > what a BAD idea. worse than anything else on the table or in existence today.
> > --
> > Paul Vixie
>
>
>

[Andy Walden]

On Sun, 21 Sep 2003, Paul Vixie wrote:

>
> > This sort of not-for-profit is exactly what I proposed when the VeriSign
> > discussion started. A non-technical response to a non-technical problem.
> > Since my inital email, I've recruited a few other NANOG folks and put up a
> > website: www.alt-servers.org.
>
> what a BAD idea. worse than anything else on the table or in existence today.

Splitting the root you mean? I'm not sure there was enough info on that
site to come to any other conclusion, but I wanted to make sure.

andy
--
PGP Key Available at http://www.tigerteam.net/andy/pgp

[Paul Vixie]

> How should an ISP tell the difference between "good" DNS packets and "bad"
> DNS packets?

the bad ones are the ones people complain about.

> You aren't complaining about your dynamic update packets or even all
> dynamic updates. You are complaining about someone sending you packets
> you don't want. And more precisely, you are complaining that Comcast is
> failing to send you other packets you want to receive, i.e. a response to
> your e-mail packets.

yup. where "packets i do not want" could as easily be ddos ("zwil") or spam.

> I've been thinking how to use ICMP to signal different types of
> responses; and even how "smart" edges on both ends of a communication
> could establish and enforce policies. Most of these are non-malicious
> communications involving misconfigured systems. Edge communications
> avoids problems with the host system, but has problems with multi-path
> communications and source validation.

the whole end-to-end argument depends on uniform clue distribution for scale.

[Sean Donelan]

On Sun, 28 Sep 2003, Paul Vixie wrote:
> > I've been thinking how to use ICMP to signal different types of
> > responses; and even how "smart" edges on both ends of a communication
> > could establish and enforce policies. Most of these are non-malicious
> > communications involving misconfigured systems. Edge communications
> > avoids problems with the host system, but has problems with multi-path
> > communications and source validation.
>
> the whole end-to-end argument depends on uniform clue distribution for scale.

The current method of complaining to an ISP doesn't scale very well
either. As you observed in your previous message, supporting 10,000
or ten million customers has many poor scaling properties. Especialy
if you have to fix issues on a case-by-case basis.

Getting vendors to supply more appropriate defaults offers better
scaling possibilities. Your complaint might fix one user's computer,
Microsoft updating the default behaivor would fix tens of millions
of users' computers. Which scales better?

If software didn't do dumb things by default, we wouldn't have to fix the
software one customer at a time. If BIND, ISC DHCP and Windows shipped by
default with "safe" settings, and did a better job of telling the person
who can fix the problem that there is a problem, would there be fewer
problems?

How can a Windows system have a fatal error every hour for days and
months, and the user not be aware of it until someone else calls them?

If Dynamic DNS Update is so critical that Microsoft feels the need to
enable it by default, why doesn't Microsoft pop an error dialog window
on the user's machine every time it fails? Then the user could decide
to fix the problem, or stop doing it. If the user doesn't know there
is a problem, why should he fix it?

[Paul Vixie]

> > the whole end-to-end argument depends on uniform clue distribution
> > for scale.
> ...
> Getting vendors to supply more appropriate defaults offers better
> scaling possibilities. Your complaint might fix one user's computer,
> Microsoft updating the default behaivor would fix tens of millions
> of users' computers. Which scales better?

you've got a real mad on about software monopolies, and i guess i ought
to join you since on any other day i'm just as worried. (the fact that
dan geer lost his job over this issue makes it even more painful.) but
in this case microsoft's culpability is toward their user, whereas the
isp's culpability is toward me, so there are two "culpability segments"
in the path, and i can't really complain to microsoft about these updates
even if, as you point out, they are the ones who would find fixing it
easiest, among all involved parties.

> How can a Windows system have a fatal error every hour for days and
> months, and the user not be aware of it until someone else calls them?

from microsoft's point of view, the failure in that case is that they
are not monetizing a condition which is very common amongst their users.
MSN has the ability to sell domain names. windows has the ability to
tell that a microsoft customer does not have a domain name, or does not
own the one they are pretending to be in, or whatever. microsoft should
not be waiting on complaints, nor should they have to feel any remorse
before they fix this. the verb they should be considering is "monetize".

> If Dynamic DNS Update is so critical that Microsoft feels the need to
> enable it by default, why doesn't Microsoft pop an error dialog window
> on the user's machine every time it fails? Then the user could decide
> to fix the problem, or stop doing it. If the user doesn't know there
> is a problem, why should he fix it?

that's an excellent question, especially since it could have a "click here
to send microsoft more of your money" button. but no matter how good an
idea it is, my complaint is still that sending e-mail toward the whois
contact for a network or AS# should elicit a clueful reply, and if it
doesn't, then the key word we're looking for is "cost shifting". (and
that, in case y'all wondered, is why this is relevant to ***@.)

[Owen DeLong]

--On Monday, September 29, 2003 2:44 AM +0000 Paul Vixie <***@vix.com>
wrote:

>
>> > the whole end-to-end argument depends on uniform clue distribution
>> > for scale.
>> ...
>> Getting vendors to supply more appropriate defaults offers better
>> scaling possibilities. Your complaint might fix one user's computer,
>> Microsoft updating the default behaivor would fix tens of millions
>> of users' computers. Which scales better?
>
> you've got a real mad on about software monopolies, and i guess i ought
> to join you since on any other day i'm just as worried. (the fact that
> dan geer lost his job over this issue makes it even more painful.) but
> in this case microsoft's culpability is toward their user, whereas the
> isp's culpability is toward me, so there are two "culpability segments"
> in the path, and i can't really complain to microsoft about these updates
> even if, as you point out, they are the ones who would find fixing it
> easiest, among all involved parties.
>
Paul,
IANAL, but, I believe you could sue Micr0$0ft under current
product liability laws, just as if their exploding pinto had hit you
on the freeway and blown up in your face. I believe that if lots of
Micr0$0ft victims would do this, making Micr0$0ft play legal whack-a-mole,
it would have an impact. Even if most or all of the law-suits didn't
win, it would create a cost to Micr0$0ft for not fixing things.

>> How can a Windows system have a fatal error every hour for days and
>> months, and the user not be aware of it until someone else calls them?
>
Because most Windows users have become so conditioned to accepting failures
in the software that they just push the big red button again and move on.
If it fails after three reboots, they either call their IT help desk or
get a cup of coffee and hope it's better when they get back.


Owen

[Kevin Oberman]

> Date: Mon, 9 Feb 2004 12:41:26 -0500 (EST
> From: Sean Donelan <***@donelan.com
> Sender: owner-***@merit.ed
>
>
> On Mon, 9 Feb 2004, John Payne wrote
> > --On Sunday, February 8, 2004 10:46 PM +0000 Paul Vixie <***@vix.com
> > wrote
> > > There is nothing wrong with a user who thinks they should not have to kno
> > > how to protect their computer from virus infections
> > However, someone attending NANOG should at least have cleaned up slamme
> > before connecting to the wireless..
>
> I have never seen any evidence that security experts or network operator
> are any better at practicing security than any other user group. In ever
> forum I've been at, the infection rates have been similar regardless o
> the attendees security experience
>
> Sometimes the attendees know about the issue, but do not have the powe
> to fix it, e.g. corporate IT deparment controls the laptop they ar
> required to use. Other times, they are oblivious to the equipment bein
> infected
>
> I wouldn't be surprised if I went to a meeting at the Department o
> Homeland Security or NSA, their infection rates are similar

At a recent large (last 6 months) trade show, the show network saw
bunch infected systems pop up at once. The problem was tracked (fairl
quickly) to machines brought up by a vendor in their booth that lacked
number of recent Microsoft Windows Critical Updates. I can't say who th
vendor was, but they REALLY should have been the FIRST to install an
patches

If this happens, what hope do we have for "normal" users
--
R. Kevin Oberman, Network Enginee
Energy Sciences Network (ESnet
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab
E-mail: ***@es.net Phone: [phone]

[d***@nanog.con.com]

In their defense, Microsoft hired a convention specialist to handle thei
booth. That company in turned hired some random integrator to supply an
configure the Windows machines

Dou


On Mon, 9 Feb 2004, Kevin Oberman wrote


> > Date: Mon, 9 Feb 2004 12:41:26 -0500 (EST
> > From: Sean Donelan <***@donelan.com
> > Sender: owner-***@merit.ed
>
>
> > On Mon, 9 Feb 2004, John Payne wrote
> > > --On Sunday, February 8, 2004 10:46 PM +0000 Paul Vixie <***@vix.com
> > > wrote
> > > > There is nothing wrong with a user who thinks they should not have to kno
> > > > how to protect their computer from virus infections
> > > However, someone attending NANOG should at least have cleaned up slamme
> > > before connecting to the wireless..
>
> > I have never seen any evidence that security experts or network operator
> > are any better at practicing security than any other user group. In ever
> > forum I've been at, the infection rates have been similar regardless o
> > the attendees security experience
>
> > Sometimes the attendees know about the issue, but do not have the powe
> > to fix it, e.g. corporate IT deparment controls the laptop they ar
> > required to use. Other times, they are oblivious to the equipment bein
> > infected
>
> > I wouldn't be surprised if I went to a meeting at the Department o
> > Homeland Security or NSA, their infection rates are similar

> At a recent large (last 6 months) trade show, the show network saw
> bunch infected systems pop up at once. The problem was tracked (fairl
> quickly) to machines brought up by a vendor in their booth that lacked
> number of recent Microsoft Windows Critical Updates. I can't say who th
> vendor was, but they REALLY should have been the FIRST to install an
> patches

> If this happens, what hope do we have for "normal" users
> -
> R. Kevin Oberman, Network Enginee
> Energy Sciences Network (ESnet
> Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab
> E-mail: ***@es.net Phone: [phone]

[Paul Vixie]

> After all these years, perhaps its time to re-examine the assumptions

it's always fun and useful to re-example assumptions. for example, anyon
who assumes that because the attacks they happen to see, or the attack
they hear about lately, don't use spoofed source addresses -- that spoofin
is no longer a problem, needs to re-examine that assumption

for one thing, spoofed sources could be occurring outside local viewing

for another thing, spoofed sources could be "plan B" when other attack
aren't effective

the last thing is, this is war. information warfare. the enemy knows u
better than we know them, and their cost of failure is drastically lowe
than our cost of failure

don't be lulled into some kind of false sense of security by the fac
that YOU are not seeing spoofed packets TODAY. let's close the doors w
CAN close, and give attackers fewer options

[Dan Hollis]

On Sun, 7 Mar 2004, Paul Vixie wrote
> don't be lulled into some kind of false sense of security by the fac
> that YOU are not seeing spoofed packets TODAY. let's close the doors w
> CAN close, and give attackers fewer options

sadly the prevailing thought seems to be 'we cant block every exploit so
we will block none'. this (and others) are used as an excuse to not deploy
urpf on edge interfaces facing singlehomed customers

its a fatalistic approach to dealing with network abuse, and its retarded

-Da

[Sean Donelan]

On Sat, 6 Mar 2004, Dan Hollis wrote
> sadly the prevailing thought seems to be 'we cant block every exploit s
> we will block none'. this (and others) are used as an excuse to not deplo
> urpf on edge interfaces facing singlehomed customers

This is one of the few locations SAV/uRPF consistently works. SAV/uRPF i
widely (but not 100%) deployed int those location. However I think yo
are mis-stating the issue. I do not know of anyone that has stated you
reason as the reason not to deploy SAV/uRPF on non-routing interfaces
The issue which prompt this thread was deploying uRPF on multi-pat
backbone interfaces using active routing

How many exploits does uRPF block

Biometric smart cards may do wonders for credit card fraud. Why don'
credit card companies replace all existing cards with them

Does uRPF solve more problems than it causes, and saves more than i
costs

[Paul Vixie]

***@donelan.com (Sean Donelan) writes

> How many exploits does uRPF block

that's hard to measure since we end up not receiving those. but one ca
assume that spoofed-source attacks aren't tried, either because (1) it'
easier to just use a high number of windows-xp drones, or because of (2
uRPF deployment

> Does uRPF solve more problems than it causes, and saves more than it costs

until you know what percentage of the attacks you don't see is due to (1
vs (2) above, you can't really pose that question meaningfully. anytim
there's a way to protect against a whole class of attack weapons, we hav
to deploy it. this is war, information warfare. let's deprive the enem
of options until we can force them to meet us on our own chosen terms
--
Paul Vixi

[Sean Donelan]

On Sun, 7 Mar 2004, Paul Vixie wrote
> don't be lulled into some kind of false sense of security by the fac
> that YOU are not seeing spoofed packets TODAY. let's close the doors w
> CAN close, and give attackers fewer options

I don't have a false sense of security. We have lots of open doors an
windows and even missing walls. Let's close the doors we can close, bu
buying screen doors for igloos may not be the best use of resources. uRP
doesn't actually prevent any attacks

Would you rather ISPs spend money t
1. Deploying S-BGP
2. Deploying uRPF
3. Respond to incident reports

[Laurence F. Sheldon, Jr.]

Sean Donelan wrote

> Would you rather ISPs spend money t
> 1. Deploying S-BGP
> 2. Deploying uRPF
> 3. Respond to incident reports

Why are we limited to that set

[E.B. Dreger]

SD> Date: Sat, 6 Mar 2004 22:04:58 -0500 (EST
SD> From: Sean Donela

SD> Would you rather ISPs spend money t
SD> 1. Deploying S-BGP
SD> 2. Deploying uRPF
SD> 3. Respond to incident reports

Let's look at the big picture instead of a taking a shallow mute
approach

If SAV were universal (ha ha ha!), one could discount spoofe
traffic when analyzing flows. But, hey, why bother playing nic
and helping other networks, eh

Am I the only one who's had IWFs -- even legitimate entities -
complain about packets "from your network" that weren't? I
certainly would have been nice if $other_networks had used SAV

SAV doesn't take long to implement. Considering the time spen
discounting spoofing when responding to incidents, I think ther
would be a _net_ savings (no pun intended) in time spen
responding to incidents

Alas, that requires cooperation and doesn't provide instantaneou
gratification. If it doesn't make/save a quick buck, why bother

Detection of sarcasm is left as an exercise to the reader

Edd
-
EverQuick Internet - http://www.everquick.net
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com
Bandwidth, consulting, e-commerce, hosting, and network buildin
Phone: [phone] Lawrence and [inter]nationa
Phone: [phone] Wichit
________________________________________________________________
DO NOT send mail to the following addresses
***@brics.com -or- ***@intc.net -or- ***@intc.ne
Sending mail to spambait addresses is a great way to get blocked

[Sean Donelan]

On Sun, 7 Mar 2004, E.B. Dreger wrote
> If SAV were universal (ha ha ha!), one could discount spoofe
> traffic when analyzing flows. But, hey, why bother playing nic
> and helping other networks, eh

SAV doesn't tell you where the packets came from. At best SAV tells yo
where the packets didn't come from

> Am I the only one who's had IWFs -- even legitimate entities -
> complain about packets "from your network" that weren't? I
> certainly would have been nice if $other_networks had used SAV

You still need to spend the same amount of time tracing the flows becaus
you can't tell from the packet itself if something went wrong with SAV
Even if everyone said they did SAV (and meant it), things like uRPF rel
on a number of things to work correctly. If any of those break or aren'
secure, you still can't rely on the source address being accurate

Even if you deployed SAV/uRPF on 100% of your network, you probabl
wouldn't want to tell people about it due to the idiots with firewalls

> SAV doesn't take long to implement. Considering the time spen
> discounting spoofing when responding to incidents, I think ther
> would be a _net_ savings (no pun intended) in time spen
> responding to incidents

You would be wrong. There are networks that have deployed SAV/uRPF

They saw no _net_ savings

In the real world, it costs more to deploy and maintain SAV/uRPF

Have you noticed this thread is full of people who don't run larg
networks saying other people who do run networks should deploy SAV/uRPF

But there hasn't been anyone who does run large networks saying the
deployed SAV/uRPF and it saved them money, made their network run bette
or improved the world

[Paul Vixie]

***@donelan.com (Sean Donelan) writes

> SAV doesn't tell you where the packets came from. At best SAV tells yo
> where the packets didn't come from

...which is incredibly more valuable than not knowing anything at all

> You would be wrong. There are networks that have deployed SAV/uRPF
>
> They saw no _net_ savings
>
> In the real world, it costs more to deploy and maintain SAV/uRPF

in the therefore-unreal world i live in, the ability to tell a GWF ("goobe
with firewall") that the incident report they sent our noc could not possibl
have come from here, is a net cost savings over having to prove it every time

> Have you noticed this thread is full of people who don't run larg
> networks saying other people who do run networks should deploy SAV/uRPF

distinguishingly, i do help run a network, and i'm not limiting my accusatio
("you guys are slackers") to uPRF-free networks of any particular size ("big")
--
Paul Vixi

[Sean Donelan]

On Sun, 7 Mar 2004, Paul Vixie wrote
> in the therefore-unreal world i live in, the ability to tell a GWF ("goobe
> with firewall") that the incident report they sent our noc could not possibl
> have come from here, is a net cost savings over having to prove it every time

Of course, some people claim large networks say that anyway so there i
not net cost savings :-

In practice, GWF's do not send reports to noc's about packets which coul
not have possibly have come from here. They send reports about packet
which have our IP addresses, but didn't originate here. The last thin
you want to admit is you do SAV because GWF think SAV means every packe
with that source address must have originated here

Whether or not we do SAV or everyone else does SAV, it doesn't save an
time validating if a packet stream originated here. Did the packe
actually originate here, or did SAV fail somewhere and it originate
somewhere else

Dear NOC, 192.5.5.241 is attacking me. Prove it isn't. Rinse, Lather
Repeat. Maybe you got hacked in the last 5 seconds, and now you reall
are attacking them

[Sean Donelan]

On Sat, 6 Mar 2004, Laurence F. Sheldon, Jr. wrote
> > Would you rather ISPs spend money t
> > 1. Deploying S-BGP
> > 2. Deploying uRPF
> > 3. Respond to incident reports

> Why are we limited to that set

You are not limited to any particular set. However you are limited. N
one has infinite resources. Pick and choose the things you do, and yo
will discover you still do not do everything everyone wants

Create your own list of things to spend money on. Was uRPF high enoug
on your list before you ran out of money? Why did you choose to spen
money on other security projets instead of uRPF, or the opposite why di
you choose to spend money on uRPF instead of other things which would hav
improved security

[Paul Vixie]

> ..
> buying screen doors for igloos may not be the best use of resources. uRP
> doesn't actually prevent any attacks

actually, it would. universal uRPF would stop some attacks, and it woul
remove a "plan B" option for some attack-flowcharts. i would *much* rathe
play defense without facing this latent weapon available to the offense

> Would you rather ISPs spend money t
> 1. Deploying S-BGP
> 2. Deploying uRPF
> 3. Respond to incident reports

"yes.

and i can remember being sick and tired of competing (on price, no less
against providers who couldn't/wouldn't do #2 or #3. i'm out of the is
business at the moment, but the "race to the bottom" mentality is stil
a pain in my hindquarters, both present and remembered

[Stephen J. Wilcox]

> actually, it would. universal uRPF would stop some attacks, and it woul
> remove a "plan B" option for some attack-flowcharts. i would *much* rathe
> play defense without facing this latent weapon available to the offense

I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to be
non-existent these days so shall we stop disabling 'ip directed-broadcast' on
our routers

Stev

[Christopher L. Morrow]

On Sun, 7 Mar 2004, Stephen J. Wilcox wrote


> > actually, it would. universal uRPF would stop some attacks, and it woul
> > remove a "plan B" option for some attack-flowcharts. i would *much* rathe
> > play defense without facing this latent weapon available to the offense

> I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to b
> non-existent these days so shall we stop disabling 'ip directed-broadcast' o
> our routers

smurf attacks are far from 'non-existent' today, however they are not a
popular as in 1999-2000-2001. In fact netscan.org still shows almost 9
networks that are 'broken'

[Avleen Vig]

On Sun, Mar 07, 2004 at 08:48:00PM +0000, Christopher L. Morrow wrote
> > > actually, it would. universal uRPF would stop some attacks, and it woul
> > > remove a "plan B" option for some attack-flowcharts. i would *much* rathe
> > > play defense without facing this latent weapon available to the offense
>
> > I'm agreeing here, okay (yet anoter) example.. smurf attacks. These seem to b
> > non-existent these days so shall we stop disabling 'ip directed-broadcast' o
> > our routers
>
> smurf attacks are far from 'non-existent' today, however they are not a
> popular as in 1999-2000-2001. In fact netscan.org still shows almost 9
> networks that are 'broken'

A few of us tried (like netscan, only more agressively on a weekl
basis) to find and try to get closed, smurf amplifiers in the RIP
region
We eventually gave up after closing ~20k, when the last few k refused t
do anything at all
"My network is just a /30! Who cares, you're only getting TWO replie
back for ONE packet, it's not like the big amplifiers! I'm not going t
fix this!"

To anyone with this attitude: You are an idiot

--
Avleen Vi
Systems Administrato

[Stephen J. Wilcox]

> smurf attacks are far from 'non-existent' today, however they are not a
> popular as in 1999-2000-2001.

thats interesting, i've not seen/heard of one for ages.. (guess u have a wider
testing ground :

> In fact netscan.org still shows almost 9k networks that are 'broken'

actually i just ran that file thro a quick awk and sort to see to what extent
these networks exist.

as you can see almost all only reply two or three times, not like in the ol
days with >100 replies being commonplace..

5224
1834
897
334
167
56
19
15
7 1
11 1
6 1
3 1
6 1
1 1
1 1
4 1
5 1
1 2
1 2
1 2
1 10

[Christopher L. Morrow]

removed paul from the direct reply since his mailserver doesn't like uune
mail servers :

On Sun, 7 Mar 2004, Stephen J. Wilcox wrote

> > smurf attacks are far from 'non-existent' today, however they are not a
> > popular as in 1999-2000-2001

> thats interesting, i've not seen/heard of one for ages.. (guess u have a wide
> testing ground :


just last week we had one... they do still happen

> > In fact netscan.org still shows almost 9k networks that are 'broken'

> actually i just ran that file thro a quick awk and sort to see to what exten
> these networks exist.

> as you can see almost all only reply two or three times, not like in the ol
> days with >100 replies being commonplace.


Sure, but a list of 9k networks with this leve of response is still enoug
to do damage. It's getting better, no doubt about it but it's still
factor


--Chri
(formerly ***@uu.net
######################################################
## UUNET Technologies, Inc. #
## Manager #
## Customer Router Security Engineering Team #
## (W)703-886-3823 (C)703-338-7319 #
######################################################

[Paul Vixie]

> I suggested using something like HINFO in the in-addr.arpa addres
> zones for service providers to give similar information about I
> addresses. Yes, I know, using DNS for yet something else. LDAP o
> RWHOIS or any other global mechanism could be used

more uses for dns is actually a good thing in my opinion. but this isn'
one of the times when hierarchical autonomy is the best data model -- w
already know that the average broadband provider is not even aware of thei
role in the overall spam problem, and does not have the budget to emplo
anyone who could (a) become aware of an HINFO-like registry, (b) know wha
category their netblocks belong in, (c) have the technical ability to updat
the RFC1101-like info at the apex of the appropriate zones, and (d) ge
approval from management/legal/marketing/sales to put this data in. so
it's going to have to be an external entity like a RIR or DNSBLP who run
a global "BBL" and externally categorizes these netblocks

> If you don't want to accept connections from indeterminate o
> unauthenticated addresses, its your choice. If you are a porn vendo
> and don't want K12 users to accidently stumble on to your web site
> its your choice. If you are a credit card vendor and don't want t
> accept credit card orders from prisons or jails, its your choice

yes, that's how it works, it's just that right now there's no way to know
and the way-to-know that you proposed requires broadband gross margin no
in evidence (or expected to appear)

[Iljitsch van Beijnum]

On 18-apr-04, at 16:55, Paul Vixie wrote

> we already know that the average broadband provider is not even aware
> of thei
> role in the overall spam problem, and does not have the budget to
> emplo
> anyone who could (a) become aware of an HINFO-like registry, (b) know
> wha
> category their netblocks belong in, (c) have the technical ability to
> updat
> the RFC1101-like info at the apex of the appropriate zones, and (d) ge
> approval from management/legal/marketing/sales to put this data in.
> so
> it's going to have to be an external entity like a RIR or DNSBLP who
> run
> a global "BBL" and externally categorizes these netblocks

Maybe a stupid question... But if broadband providers aren't going to
do this, and considering there are way less legitimate SMTP senders
than broadband users, wouldn't it make more sense to whitelist known
real SMTP sources rather than blacklist all addresses that potentially
have a fake one

This has the advantage that he solution stays in the hands of the
people who are experiencing the problem: SMTP operators

It would be important to make this a list of legitimate SMTP hosts
only, and NOT a list of non-spammers, as the former can be determined
through technical means (1) and the latter is open to endless debate.
(As we can see with pretty much all existing blacklists.

(1) I'm assuming spamworms won't be sporting an
I-can't-believe-this-isn't-a-real-MTA any time soon

[Rik van Riel]

On Sun, 18 Apr 2004, Iljitsch van Beijnum wrote

> It would be important to make this a list of legitimate SMTP host
> only, and NOT a list of non-spammers, as the former can be determine
> through technical means (1) and the latter is open to endless debate
> (As we can see with pretty much all existing blacklists.

However, spamtrap-driven blocklists can use such a lis
to be less aggressive in listing said SMTP hosts. In fact
I've been planning to create such a list myself, in orde
to reduce the false positive rate of the PSBL

Guess I'll have to let NANOG know when it's up and running

I am planning to use some of the DSBL server side softwar
to implement such a "white"list here, with the extra tha
admins can specify the preferred abuse address for the I
addresses they add to the list

3 years ago, I'd have never thought that mail server
would be a minority of the SMTP senders out there, bu
here we are ..

Ri
--
"Debugging is twice as hard as writing the code in the first place
Therefore, if you write the code as cleverly as possible, you are
by definition, not smart enough to debug it." - Brian W. Kernigha

[Paul Vixie]

> Be careful about the slice and dice effect. Depending on how you divid
> up the numbers you can make any thing come out on top. In some sens
> the problem is a lot worse. Its not just spam, worms, viruses. Its no
> just residential broadband users. Its not even just Microsoft Windows

while i agree, i think something i said earlier needs to get re-said

>> So-called "broadband" user populations (cable, dsl, fixed wireless
>> mobile wireless) are full time connected, or nearly so. They ar
>> technically unsophisticated, on average. The platforms they ru
>> trade convenience for security, and must do so in order to remai
>> competitive/relevant. Margin pressure makes it impossible for mos
>> "broadband" service providers to even catalogue known-defect custome
>> systems or process complaints about them
>>
>> Those facts are not in dispute. [...

so, we know that a "broadband customer netblock" operator will no
handle complaints, will not fix the systems that are known to b
running third-hand malware, and that the only recourse against abus
from those places is blackholing them one (ipv4) /32 at a time, o
blackholing them all at once and forcing mail servers (whether legi
or not) to operate from a higher-rent neighborhood

there's no choice at all, really

[Petri Helenius]

Paul Vixie wrote


>so, we know that a "broadband customer netblock" operator will no
>handle complaints, will not fix the systems that are known to b
>running third-hand malware, and that the only recourse against abus
>from those places is blackholing them one (ipv4) /32 at a time, o
>blackholing them all at once and forcing mail servers (whether legi
>or not) to operate from a higher-rent neighborhood

>there's no choice at all, really

>

Are you suggesting to drop all traffic (which, if widespread would get
attention) or just email
If you´re suggesting only email blocking, you'll promote email-peering
agreement, eventually with settlement, architechture

Pet

[Paul Vixie]

> So you claim even the ISPs you ran yourself have never attempted to d
> any of these things

the last access-side isp i had anything to do with running used uucp an
shell and was just getting going on c-slip when i pushed off. (i assur
that any rmail or rnews spam was grounds for suspension during my watch.

my last gig at a colo-side isp ended with me moving over to paix due t
the board's discomfort over my policies toward certain colo-side customer
(who have since improved, yay.

> If you didn't do them, why do you think other people should

so you aren't going to google for "chemical polluter business model", huh

[Sean Donelan]

On Sun, 13 Jun 2004, Paul Vixie wrote
> > If you didn't do them, why do you think other people should

> so you aren't going to google for "chemical polluter business model", huh

I hope you also google for Nonpoint Source Pollution

ISPs don't put the pollution in the water, ISPs are trying to clean u
the water polluted by others. ISPs are spending a lot of money cleanin
up problems created by other people

[David Schwartz]

> On Sun, 13 Jun 2004, Paul Vixie wrote

> > > If you didn't do them, why do you think other people should

> > so you aren't going to google for "chemical polluter busines
> model", huh

> I hope you also google for Nonpoint Source Pollution

> ISPs don't put the pollution in the water, ISPs are trying to clean u
> the water polluted by others. ISPs are spending a lot of money cleanin
> up problems created by other people

ISPs do put the pollution in the water. They own/run the pipes that carr
the pollution into the ocean. Nobody cares about pollution inside the ISP'
own network, we only care about the pollution they put into our water. The
own, run, and manage the pipes that put the pollution where it can har
others. They have continuous control over the process and ultimately decid
who does or does not put things into those pipes and influence the policies

I think there's a serious disconnect between how ISPs see this issue an
how their customers do. I hold ISPs responsible for their customers behavio
once they are aware of that behavior. It has been many years since "I jus
pass the traffic my customers tell me to pass" was an acceptable answer. I
fact, ISPs that take that attitude are (properly) ostracized today

If an ISP knows or suspected or should know that their customer is puttin
pollution into the communal waters, they have an obligation to do whateve
it takes to stop that pollution. If that's notifying the customer
disconnecting the customer, filtering, whatever, that's between the ISP an
the customer. I'm willing to make all kinds of allowances for what is and i
not possible. I don't expect a filter in minutes. I don't expect them t
disconnect a customer because they couldn't reach them. However, I do expec
them to track the issue with their customer until it's resolved. If they d
not do so, I hold them responsible to the extent that I am able to do so

Again, as I said, this in no way diminishes the responsiblity of th
customer, the author of the malware, the person who failed to install th
patch, the person who misconfigured the firewall (or decided they reall
didn't need one). Responsibility does not have to sum to 100%, it's possibl
for any number of parties to be wholly responsible

It amazes me how quick ISPs are to blame others, as if this diminshes thei
responsibility. It does not. If I leave your car unlocked and someone steal
your CDs, no amount of blame I place on the thief diminshes m
responsibility

D

[Paul Vixie]

***@webmaster.com ("David Schwartz") writes

> > ISPs don't put the pollution in the water, ISPs are trying to clean u
> > the water polluted by others. ISPs are spending a lot of money cleanin
> > up problems created by other people
>
> ISPs do put the pollution in the water. They own/run the pipes tha
> carry the pollution into the ocean. Nobody cares about pollution insid
> the ISP's own network, we only care about the pollution they put into ou
> water. They own, run, and manag

"and profit from

> the pipes that put the pollution where it can harm others. They hav
> continuous control over the process and ultimately decide who does o
> does not put things into those pipes and influence the policies

yea, verily
--
Paul Vixi

[John Curran]

The real challenge here is that the "default" Internet service i
wide-open Internet Protocol, w/o any safeties or controls. Thi
made a lot of sense when the Internet was a few hundred sites
but is showing real scaling problems today (spam, major viruses
etc.

One could imagine changing the paradigm (never easy) so that
the normal Internet service was proxied for common applications
and NAT'ed for everything else... This wouldn't eliminate all th
problems, but would dramatically cut down the incident rate

If a site wants wide-open access, just give it to them. If that turns
out to cause operational problems (due to open mail proxies, spam
origination, etc), then put 'em back behind the relays

/Joh

[Anthony Edwards]

On Sun, Jun 13, 2004 at 04:21:03AM +0000, Christopher L. Morrow wrote

> We have methods of dealing with these abuse problems today, unfortanatel
> as Paul Vixie often points out there are business reasons why thes
> problems persist. Often the 'business' reason isn't th
> tin-foil-hat-brigade's reason so much as 'we can't afford to keep thes
> abuse folks around since they don't make money for the company'

One of the core skills required by an abuse desk person, and i
particular an abuse team manager, is an ability to evangelise to highe
management the business benefits of effective Acceptable Use Polic
enforcement

For example, how many legitimate prospective customers does th
following

Found 187 SBL listings for IPs under the responsibilit
of mci.co

Listings in yellow are known spam gangs with ROKSO record

http://www.spamhaus.org/sbl/listings.lass

Cause to decide not to even consider you as a supplier of bandwidt
and/or hosting services? When one also factors into the equatio
the fact that spammers (of whatever type) tend historically to b
bad payers, it is not unlikely that your apparent business relate
decision to provide safe haven to such folks is actually a cause o
net revenue loss, not gain

--
Anthony Edwards * ***@uk.easynet.ne
Abuse Team Manager * Easynet UK Abuse Tea
Easynet Ltd * DDI: 0161 227 070
http://www.uk.easynet.net * Fax: [phone]

[Randy Bush]

> One could imagine changing the paradigm (never easy) so that
> the normal Internet service was proxied for common applications
> and NAT'ed for everything else... This wouldn't eliminate all th
> problems, but would dramatically cut down the incident rate
>
> If a site wants wide-open access, just give it to them. If that turns
> out to cause operational problems (due to open mail proxies, spam
> origination, etc), then put 'em back behind the relays

guilty until proven innocent, eh? thanks mr ashcroft

rand

[John Curran]

At 6:58 PM -0700 6/12/04, Randy Bush wrote
> > One could imagine changing the paradigm (never easy) so tha
>> the normal Internet service was proxied for common application
>> and NAT'ed for everything else... This wouldn't eliminate all th
>> problems, but would dramatically cut down the incident rate
>
>> If a site wants wide-open access, just give it to them. If that turn
>> out to cause operational problems (due to open mail proxies, spa
>> origination, etc), then put 'em back behind the relays

>guilty until proven innocent, eh? thanks mr ashcroft

Randy, are you objecting to the model for initial connectivity
or the throwing them back behind relays w/o a formal trial

/Joh

[Sean Donelan]

On Sat, 12 Jun 2004, John Curran wrote
> One could imagine changing the paradigm (never easy) so tha
> the normal Internet service was proxied for common application
> and NAT'ed for everything else... This wouldn't eliminate all th
> problems, but would dramatically cut down the incident rate

In the BBS days, how did most viruses get on computers? Have thing
really changed that much

Take a look how computers are being compromised. Its amazing just ho
many compromised computers have NAT, firewalls, proxies, etc

1) pre-infected, i.e. already compromised before connecting to you
network (laptops are dangerous
2) self-infected, i.e. compromised because the user installed th
software containing the viru
3) network-infected, i.e. compromised solely by being connected withou
any action by the use

Some broadband providers have been selling service that includes
NAT/firewall on the connection for several years. What is the differenc
in infection rate of those users? Is it just wishfull thinking by som
people that NAT/firewalls/proxies will solve the problem? Or do they hav
hard data to back them up

Preventing users from compromising their computers is a lot lik
preventing users from accessing porn or music. Basically anything th
user wants could be potentially harmful, and the miscreants know that
So how do you make sure users can only access "safe" content

[Christopher L. Morrow]

On Sat, 12 Jun 2004, John Curran wrote


> The real challenge here is that the "default" Internet service i
> wide-open Internet Protocol, w/o any safeties or controls. Thi
> made a lot of sense when the Internet was a few hundred sites
> but is showing real scaling problems today (spam, major viruses
> etc.

> One could imagine changing the paradigm (never easy) so tha
> the normal Internet service was proxied for common application
> and NAT'ed for everything else... This wouldn't eliminate all th
> problems, but would dramatically cut down the incident rate

This sounds like a fantastic idea, for instance: How much direct IP doe
joe-average Internet user really require? Do they require anything mor
than imap(s)/pop(s)/smtp(+tls) and dns/http/https ? I suppose they als
need
1) internet gamin
2) voi
3) kazaa/p2p-app(s)-of-choic
4) I

Actually I'm sure there are quite a few things they need, things whic
require either very smart NAT/Proxy devices or open access. The filterin
of IP on the broad scale will hamper creativity and innovation. I'm fairl
certain this was not what we want in the long term, is it


> If a site wants wide-open access, just give it to them. If that turn
> out to cause operational problems (due to open mail proxies, spa
> origination, etc), then put 'em back behind the relays


We have methods of dealing with these abuse problems today, unfortanatel
as Paul Vixie often points out there are business reasons why thes
problems persist. Often the 'business' reason isn't th
tin-foil-hat-brigade's reason so much as 'we can't afford to keep thes
abuse folks around since they don't make money for the company'

Downstream from the ISP, the individuals are not taking responsibility fo
their actions/in-actions with respect to 'security'. Vendors are no
providing safe environments for their consumers either. I understand tha
shipping an OS with 100% of things enabled might 'foster innovation' o
'make things easier for the end user', however, so would well though
instructions for enabling (safely) these same features. 99% of compute
users never ever need to share files, yet file sharing is enabled b
defailt on some operating systems... This is a major vector for infectio
and abuse

Education and awareness are also lacking in the industry as a whole, wel
not the 'industry' so much as 'the culture' I think. "Why should anyon
want to hack my machine? I'm not some big corporation with lots o
'secrets'." No, they want your machine for the simple fact it's connecte
to the global Internet and it's NOT their ip address so abuse of it won'
harm 'them' :

-Chri

[John Curran]

At 4:21 AM +0000 6/13/04, Christopher L. Morrow wrote

>We have methods of dealing with these abuse problems today, unfortanatel
>as Paul Vixie often points out there are business reasons why thes
>problems persist. Often the 'business' reason isn't th
>tin-foil-hat-brigade's reason so much as 'we can't afford to keep thes
>abuse folks around since they don't make money for the company'

I'll argue that we have don't effective methods of dealing with this today
and it's not the lack of abuse desk people as much as the philosophy o
closing barn doors after the fact. The idea that we can leave everythin
wide open for automated exploit tools, and then clean up afterward
manually with labor-intensive efforts is fundamentally flawed

/Joh

[Paul Vixie]

> >We have methods of dealing with these abuse problems today, unfortanatel
> >as Paul Vixie often points out there are business reasons why thes
> >problems persist. Often the 'business' reason isn't the tin-foil
> >hat-brigade's reason so much as 'we can't afford to keep these abus
> >folks around since they don't make money for the company'
>
> I'll argue that we have don't effective methods of dealing with this today
> and it's not the lack of abuse desk people as much as the philosophy o
> closing barn doors after the fact. The idea that we can leave everythin
> wide open for automated exploit tools, and then clean up afterward
> manually with labor-intensive efforts is fundamentally flawed

and i'd agree. the trouble, when this problem was first isolated, was tha
the costs and benefits were assymetric. the people who needed the adde
services (filtering, training, remote OS upgrades/audits/management, etc
were the ones least able/willing to pay extra for those services. the folk
who didn't need them have always complained that they have to pay more t
avoid getting them

now, though, there's an opportunity to do a marketing U-turn on this. cabl
and dsl providers in the USA can point to the national cybersecurity plan an
say that to comply with it they have to put infected computers in cyberjail
with a fee of $N to get these machines audited, and if found clean, put bac
on the net, noting that N doubles every time this process is invoked, an
that a deposit of $(0.5*N) is required as prepayment for the next incident
refundable after one year if there are no further incidents. then offer t
remotely manage their host ("give me your root passwords, trust me!") for a
annual fee of $(0.75*N). if the initial value of N were $500, you might b
able to get the people who need this service to pay for it. it's worth a try
--
Paul Vixi

[Doug White]

----- Original Message -----
From: "Paul Vixie" <***@vix.com


: now, though, there's an opportunity to do a marketing U-turn on this. cabl
: and dsl providers in the USA can point to the national cybersecurity plan an
: say that to comply with it they have to put infected computers in cyberjail
: with a fee of $N to get these machines audited, and if found clean, put bac
: on the net, noting that N doubles every time this process is invoked, an
: that a deposit of $(0.5*N) is required as prepayment for the next incident
: refundable after one year if there are no further incidents. then offer t
: remotely manage their host ("give me your root passwords, trust me!") for a
: annual fee of $(0.75*N). if the initial value of N were $500, you might b
: able to get the people who need this service to pay for it. it's worth
try
: --
: Paul Vixi


If I read Paul's post correctly, then I would have to agree that the costs o
cleaning up the problem customers should be placed on the customer (miscreant
as opposed to the rest of us. This would be far more preferable than puttin
in place controls by the respective ISP that would limit my own use of m
connection, on which I have spent considerable time, money and education t
make sure it is secure and beyond that, compliant with the ISP Acceptable Us
policies

Dou

[Paul Vixie]

***@clickdoug.com ("Doug White") writes

> If I read Paul's post correctly, then I would have to agree that th
> costs of cleaning up the problem customers should be placed on th
> customer (miscreant) as opposed to the rest of us

and if you read the other post last night you'll see that this has t
be fixed and that the money to fix it has to come from somewhere an
that if making cable/dsl subscribers pay more if they need these service
won't work, then making cable/dsl subscribes pay more if they don't nee
these services would have to remain the norm (it's already the norm.

> This would be far more preferable than putting in place controls by th
> respective ISP that would limit my own use of my connection, on which
> have spent considerable time, money and education to make sure it i
> secure and beyond that, compliant with the ISP Acceptable Use policies

i agree that making users like you describe pay more is senseless. bu
what really burns me is that you're made to pay more, but the cable/ds
company just pockets the money rather than allocating it toward filterin
cleaning or otherwise dealing with the effluent dumped into the stream a
a side effect of their operations

--

which brings us back to the chemical polluter business model, and sean
sean's been whining for a while about how it's not reasonable for larg
masses of pollution victims to boycott all output from his factory, sinc
there's good mixed in with the bad. this all seems like throwing out th
baby with the bathwater the way sean looks at things. so, let me be ver
clear about what i mean and what i want

what follows is a list of hits in my darkspace IDS from one of sean's
networks, just for demonstration purposes. what i want is

1. sean make some effort to discover these on his own rather than waitin
to be told about them by victims
2. sean believe me (and other qualified victims) when i report them
3. verified reports result in immediate customer service suspension
4. the customer be required to either attend training or pay a fine or both
5. the customer's machine be audited before reconnection
6. sean should ask the FCC to require this behaviour of his competitors also
7. sean should stop whining about how i reject all traffic from his customers

note that the list below has ~600 entries and is just a /19 out of a large
/12. the listing for the /12 is Quite Large and would not be instructive

SELECT MIN(DATE(entered)) AS earliest
MAX(DATE(entered)) AS latest
srcaddr
COUNT(srcaddr
FROM tran
WHERE srcaddr << '63.202.104.0/19
GROUP BY srcadd
ORDER BY srcaddr

earliest | latest | srcaddr | count
------------+------------+----------------+------
2004-04-13 | 2004-04-13 | 63.202.96.65 |
2004-04-08 | 2004-04-08 | 63.202.96.67 |
2004-03-19 | 2004-03-19 | 63.202.96.69 |
2004-03-18 | 2004-03-18 | 63.202.98.234 |
2004-04-17 | 2004-04-17 | 63.202.104.9 |
2003-01-19 | 2003-01-19 | 63.202.104.10 |
2004-03-28 | 2004-03-28 | 63.202.104.14 |
2004-03-22 | 2004-03-22 | 63.202.104.24 |
2004-05-29 | 2004-05-29 | 63.202.104.28 |
2004-03-30 | 2004-03-30 | 63.202.104.32 |
2004-03-29 | 2004-03-29 | 63.202.104.37 |
2004-04-14 | 2004-04-14 | 63.202.104.46 |
2004-03-22 | 2004-03-22 | 63.202.104.48 |
2004-04-19 | 2004-04-19 | 63.202.104.50 |
2004-03-17 | 2004-03-17 | 63.202.104.51 |
2004-04-01 | 2004-04-01 | 63.202.104.52 |
2004-03-26 | 2004-03-26 | 63.202.104.59 |
2004-05-07 | 2004-05-07 | 63.202.104.60 |
2004-03-18 | 2004-03-18 | 63.202.104.68 |
2004-04-08 | 2004-04-08 | 63.202.104.70 |
2004-01-01 | 2004-03-24 | 63.202.104.77 |
2003-10-28 | 2003-10-28 | 63.202.104.80 |
2004-03-20 | 2004-03-20 | 63.202.104.82 |
2004-03-26 | 2004-03-26 | 63.202.104.84 |
2004-04-04 | 2004-04-04 | 63.202.104.88 |
2004-04-03 | 2004-04-03 | 63.202.104.89 |
2003-01-12 | 2003-01-12 | 63.202.104.93 |
2003-04-14 | 2003-04-14 | 63.202.104.98 | 2
2004-03-17 | 2004-03-17 | 63.202.104.101 | 1
2004-04-03 | 2004-04-03 | 63.202.104.109 | 1
2004-02-12 | 2004-02-12 | 63.202.104.110 | 1
2004-04-20 | 2004-04-20 | 63.202.104.111 | 1
2004-03-29 | 2004-03-29 | 63.202.104.118 | 1
2004-04-08 | 2004-04-08 | 63.202.104.121 | 1
2003-10-01 | 2003-10-01 | 63.202.104.126 | 1
2004-03-17 | 2004-03-17 | 63.202.104.130 | 1
2004-05-04 | 2004-05-04 | 63.202.104.133 | 1
2004-05-05 | 2004-05-05 | 63.202.104.145 | 1
2003-10-05 | 2004-04-11 | 63.202.104.154 | 2
2004-03-20 | 2004-03-20 | 63.202.104.155 | 1
2004-04-12 | 2004-04-12 | 63.202.104.157 | 1
2004-05-28 | 2004-05-28 | 63.202.104.159 | 1
2003-08-25 | 2003-08-25 | 63.202.104.161 | 1
2004-05-05 | 2004-05-05 | 63.202.104.164 | 1
2004-04-18 | 2004-04-18 | 63.202.104.165 | 1
2004-04-21 | 2004-04-21 | 63.202.104.169 | 1
2004-05-05 | 2004-05-05 | 63.202.104.171 | 1
2003-12-02 | 2003-12-02 | 63.202.104.173 | 1
2004-03-30 | 2004-03-30 | 63.202.104.176 | 1
2004-03-21 | 2004-03-21 | 63.202.104.178 | 1
2004-04-02 | 2004-04-02 | 63.202.104.180 | 1
2004-04-10 | 2004-04-10 | 63.202.104.184 | 1
2003-10-03 | 2003-10-04 | 63.202.104.186 | 2
2003-08-29 | 2003-08-29 | 63.202.104.195 | 1
2003-09-06 | 2003-09-06 | 63.202.104.198 | 1
2003-12-10 | 2003-12-10 | 63.202.104.204 | 1
2003-10-09 | 2004-05-14 | 63.202.104.211 | 2
2003-12-07 | 2003-12-07 | 63.202.104.218 | 1
2004-03-18 | 2004-03-18 | 63.202.104.219 | 1
2003-09-28 | 2003-09-28 | 63.202.104.222 | 1
2003-10-12 | 2003-10-12 | 63.202.104.226 | 1
2004-04-17 | 2004-04-17 | 63.202.104.230 | 1
2004-04-11 | 2004-04-11 | 63.202.104.240 | 1
2004-04-21 | 2004-04-21 | 63.202.104.241 | 1
2004-04-13 | 2004-04-13 | 63.202.104.242 | 1
2004-04-18 | 2004-04-18 | 63.202.104.245 | 1
2004-03-29 | 2004-03-29 | 63.202.104.253 | 1
2004-05-30 | 2004-05-30 | 63.202.105.9 | 1
2004-03-28 | 2004-03-28 | 63.202.105.15 | 1
2004-04-26 | 2004-04-26 | 63.202.105.31 | 1
2004-03-25 | 2004-03-25 | 63.202.105.35 | 1
2003-11-30 | 2004-04-10 | 63.202.105.39 | 2
2004-04-22 | 2004-04-22 | 63.202.105.44 | 1
2004-04-19 | 2004-04-19 | 63.202.105.46 | 1
2004-04-11 | 2004-04-11 | 63.202.105.50 | 1
2004-05-13 | 2004-05-13 | 63.202.105.54 | 1
2003-10-31 | 2003-10-31 | 63.202.105.57 | 1
2003-08-26 | 2004-03-18 | 63.202.105.68 | 3
2003-09-29 | 2003-09-29 | 63.202.105.69 | 1
2003-09-09 | 2004-03-30 | 63.202.105.70 | 2
2004-03-21 | 2004-03-21 | 63.202.105.71 | 1
2003-09-19 | 2004-05-08 | 63.202.105.77 | 2
2003-11-19 | 2003-11-19 | 63.202.105.86 | 1
2004-05-13 | 2004-05-13 | 63.202.105.88 | 1
2004-04-14 | 2004-04-14 | 63.202.105.90 | 1
2004-05-12 | 2004-05-12 | 63.202.105.91 | 1
2004-04-17 | 2004-04-17 | 63.202.105.94 | 1
2004-05-12 | 2004-05-12 | 63.202.105.99 | 1
2003-12-16 | 2003-12-16 | 63.202.105.110 | 1
2003-12-13 | 2003-12-13 | 63.202.105.116 | 1
2004-03-26 | 2004-03-26 | 63.202.105.123 | 1
2003-12-31 | 2003-12-31 | 63.202.105.125 | 1
2004-05-09 | 2004-05-09 | 63.202.105.128 | 1
2004-03-29 | 2004-03-29 | 63.202.105.131 | 1
2004-05-11 | 2004-05-11 | 63.202.105.135 | 1
2004-03-20 | 2004-03-20 | 63.202.105.142 | 1
2004-05-07 | 2004-05-07 | 63.202.105.144 | 1
2003-01-17 | 2003-01-17 | 63.202.105.147 | 2
2003-11-12 | 2003-11-12 | 63.202.105.149 | 1
2004-05-12 | 2004-05-12 | 63.202.105.155 | 1
2004-04-15 | 2004-04-15 | 63.202.105.163 | 1
2004-03-21 | 2004-03-21 | 63.202.105.164 | 1
2003-05-02 | 2003-05-07 | 63.202.105.171 | 31
2004-05-09 | 2004-05-09 | 63.202.105.173 | 1
2004-05-15 | 2004-05-15 | 63.202.105.186 | 1
2004-03-18 | 2004-03-18 | 63.202.105.192 | 2
2004-05-11 | 2004-05-11 | 63.202.105.196 | 1
2004-04-23 | 2004-04-23 | 63.202.105.199 | 1
2004-03-31 | 2004-03-31 | 63.202.105.200 | 1
2004-04-27 | 2004-04-27 | 63.202.105.204 | 1
2003-11-22 | 2004-03-28 | 63.202.105.208 | 2
2004-04-26 | 2004-04-26 | 63.202.105.214 | 1
2004-03-19 | 2004-03-19 | 63.202.105.221 | 1
2004-03-20 | 2004-03-20 | 63.202.105.223 | 1
2004-04-21 | 2004-04-21 | 63.202.105.226 | 1
2004-04-28 | 2004-04-28 | 63.202.105.227 | 1
2004-05-28 | 2004-05-28 | 63.202.105.228 | 1
2003-07-16 | 2003-07-22 | 63.202.105.230 | 90
2004-04-12 | 2004-04-12 | 63.202.105.236 | 1
2003-10-05 | 2003-10-05 | 63.202.105.238 | 1
2003-03-30 | 2003-03-30 | 63.202.105.239 | 1
2003-09-03 | 2003-09-03 | 63.202.105.245 | 1
2004-05-14 | 2004-05-14 | 63.202.105.249 | 1
2004-03-25 | 2004-03-25 | 63.202.105.250 | 1
2003-11-25 | 2003-11-25 | 63.202.105.251 | 1
2004-04-06 | 2004-04-06 | 63.202.106.0 | 1
2004-04-02 | 2004-04-02 | 63.202.106.1 | 1
2004-04-26 | 2004-04-26 | 63.202.106.3 | 1
2003-10-28 | 2003-10-28 | 63.202.106.5 | 1
2003-05-28 | 2003-05-28 | 63.202.106.7 | 3
2004-04-11 | 2004-04-11 | 63.202.106.8 | 1
2004-04-01 | 2004-04-01 | 63.202.106.9 | 1
2004-03-25 | 2004-03-25 | 63.202.106.14 | 1
2004-03-21 | 2004-03-21 | 63.202.106.17 | 1
2004-05-07 | 2004-05-07 | 63.202.106.22 | 1
2003-05-18 | 2003-05-18 | 63.202.106.26 | 3
2004-04-21 | 2004-04-21 | 63.202.106.28 | 2
2004-05-07 | 2004-05-07 | 63.202.106.29 | 1
2004-03-31 | 2004-03-31 | 63.202.106.33 | 1
2004-04-19 | 2004-04-19 | 63.202.106.47 | 1
2004-04-22 | 2004-04-22 | 63.202.106.50 | 1
2004-04-17 | 2004-04-17 | 63.202.106.51 | 1
2004-05-14 | 2004-05-14 | 63.202.106.55 | 1
2003-04-18 | 2003-04-18 | 63.202.106.67 | 2
2004-04-24 | 2004-04-24 | 63.202.106.68 | 1
2004-04-30 | 2004-04-30 | 63.202.106.69 | 1
2004-03-20 | 2004-03-20 | 63.202.106.72 | 1
2003-12-04 | 2003-12-04 | 63.202.106.82 | 1
2004-04-25 | 2004-04-25 | 63.202.106.85 | 1
2003-05-18 | 2003-05-18 | 63.202.106.87 | 1
2004-05-13 | 2004-05-13 | 63.202.106.92 | 1
2004-05-28 | 2004-05-28 | 63.202.106.93 | 1
2004-04-01 | 2004-04-01 | 63.202.106.94 | 1
2004-04-11 | 2004-04-11 | 63.202.106.95 | 1
2004-04-22 | 2004-04-22 | 63.202.106.98 | 1
2004-04-10 | 2004-04-10 | 63.202.106.104 | 1
2004-05-12 | 2004-05-12 | 63.202.106.106 | 1
2003-07-15 | 2003-07-15 | 63.202.106.108 | 1
2004-05-13 | 2004-05-13 | 63.202.106.111 | 1
2004-05-27 | 2004-05-27 | 63.202.106.113 | 1
2003-11-14 | 2004-03-17 | 63.202.106.127 | 2
2004-04-21 | 2004-04-21 | 63.202.106.129 | 1
2004-04-12 | 2004-04-12 | 63.202.106.130 | 1
2004-04-16 | 2004-04-16 | 63.202.106.137 | 1
2004-04-20 | 2004-04-20 | 63.202.106.139 | 1
2004-02-18 | 2004-02-18 | 63.202.106.140 | 1
2004-03-25 | 2004-03-25 | 63.202.106.142 | 1
2003-11-21 | 2003-11-21 | 63.202.106.143 | 1
2004-05-10 | 2004-05-10 | 63.202.106.145 | 1
2003-12-01 | 2003-12-12 | 63.202.106.149 | 2
2004-03-27 | 2004-03-27 | 63.202.106.150 | 1
2003-09-01 | 2004-04-07 | 63.202.106.151 | 2
2003-09-27 | 2003-09-27 | 63.202.106.155 | 1
2004-04-30 | 2004-04-30 | 63.202.106.159 | 1
2004-03-27 | 2004-03-27 | 63.202.106.163 | 1
2004-04-04 | 2004-04-04 | 63.202.106.167 | 1
2004-04-14 | 2004-04-14 | 63.202.106.170 | 1
2004-03-21 | 2004-03-21 | 63.202.106.181 | 1
2003-04-30 | 2003-04-30 | 63.202.106.182 | 1
2004-05-02 | 2004-05-02 | 63.202.106.183 | 1
2003-08-28 | 2003-08-28 | 63.202.106.186 | 1
2003-10-14 | 2003-10-14 | 63.202.106.195 | 1
2004-03-26 | 2004-03-26 | 63.202.106.197 | 1
2004-03-26 | 2004-03-26 | 63.202.106.205 | 1
2004-05-02 | 2004-05-02 | 63.202.106.206 | 1
2004-03-31 | 2004-03-31 | 63.202.106.215 | 1
2004-03-28 | 2004-03-28 | 63.202.106.219 | 1
2004-03-25 | 2004-03-25 | 63.202.106.220 | 1
2004-04-16 | 2004-04-16 | 63.202.106.223 | 1
2003-10-14 | 2003-10-21 | 63.202.106.231 | 2
2004-04-27 | 2004-04-27 | 63.202.106.232 | 1
2004-04-08 | 2004-04-08 | 63.202.106.234 | 1
2004-03-24 | 2004-03-24 | 63.202.106.235 | 1
2004-04-23 | 2004-04-23 | 63.202.106.246 | 1
2004-04-27 | 2004-04-27 | 63.202.107.0 | 1
2004-01-04 | 2004-05-01 | 63.202.107.8 | 3
2003-12-09 | 2003-12-09 | 63.202.107.11 | 1
2003-01-10 | 2003-01-12 | 63.202.107.12 | 4
2004-04-14 | 2004-04-14 | 63.202.107.13 | 1
2004-03-19 | 2004-03-19 | 63.202.107.18 | 1
2004-05-10 | 2004-05-10 | 63.202.107.21 | 1
2004-04-04 | 2004-04-04 | 63.202.107.25 | 1
2004-04-11 | 2004-04-11 | 63.202.107.29 | 1
2004-04-16 | 2004-04-16 | 63.202.107.33 | 1
2004-02-14 | 2004-02-14 | 63.202.107.36 | 1
2003-12-20 | 2003-12-20 | 63.202.107.42 | 1
2004-04-09 | 2004-04-09 | 63.202.107.48 | 1
2004-03-17 | 2004-03-17 | 63.202.107.56 | 1
2004-03-23 | 2004-03-23 | 63.202.107.59 | 1
2004-04-10 | 2004-04-10 | 63.202.107.60 | 1
2004-03-21 | 2004-03-21 | 63.202.107.61 | 1
2003-09-11 | 2003-09-11 | 63.202.107.62 | 1
2004-03-24 | 2004-03-24 | 63.202.107.64 | 1
2004-04-14 | 2004-04-14 | 63.202.107.67 | 1
2003-05-12 | 2003-05-12 | 63.202.107.68 | 1
2004-04-14 | 2004-05-17 | 63.202.107.71 | 2
2004-05-03 | 2004-05-03 | 63.202.107.72 | 1
2004-05-02 | 2004-05-02 | 63.202.107.76 | 1
2004-03-21 | 2004-03-21 | 63.202.107.79 | 1
2004-03-22 | 2004-03-22 | 63.202.107.81 | 1
2003-11-29 | 2003-11-29 | 63.202.107.82 | 1
2004-03-08 | 2004-03-08 | 63.202.107.83 | 1
2003-11-21 | 2003-11-21 | 63.202.107.90 | 1
2003-11-19 | 2003-11-19 | 63.202.107.91 | 1
2004-03-31 | 2004-03-31 | 63.202.107.92 | 1
2004-04-04 | 2004-04-04 | 63.202.107.93 | 1
2004-04-28 | 2004-04-28 | 63.202.107.104 | 1
2004-05-07 | 2004-05-07 | 63.202.107.107 | 1
2004-04-09 | 2004-04-09 | 63.202.107.109 | 1
2004-05-07 | 2004-05-07 | 63.202.107.115 | 1
2004-05-27 | 2004-05-27 | 63.202.107.116 | 1
2004-03-18 | 2004-03-18 | 63.202.107.119 | 1
2004-05-08 | 2004-05-08 | 63.202.107.120 | 1
2004-05-03 | 2004-05-03 | 63.202.107.121 | 1
2004-04-03 | 2004-04-03 | 63.202.107.123 | 1
2004-03-21 | 2004-03-21 | 63.202.107.129 | 1
2004-04-02 | 2004-04-02 | 63.202.107.134 | 1
2003-12-02 | 2003-12-02 | 63.202.107.135 | 1
2003-09-07 | 2004-04-29 | 63.202.107.151 | 2
2003-05-12 | 2004-03-24 | 63.202.107.154 | 3
2004-04-21 | 2004-04-21 | 63.202.107.155 | 1
2004-04-22 | 2004-04-22 | 63.202.107.157 | 1
2004-03-26 | 2004-03-26 | 63.202.107.160 | 1
2004-05-09 | 2004-05-09 | 63.202.107.161 | 1
2004-04-09 | 2004-04-09 | 63.202.107.169 | 1
2004-03-23 | 2004-03-23 | 63.202.107.170 | 1
2004-04-01 | 2004-04-01 | 63.202.107.171 | 1
2004-04-21 | 2004-04-21 | 63.202.107.176 | 1
2004-05-01 | 2004-05-01 | 63.202.107.177 | 1
2004-05-11 | 2004-05-11 | 63.202.107.178 | 1
2004-04-29 | 2004-04-29 | 63.202.107.179 | 1
2003-09-21 | 2003-09-21 | 63.202.107.180 | 1
2004-04-10 | 2004-04-10 | 63.202.107.182 | 1
2004-04-01 | 2004-04-01 | 63.202.107.184 | 1
2004-04-29 | 2004-04-29 | 63.202.107.185 | 1
2004-03-31 | 2004-03-31 | 63.202.107.206 | 1
2004-04-28 | 2004-04-28 | 63.202.107.209 | 1
2003-02-14 | 2003-02-25 | 63.202.107.214 | 57
2003-05-21 | 2003-05-21 | 63.202.107.215 | 1
2004-03-31 | 2004-03-31 | 63.202.107.218 | 1
2004-04-24 | 2004-04-24 | 63.202.107.226 | 1
2004-03-30 | 2004-03-30 | 63.202.107.231 | 1
2004-03-28 | 2004-03-28 | 63.202.107.241 | 1
2003-09-09 | 2004-03-19 | 63.202.107.242 | 2
2004-04-17 | 2004-04-17 | 63.202.107.243 | 1
2004-04-19 | 2004-04-19 | 63.202.107.246 | 1
2003-10-01 | 2004-05-30 | 63.202.107.251 | 2
2004-05-28 | 2004-05-28 | 63.202.107.252 | 1
2004-05-07 | 2004-05-07 | 63.202.108.5 | 1
2004-03-21 | 2004-03-21 | 63.202.108.8 | 1
2004-05-06 | 2004-05-06 | 63.202.108.9 |
2004-05-07 | 2004-05-07 | 63.202.108.10 |
2004-04-21 | 2004-04-21 | 63.202.108.12 |
2003-12-24 | 2003-12-24 | 63.202.108.13 |
2004-03-22 | 2004-03-22 | 63.202.108.14 |
2004-04-27 | 2004-04-27 | 63.202.108.15 |
2004-05-31 | 2004-05-31 | 63.202.108.17 |
2004-03-26 | 2004-03-26 | 63.202.108.29 |
2004-03-19 | 2004-03-19 | 63.202.108.35 |
2004-04-07 | 2004-04-07 | 63.202.108.37 |
2002-12-11 | 2002-12-11 | 63.202.108.40 | 9
2004-03-24 | 2004-03-24 | 63.202.108.50 |
2003-09-05 | 2003-09-07 | 63.202.108.51 |
2004-04-29 | 2004-04-29 | 63.202.108.55 |
2003-01-19 | 2003-01-19 | 63.202.108.57 |
2003-10-02 | 2003-10-02 | 63.202.108.61 |
2003-10-15 | 2003-10-15 | 63.202.108.63 |
2003-09-15 | 2003-09-15 | 63.202.108.72 |
2003-10-17 | 2003-10-17 | 63.202.108.73 |
2004-03-22 | 2004-03-22 | 63.202.108.76 |
2003-11-07 | 2003-11-07 | 63.202.108.78 |
2004-03-31 | 2004-03-31 | 63.202.108.80 |
2004-04-26 | 2004-04-26 | 63.202.108.81 |
2004-04-03 | 2004-04-03 | 63.202.108.88 |
2003-08-29 | 2003-08-29 | 63.202.108.89 |
2004-04-16 | 2004-04-16 | 63.202.108.96 |
2004-04-24 | 2004-04-28 | 63.202.108.99 |
2004-04-04 | 2004-04-04 | 63.202.108.101 |
2004-03-17 | 2004-03-17 | 63.202.108.105 |
2004-03-19 | 2004-03-19 | 63.202.108.110 |
2004-02-14 | 2004-02-14 | 63.202.108.111 |
2004-04-17 | 2004-04-17 | 63.202.108.112 |
2004-03-17 | 2004-03-17 | 63.202.108.115 |
2004-05-14 | 2004-05-14 | 63.202.108.127 |
2004-03-17 | 2004-03-17 | 63.202.108.135 |
2004-03-24 | 2004-03-24 | 63.202.108.140 |
2004-04-16 | 2004-04-16 | 63.202.108.142 |
2003-09-01 | 2003-09-01 | 63.202.108.144 |
2004-03-17 | 2004-03-17 | 63.202.108.149 |
2003-03-14 | 2003-03-15 | 63.202.108.160 |
2004-03-28 | 2004-03-28 | 63.202.108.164 |
2004-03-26 | 2004-03-26 | 63.202.108.168 |
2004-04-17 | 2004-04-17 | 63.202.108.170 |
2004-03-20 | 2004-03-20 | 63.202.108.171 |
2004-03-19 | 2004-03-19 | 63.202.108.176 |
2004-05-07 | 2004-05-07 | 63.202.108.180 |
2004-03-27 | 2004-03-27 | 63.202.108.182 |
2004-03-27 | 2004-03-27 | 63.202.108.183 |
2003-02-14 | 2004-04-09 | 63.202.108.184 |
2004-05-09 | 2004-05-09 | 63.202.108.195 |
2004-03-24 | 2004-03-24 | 63.202.108.202 |
2004-04-12 | 2004-04-12 | 63.202.108.203 |
2004-03-24 | 2004-03-24 | 63.202.108.207 |
2004-04-18 | 2004-04-18 | 63.202.108.208 |
2004-03-23 | 2004-03-23 | 63.202.108.221 |
2004-05-10 | 2004-05-10 | 63.202.108.223 |
2003-03-15 | 2003-03-15 | 63.202.108.232 |
2004-05-07 | 2004-05-07 | 63.202.108.236 |
2004-03-24 | 2004-03-24 | 63.202.108.239 |
2004-03-13 | 2004-03-13 | 63.202.108.240 |
2004-04-02 | 2004-04-02 | 63.202.108.243 |
2004-03-27 | 2004-03-27 | 63.202.108.247 |
2004-03-29 | 2004-03-29 | 63.202.108.249 |
2004-04-07 | 2004-04-07 | 63.202.108.250 |
2004-04-13 | 2004-04-13 | 63.202.108.255 |
2004-04-09 | 2004-04-09 | 63.202.109.0 |
2004-03-26 | 2004-03-26 | 63.202.109.7 |
2003-09-09 | 2003-09-09 | 63.202.109.10 |
2004-04-14 | 2004-04-14 | 63.202.109.12 |
2004-05-28 | 2004-05-28 | 63.202.109.13 |
2004-04-10 | 2004-04-10 | 63.202.109.16 |
2004-03-18 | 2004-03-18 | 63.202.109.21 |
2004-05-05 | 2004-05-05 | 63.202.109.22 |
2004-05-06 | 2004-05-06 | 63.202.109.26 |
2004-03-30 | 2004-03-30 | 63.202.109.29 |
2004-05-11 | 2004-05-11 | 63.202.109.32 |
2003-05-05 | 2003-05-05 | 63.202.109.36 |
2004-04-07 | 2004-04-07 | 63.202.109.37 |
2004-05-12 | 2004-05-12 | 63.202.109.40 |
2004-03-29 | 2004-03-29 | 63.202.109.41 |
2004-04-09 | 2004-04-09 | 63.202.109.42 |
2004-04-14 | 2004-04-14 | 63.202.109.43 |
2004-03-27 | 2004-03-27 | 63.202.109.45 | 1
2004-05-29 | 2004-05-29 | 63.202.109.51 | 1
2003-01-19 | 2004-05-30 | 63.202.109.53 | 2
2004-04-26 | 2004-04-26 | 63.202.109.58 | 1
2004-03-20 | 2004-03-20 | 63.202.109.60 | 1
2004-04-18 | 2004-04-18 | 63.202.109.62 | 1
2004-04-25 | 2004-04-25 | 63.202.109.65 | 1
2004-04-19 | 2004-04-19 | 63.202.109.71 | 1
2004-03-31 | 2004-03-31 | 63.202.109.74 | 1
2004-03-25 | 2004-03-25 | 63.202.109.78 | 1
2004-05-13 | 2004-05-13 | 63.202.109.81 | 1
2003-10-10 | 2003-10-10 | 63.202.109.84 | 1
2004-04-11 | 2004-04-11 | 63.202.109.90 | 1
2004-05-08 | 2004-05-08 | 63.202.109.93 | 1
2003-09-22 | 2003-12-01 | 63.202.109.94 | 2
2004-04-13 | 2004-04-13 | 63.202.109.95 | 1
2003-10-25 | 2003-10-25 | 63.202.109.105 | 1
2004-05-11 | 2004-05-11 | 63.202.109.108 | 1
2003-01-18 | 2003-01-18 | 63.202.109.112 | 3
2004-05-27 | 2004-05-27 | 63.202.109.114 | 1
2004-04-07 | 2004-04-07 | 63.202.109.116 | 1
2004-03-21 | 2004-03-21 | 63.202.109.122 | 1
2004-05-10 | 2004-05-10 | 63.202.109.123 | 2
2003-04-23 | 2003-04-28 | 63.202.109.127 | 58
2003-10-05 | 2003-10-05 | 63.202.109.128 | 1
2003-05-18 | 2004-05-09 | 63.202.109.132 | 2
2004-04-02 | 2004-04-02 | 63.202.109.134 | 1
2004-04-24 | 2004-04-24 | 63.202.109.136 | 1
2004-04-03 | 2004-04-03 | 63.202.109.143 | 1
2004-04-03 | 2004-04-03 | 63.202.109.150 | 1
2004-05-11 | 2004-05-11 | 63.202.109.155 | 1
2004-04-15 | 2004-04-15 | 63.202.109.156 | 1
2004-04-14 | 2004-04-14 | 63.202.109.163 | 1
2004-03-30 | 2004-03-30 | 63.202.109.164 | 1
2004-04-03 | 2004-04-03 | 63.202.109.166 | 1
2004-03-21 | 2004-03-21 | 63.202.109.169 | 1
2003-09-20 | 2003-09-20 | 63.202.109.170 | 1
2003-10-06 | 2003-10-06 | 63.202.109.172 | 1
2003-12-08 | 2003-12-08 | 63.202.109.177 | 1
2004-03-26 | 2004-03-26 | 63.202.109.181 | 1
2004-04-12 | 2004-04-12 | 63.202.109.186 | 1
2004-05-06 | 2004-05-06 | 63.202.109.189 | 1
2003-09-16 | 2003-09-16 | 63.202.109.190 | 1
2004-03-21 | 2004-03-21 | 63.202.109.191 | 1
2004-04-16 | 2004-04-16 | 63.202.109.192 | 1
2004-04-26 | 2004-04-26 | 63.202.109.194 | 1
2004-04-12 | 2004-04-12 | 63.202.109.197 | 1
2004-02-13 | 2004-02-13 | 63.202.109.199 | 1
2004-04-03 | 2004-04-03 | 63.202.109.200 | 1
2004-04-19 | 2004-04-19 | 63.202.109.202 | 1
2004-05-04 | 2004-05-04 | 63.202.109.207 | 1
2004-03-17 | 2004-03-17 | 63.202.109.210 | 1
2003-08-23 | 2003-08-23 | 63.202.109.212 | 1
2004-04-03 | 2004-04-03 | 63.202.109.216 | 1
2003-08-26 | 2003-08-26 | 63.202.109.220 | 1
2004-03-29 | 2004-03-29 | 63.202.109.222 | 1
2004-05-27 | 2004-05-27 | 63.202.109.227 | 1
2003-12-24 | 2004-04-04 | 63.202.109.228 | 2
2003-11-18 | 2004-05-28 | 63.202.109.229 | 3
2004-04-16 | 2004-04-16 | 63.202.109.230 | 1
2004-05-11 | 2004-05-11 | 63.202.109.232 | 1
2004-05-28 | 2004-05-28 | 63.202.109.233 | 1
2003-09-04 | 2003-09-19 | 63.202.109.235 | 3
2003-10-07 | 2003-10-07 | 63.202.109.245 | 1
2004-04-25 | 2004-04-25 | 63.202.109.248 | 1
2004-04-25 | 2004-04-27 | 63.202.109.249 | 2
2004-03-28 | 2004-03-28 | 63.202.109.251 | 1
2004-04-07 | 2004-04-07 | 63.202.109.253 | 1
2004-04-11 | 2004-04-11 | 63.202.109.254 | 1
2004-04-27 | 2004-04-27 | 63.202.110.1 | 1
2004-05-11 | 2004-05-11 | 63.202.110.3 | 1
2003-12-17 | 2003-12-17 | 63.202.110.6 | 1
2004-03-28 | 2004-03-28 | 63.202.110.8 | 1
2004-05-28 | 2004-05-28 | 63.202.110.13 | 1
2004-05-27 | 2004-05-27 | 63.202.110.14 | 1
2004-05-29 | 2004-05-29 | 63.202.110.15 | 1
2004-05-03 | 2004-05-03 | 63.202.110.19 | 1
2004-04-10 | 2004-04-10 | 63.202.110.27 | 1
2003-04-29 | 2003-05-01 | 63.202.110.30 | 17
2004-03-20 | 2004-03-20 | 63.202.110.31 | 1
2003-11-07 | 2003-11-07 | 63.202.110.35 | 1
2004-03-24 | 2004-03-24 | 63.202.110.45 | 1
2004-03-23 | 2004-03-23 | 63.202.110.53 | 1
2004-05-31 | 2004-05-31 | 63.202.110.54 | 1
2004-04-03 | 2004-04-03 | 63.202.110.59 | 1
2004-04-28 | 2004-04-28 | 63.202.110.69 | 1
2003-05-14 | 2003-05-14 | 63.202.110.73 | 3
2004-04-22 | 2004-04-22 | 63.202.110.76 | 1
2004-04-03 | 2004-04-03 | 63.202.110.77 | 1
2004-03-17 | 2004-03-17 | 63.202.110.78 | 1
2004-03-23 | 2004-03-23 | 63.202.110.84 | 1
2004-02-06 | 2004-02-09 | 63.202.110.86 | 3
2004-04-23 | 2004-04-23 | 63.202.110.87 | 1
2004-04-24 | 2004-04-28 | 63.202.110.88 | 4
2003-10-19 | 2003-10-19 | 63.202.110.89 | 1
2004-04-18 | 2004-04-18 | 63.202.110.91 | 1
2003-12-03 | 2003-12-03 | 63.202.110.92 | 1
2003-09-09 | 2003-09-09 | 63.202.110.98 | 1
2004-04-25 | 2004-04-25 | 63.202.110.99 | 2
2004-04-02 | 2004-04-02 | 63.202.110.100 | 1
2004-04-15 | 2004-04-15 | 63.202.110.102 | 1
2004-04-10 | 2004-04-10 | 63.202.110.105 | 1
2003-03-12 | 2003-03-12 | 63.202.110.122 | 2
2004-04-07 | 2004-04-07 | 63.202.110.124 | 1
2004-05-29 | 2004-05-29 | 63.202.110.126 | 1
2004-04-21 | 2004-04-21 | 63.202.110.127 | 1
2004-03-19 | 2004-03-19 | 63.202.110.129 | 1
2004-04-14 | 2004-04-14 | 63.202.110.130 | 1
2004-03-22 | 2004-03-22 | 63.202.110.134 | 1
2004-04-25 | 2004-04-25 | 63.202.110.135 | 1
2004-03-24 | 2004-03-24 | 63.202.110.136 | 1
2004-05-15 | 2004-05-15 | 63.202.110.139 | 1
2004-04-14 | 2004-04-14 | 63.202.110.140 | 1
2004-04-23 | 2004-04-23 | 63.202.110.149 | 1
2004-05-13 | 2004-05-13 | 63.202.110.153 | 1
2004-04-08 | 2004-04-08 | 63.202.110.154 | 1
2004-05-28 | 2004-05-28 | 63.202.110.155 | 1
2004-05-28 | 2004-05-28 | 63.202.110.165 | 1
2004-04-28 | 2004-04-28 | 63.202.110.172 | 1
2004-04-02 | 2004-04-02 | 63.202.110.173 | 1
2004-05-07 | 2004-05-07 | 63.202.110.177 | 1
2004-04-19 | 2004-04-19 | 63.202.110.179 | 1
2004-05-15 | 2004-05-15 | 63.202.110.180 | 1
2004-05-06 | 2004-05-06 | 63.202.110.186 | 1
2004-04-10 | 2004-04-10 | 63.202.110.187 | 1
2003-09-23 | 2003-09-23 | 63.202.110.194 | 1
2004-03-25 | 2004-03-25 | 63.202.110.200 | 1
2003-10-29 | 2003-12-14 | 63.202.110.201 | 2
2003-01-14 | 2004-04-08 | 63.202.110.203 | 5
2004-05-31 | 2004-05-31 | 63.202.110.204 | 1
2004-04-27 | 2004-04-27 | 63.202.110.205 | 1
2004-04-06 | 2004-04-06 | 63.202.110.209 | 1
2004-05-27 | 2004-05-27 | 63.202.110.212 | 1
2003-05-30 | 2003-05-30 | 63.202.110.213 | 1
2004-05-28 | 2004-05-28 | 63.202.110.215 | 1
2004-05-02 | 2004-05-02 | 63.202.110.217 | 1
2004-03-21 | 2004-03-21 | 63.202.110.218 | 1
2004-05-11 | 2004-05-11 | 63.202.110.220 | 1
2003-09-21 | 2004-03-20 | 63.202.110.225 | 3
2004-03-29 | 2004-03-29 | 63.202.110.226 | 1
2004-03-27 | 2004-03-27 | 63.202.110.231 | 1
2004-03-09 | 2004-03-09 | 63.202.110.236 | 1
2004-04-20 | 2004-04-20 | 63.202.110.244 | 1
2004-04-10 | 2004-04-10 | 63.202.110.245 | 1
2004-04-20 | 2004-04-20 | 63.202.110.246 | 1
2004-04-15 | 2004-04-15 | 63.202.110.249 | 1
2004-04-18 | 2004-04-18 | 63.202.110.250 | 1
2003-12-09 | 2004-05-01 | 63.202.110.251 | 2
2003-08-20 | 2004-03-31 | 63.202.110.253 | 2
2003-05-21 | 2003-05-21 | 63.202.111.0 | 1
2003-01-15 | 2003-01-15 | 63.202.111.1 | 3
2004-04-18 | 2004-04-18 | 63.202.111.2 | 1
2004-03-18 | 2004-03-18 | 63.202.111.3 | 1
2003-03-31 | 2003-04-01 | 63.202.111.5 | 4
2004-04-07 | 2004-04-07 | 63.202.111.7 | 1
2004-04-29 | 2004-04-29 | 63.202.111.8 | 1
2004-04-02 | 2004-04-02 | 63.202.111.15 | 1
2004-03-25 | 2004-03-25 | 63.202.111.16 | 1
2003-11-09 | 2003-11-09 | 63.202.111.17 | 1
2004-05-01 | 2004-05-01 | 63.202.111.20 | 1
2003-04-20 | 2003-11-16 | 63.202.111.26 | 16
2003-12-06 | 2003-12-06 | 63.202.111.27 | 1
2004-03-17 | 2004-03-17 | 63.202.111.29 | 1
2003-12-12 | 2003-12-12 | 63.202.111.36 | 1
2003-07-15 | 2003-07-15 | 63.202.111.37 | 3
2004-03-30 | 2004-03-30 | 63.202.111.38 | 1
2004-05-05 | 2004-05-05 | 63.202.111.43 | 1
2004-05-09 | 2004-05-09 | 63.202.111.45 | 1
2004-04-08 | 2004-04-08 | 63.202.111.57 | 1
2004-04-08 | 2004-04-08 | 63.202.111.58 | 1
2004-04-13 | 2004-04-13 | 63.202.111.61 | 1
2003-08-30 | 2003-09-02 | 63.202.111.62 | 2
2003-12-10 | 2003-12-10 | 63.202.111.66 | 1
2004-04-24 | 2004-04-24 | 63.202.111.67 | 1
2004-04-05 | 2004-04-05 | 63.202.111.68 | 1
2004-03-27 | 2004-03-27 | 63.202.111.72 | 1
2004-03-26 | 2004-03-26 | 63.202.111.79 | 1
2003-09-23 | 2004-03-19 | 63.202.111.82 | 2
2004-04-06 | 2004-04-06 | 63.202.111.83 | 1
2004-03-18 | 2004-03-18 | 63.202.111.94 | 1
2003-09-08 | 2003-09-08 | 63.202.111.96 | 1
2004-03-28 | 2004-03-28 | 63.202.111.98 | 1
2004-04-14 | 2004-04-14 | 63.202.111.103 | 1
2004-04-10 | 2004-04-10 | 63.202.111.106 | 1
2004-03-25 | 2004-03-25 | 63.202.111.110 | 1
2004-03-17 | 2004-03-17 | 63.202.111.111 | 1
2004-04-16 | 2004-04-16 | 63.202.111.112 | 1
2003-12-03 | 2003-12-03 | 63.202.111.118 | 1
2004-04-21 | 2004-04-21 | 63.202.111.120 | 1
2004-04-06 | 2004-04-06 | 63.202.111.122 | 1
2004-03-25 | 2004-03-25 | 63.202.111.123 | 1
2004-05-28 | 2004-05-28 | 63.202.111.128 | 1
2004-03-31 | 2004-03-31 | 63.202.111.131 | 1
2004-05-10 | 2004-05-10 | 63.202.111.132 | 1
2004-05-13 | 2004-05-13 | 63.202.111.134 | 1
2004-03-25 | 2004-03-25 | 63.202.111.135 | 1
2004-03-19 | 2004-03-19 | 63.202.111.137 | 1
2004-03-28 | 2004-03-28 | 63.202.111.139 | 1
2004-03-17 | 2004-03-17 | 63.202.111.141 | 1
2004-05-04 | 2004-05-04 | 63.202.111.143 | 1
2004-04-26 | 2004-04-28 | 63.202.111.150 | 2
2003-05-28 | 2003-05-28 | 63.202.111.152 | 17
2004-04-15 | 2004-04-15 | 63.202.111.154 | 1
2004-02-27 | 2004-02-27 | 63.202.111.155 | 1
2004-05-03 | 2004-05-03 | 63.202.111.158 | 1
2004-05-10 | 2004-05-10 | 63.202.111.164 | 1
2004-05-08 | 2004-05-08 | 63.202.111.166 | 1
2003-11-08 | 2004-03-30 | 63.202.111.174 | 2
2004-05-29 | 2004-05-29 | 63.202.111.177 | 1
2004-05-14 | 2004-05-14 | 63.202.111.183 | 2
2004-04-29 | 2004-04-29 | 63.202.111.185 | 1
2004-04-27 | 2004-04-27 | 63.202.111.186 | 1
2004-02-29 | 2004-02-29 | 63.202.111.191 | 1
2004-04-20 | 2004-04-20 | 63.202.111.192 | 1
2003-10-12 | 2003-10-12 | 63.202.111.195 | 1
2004-03-17 | 2004-03-17 | 63.202.111.196 | 1
2004-05-26 | 2004-05-26 | 63.202.111.197 | 1
2004-05-07 | 2004-05-07 | 63.202.111.199 | 1
2004-05-28 | 2004-05-28 | 63.202.111.202 | 1
2004-04-15 | 2004-04-15 | 63.202.111.207 | 1
2004-04-06 | 2004-04-06 | 63.202.111.208 | 1
2004-03-19 | 2004-03-19 | 63.202.111.218 | 1
2004-05-15 | 2004-05-15 | 63.202.111.219 | 1
2004-03-31 | 2004-03-31 | 63.202.111.220 | 1
2004-04-08 | 2004-04-08 | 63.202.111.225 | 1
2004-03-22 | 2004-03-22 | 63.202.111.226 | 1
2003-11-04 | 2003-11-04 | 63.202.111.228 | 1
2003-05-12 | 2003-05-12 | 63.202.111.229 | 1
2004-05-13 | 2004-05-13 | 63.202.111.231 | 1
2004-05-01 | 2004-05-01 | 63.202.111.237 | 1
2004-01-01 | 2004-01-01 | 63.202.111.244 | 1
2004-04-21 | 2004-04-21 | 63.202.111.247 | 1
2004-04-27 | 2004-04-27 | 63.202.112.4 | 1
2004-04-26 | 2004-04-26 | 63.202.112.110 | 1
2004-03-30 | 2004-03-30 | 63.202.112.117 | 1
2004-05-06 | 2004-05-06 | 63.202.112.128 | 1
2003-12-21 | 2003-12-21 | 63.202.126.155 | 1
2003-02-12 | 2004-04-28 | 63.202.127.10 | 49
2004-05-27 | 2004-05-27 | 63.202.127.11 | 1
2002-12-11 | 2003-02-16 | 63.202.127.12 | 76
2002-12-11 | 2004-04-27 | 63.202.127.13 | 202
2002-12-13 | 2004-04-28 | 63.202.127.14 | 18
2003-09-04 | 2003-09-04 | 63.202.127.162 | 1
(595 rows)


--
Paul Vixie

[Christopher L. Morrow]

On Sun, 13 Jun 2004, Doug White wrote




> ----- Original Message ----
> From: "Paul Vixie" <***@vix.com

> : remotely manage their host ("give me your root passwords, trust me!") for a
> : annual fee of $(0.75*N). if the initial value of N were $500, you might b
> : able to get the people who need this service to pay for it. it's worth
> try
> : -
> : Paul Vixi
>

> If I read Paul's post correctly, then I would have to agree that the costs o
> cleaning up the problem customers should be placed on the customer (miscreant

the 'customer' is most often NOT the 'miscreant', they are more often tha
not your mother/sister/brother/innocent-user#35 penalizing them is
touchy proposition

-Chri

[Geoincidents]

----- Original Message -----
From: "Paul Vixie" <***@vix.com

> now, though, there's an opportunity to do a marketing U-turn on this
cabl
> and dsl providers in the USA can point to the national cybersecurity pla
an
> say that to comply with it they have to put infected computers i
cyberjail

Except that they don't HAVE to do this and so it's lying to customers an
other ISP's will tell the customers the truth (that they don't have to pa
these charges) and presto you are out of business

> refundable after one year if there are no further incidents. then offe
t
> remotely manage their host ("give me your root passwords, trust me!") fo
a
> annual fee of $(0.75*N). if the initial value of N were $500, you migh
b
> able to get the people who need this service to pay for it. it's worth
try

Paul, why don't you make this offer to all your relatives? Don't want th
job? NEITHER DO WE!! (hoping the relatives comment will invoke the memorie
of exactly what is required to do this

We are ISP's, we got into this business because we know how to network no
how to patch every OS on the planet. It's bad enough we have to filter emai
or customers go running off to another ISP but to provide security and dea
with patching and then on top of that explain to parents how their 14 yea
old compromised their machine by running something she downloaded off th
web so they really shouldn't sue us because someone got their CC and ban
account numbers

Geo

[Paul Vixie]

***@nls.net ("Geoincidents") writes

> > refundable after one year if there are no further incidents. the
> > offer to remotely manage their host ("give me your root passwords
> > trust me!") for an annual fee of $(0.75*N). if the initial value of
> > were $500, you might be able to get the people who need this service t
> > pay for it. it's worth a try
>
> Paul, why don't you make this offer to all your relatives? Don't want th
> job? NEITHER DO WE!! ... We are ISP's, we got into this business becaus
> we know how to network not how to patch every OS on the planet. ..

if you're not set up to offer this then don't. but sean's employer alread
has the trucks and the phonebanks, and they might be able to monetize
solution to this problem, and they should be encouraged to try it

> It's bad enough we have to filter email or customers go running off t
> another ISP but to provide security and deal with patching and then o
> top of that explain to parents how their 14 year old compromised thei
> machine by running something she downloaded off the web so they reall
> shouldn't sue us because someone got their CC and bank account numbers

as an ISP who knows how to network, the only thing i request of you is tha
if your customer is spewing virus segments at me, you give me a way to prov
that to you (that costs me less time and aggravation than blackholing you)
and that once proven, you will revoke the account until you're sure tha
the infestation, and the process errors which led to it, are gone. (sam
as if they were spamming, or controlling a ddos botnet, or etc.

if you won't do that then you should not complain when folks blackhole you
customers and otherwise treat you as a chemical polluter, like i treat sean'
network. an isp has to take responsibility for the output from thei
network, and the ones who won't, are going to be treated by their victim
as "bad internet neighborhoods". hopefully sean is ready to stop whinin
about that by this point in the thread. if not i can do another databas
extract for him
--
Paul Vixi

[[e-mail]]

[Owen DeLong]

[Rob Nelson]

>: now, though, there's an opportunity to do a marketing U-turn on this. cabl
>: and dsl providers in the USA can point to the national cybersecurity
>plan an
>: say that to comply with it they have to put infected computers in cyberjail
>: with a fee of $N to get these machines audited, and if found clean, put bac
>: on the net, noting that N doubles every time this process is invoked, an
>: that a deposit of $(0.5*N) is required as prepayment for the next incident
>: refundable after one year if there are no further incidents. then offer t
>: remotely manage their host ("give me your root passwords, trust me!") for a
>: annual fee of $(0.75*N). if the initial value of N were $500, you might b
>: able to get the people who need this service to pay for it. it's worth
>try
>: -
>: Paul Vixi
>

>If I read Paul's post correctly, then I would have to agree that the costs o
>cleaning up the problem customers should be placed on the customer (miscreant
>as opposed to the rest of us. This would be far more preferable than puttin
>in place controls by the respective ISP that would limit my own use of m
>connection, on which I have spent considerable time, money and education t
>make sure it is secure and beyond that, compliant with the ISP Acceptable Us
>policies

Yes, but then you have another problem. I get a virus - whoops, attached a
laptop without thinking. I clean it up myself, cause I'm feeling so
retarded for getting the virus that I damn well ain't sharing that with
anyone. In the meantime, the ISP noticed the virus and put a block on

Do I have to pay them $500 to get it removed? Definitely cheaper to cancel
service and go with someone else at that point

Rob Nelso
***@vt.ed

[Christopher L. Morrow]

On Sun, 13 Jun 2004, John Curran wrote


> At 4:21 AM +0000 6/13/04, Christopher L. Morrow wrote
>
> >We have methods of dealing with these abuse problems today, unfortanatel
> >as Paul Vixie often points out there are business reasons why thes
> >problems persist. Often the 'business' reason isn't th
> >tin-foil-hat-brigade's reason so much as 'we can't afford to keep thes
> >abuse folks around since they don't make money for the company'

> I'll argue that we have don't effective methods of dealing with this today
> and it's not the lack of abuse desk people as much as the philosophy o
> closing barn doors after the fact. The idea that we can leave everythin
> wide open for automated exploit tools, and then clean up afterward
> manually with labor-intensive efforts is fundamentally flawed

that was the last part of my post, initial installs and supportable (en
user supportable) security really is the only way. (or that's my thoughts

[Randy Bush]

>>> One could imagine changing the paradigm (never easy) so tha
>>> the normal Internet service was proxied for common application
>>> and NAT'ed for everything else... This wouldn't eliminate all th
>>> problems, but would dramatically cut down the incident rate
>>
>>> If a site wants wide-open access, just give it to them. If that turn
>>> out to cause operational problems (due to open mail proxies, spa
>>> origination, etc), then put 'em back behind the relays
>
>>guilty until proven innocent, eh? thanks mr ashcroft
>
> Randy, are you objecting to the model for initial connectivity
> or the throwing them back behind relays w/o a formal trial

the former, see previous post about the e2e interne

if you can actually diagnose bad traffic, then you ma
have a right to ac

rand

[Sean Donelan]

On Sun, 13 Jun 2004, John Curran wrote
> I'll argue that we have don't effective methods of dealing with this today
> and it's not the lack of abuse desk people as much as the philosophy o
> closing barn doors after the fact. The idea that we can leave everythin
> wide open for automated exploit tools, and then clean up afterward
> manually with labor-intensive efforts is fundamentally flawed

Selling people barn doors and barn door audits is easier than figurin
out how the rustlers are getting the horses. The problem is the horse
aren't being rustled(?) through the barn doors. If they were, you woul
expect to see a difference between barns with doors and barns withou
doors. But in practice, we see people with and without firewalls wit
infected computers. Network level controls aren't as effective a
some people hope at stopping many things. ISPs should stop porn, ISP
should stop music sharing, ISPs should stop viruses, ISPs shoul
stop <insert here>. Yet somehow users manage to find a way aroun
all of them

What are good predictors? There aren't any great ones, but there ar
some. Can we use them effectively

So what makes some users more likely or less likely to have infecte
computers? How do they become infected, but other users don't? What'
different between the two groups

[Dave Howe]

Sean Donelan wrote
> Selling people barn doors and barn door audits is easier than figurin
> out how the rustlers are getting the horses. The problem is the horse
> aren't being rustled(?) through the barn doors. If they were, you woul
> expect to see a difference between barns with doors and barns withou
> doors. But in practice, we see people with and without firewalls wit
> infected computers. Network level controls aren't as effective a
> some people hope at stopping many things. ISPs should stop porn, ISP
> should stop music sharing, ISPs should stop viruses, ISPs shoul
> stop <insert here>. Yet somehow users manage to find a way aroun
> all of them
> So what makes some users more likely or less likely to have infecte
> computers? How do they become infected, but other users don't? What'
> different between the two groups
Skill, Desire and Luck - not always in that order

I usually set out my stall on this one by making a the following
assumptions

1) any protective measure that relies on users having common sense will
inevitably lead to astonishment at how uncommon common sense is (core rule

2)Warning messages are now so common users don't read them, and web
popup boxes even more so. By simple extension therefore, no warning
message is of any value - users will read just enough to discover how to
make it go away, and if the obvious way of doing so works, won't trouble
themselves further. (case in point - "how did that porn dialler get
there? I only visited a website or two. Yeah, there was some sort of
popup box but I closed it"

3) not all machines will be vulnerable - either by skill, initial
design, patching dilligence or obsolescence, some machines will be
inherently protected against any given outbreak. Downside there is -
said users will invariably decide they don't *need* to take protective
measures because this one attack couldn't affect them (case in point -
most linux users do not have AV software of any type, despite at least
one being free and open source

4) any scheme that relies on blocking users from what they want to do
will be bypassed by at least some of those users; once some of the users
know how to do it, the blackhats won't be far behind teaching their
creations how to do it too, and the greyhats in writing little pretty
gui tools to do it automagically - relying that users knowing how to
bypass lockdowns being skilled enough to look after their own security
therefore violates rule

5) anything that relies on convincing the users (or better yet their
machine) that the action *is* what they want to do is onto a winner; see
rule 3 and indeed rule 1 for details

so back to your list

> ISPs should stop porn
not going to work - prohibition just makes it harder to regulate stuff,
even leaving aside the moral issues of trying to block online what can
be bought in most newsagents

> ISPs should stop music sharing
why? users obviously want to do it, and in many places it is not a
criminal act (copyright violations being civil not criminal in most
countries
ISPs should of course co-operate with any lawful warrant or court order,
and (for practical purposes) try to limit their own expenses in having
to deal with copyright violations on websites and so forth but in the UK
(Not sure about elsewhere) the real problem is commercial pirates
selling dodgy copies from stalls or car boots, and that predates the web
(and indeed the CD

> ISPs should stop viruses
Sure. I don't think that should be free though - plenty of services out
there offer filtered, reactive web access to remove all those nasty
worms, email viruses and so forth as fast as is possible. Doing that
work *costs* and has little or nothing to do with the business of
pushing bits down wires. Yey the free market...

> ISPs should stop <insert here>
damn right. <insert here> has always bugged me :

[John Curran]

At 6:31 AM -0400 6/13/04, Sean Donelan wrote
>If they were, you would expect to see a difference between barns wit
>doors and barns without doors. But in practice, we see people with an
>without firewalls with infected computers.

If you're asserting that having firewalls in the path doesn't hav
any impact on rate of infection, please provide a link to this data
Sure, I've even seen infected computers in rooms that don't (o
should not have had) any connectivity, but that just means it i
not a perfect world. Lot's of things make it through firewall
(email-based worms come to mind) but from what I've seen the
are quite effective at protecting networks of otherwise helples
comes-out-of-the-box-wide-open PC's

/Joh

[Dave Howe]

John Curran wrote
> If you're asserting that having firewalls in the path doesn't hav
> any impact on rate of infection, please provide a link to this data
Actually, it doesn't - practical experience on a medium sized corporate
network is that the firewall protects perfectly against TCP/IP worms -
right up to the first time some senior management bozo plugs his laptop
onto the network that his teen son was playing online games with all
last night... and has no effect at all on email or website/browser 'sploits

[John Curran]

At 6:31 AM -0400 6/13/04, Sean Donelan wrote
>Network level controls aren't as effective a
>some people hope at stopping many things. ISPs should stop porn, ISP
>should stop music sharing, ISPs should stop viruses, ISPs shoul
>stop <insert here>. Yet somehow users manage to find a way aroun
>all of them

In a perfect world, ISPs shouldn't have to worry about content. Ther
is no way to "know" whether the user wants a particular message an
methods at guessing are always imperfect. Despite this, a lot of user
would like their ISP to try to do their best to filter spam and viruses ou
of their mail stream, etc. It really should be an local issue but users ask
so the service appears

However, distinguish content from access. Typical users, particularl
in broadband residential connections, have no desire to have anyon
remotely access their machine. The same is true with most smal
business customers. Upon arrival of their first Internet connection
the systems do not magically recognize that end-to-end now coul
be any endpoint in the Internet and install appropriate filters. Wh
doesn't it make sense to change the default model so that such ar
in place under the user demonstrates some understanding of th
situation by asking them to be removed

To add one more analogy to the mix, we blindly install on-ramps t
the freeway to anyone who asks and certainly a few folks kno
what is in store once connected. However, the vast majority o
ramps are connected to suburban driveways, skate board parks
and middle school playgrounds. It's amazing that we all ac
surprised when innocents get run over..

/Joh

[Bob K]

John Curran wrote

> Wh
> doesn't it make sense to change the default model so that such ar
> in place under the user demonstrates some understanding of th
> situation by asking them to be removed

I'd just like to point out that people are going to ask to be removed so
they can get their [IM client/IP phone software/webcam/filesharing
client/gaming server/???] working, _not_ because all of a sudden they
feel they have enough technical know-how to keep their computer from
getting compromised

There is also the problem that filtered service will create an
expectation that the ISP will magically stop everything, and of course
hell will be sending out their invoices when (not if) something makes it
through

[Owen DeLong]

[Owen DeLong]

[James Edwards]

[Matthew Sullivan]

Christopher L. Morrow wrote

>On Sat, 12 Jun 2004, John Curran wrote

>

>>The real challenge here is that the "default" Internet service i
>>wide-open Internet Protocol, w/o any safeties or controls. Thi
>>made a lot of sense when the Internet was a few hundred sites
>>but is showing real scaling problems today (spam, major viruses
>>etc.
>
>>One could imagine changing the paradigm (never easy) so tha
>>the normal Internet service was proxied for common application
>>and NAT'ed for everything else... This wouldn't eliminate all th
>>problems, but would dramatically cut down the incident rate
>>
>

>This sounds like a fantastic idea, for instance: How much direct IP doe
>joe-average Internet user really require? Do they require anything mor
>than imap(s)/pop(s)/smtp(+tls) and dns/http/https ? I suppose they als
>need
>1) internet gamin
>2) voi
>3) kazaa/p2p-app(s)-of-choic
>4) I

>Actually I'm sure there are quite a few things they need, things whic
>require either very smart NAT/Proxy devices or open access. The filterin
>of IP on the broad scale will hamper creativity and innovation. I'm fairl
>certain this was not what we want in the long term, is it
>

I acutally suggested something like this at the recent AusCERT 2004
conference... It's not such a bad idea...

The real question being "why are we giving mum's and dad's who sign up
to the internet, and know nothing about either the Internet or
computers, full unrestricted incoming and outgoing access...?" ...
answer because the more bandwidth they use the more the ISP earns... so
the ISPs don't care (in some cases) if the mum's and dad's get trojaned,
because it's all money

My suggestion to the AusCERT delegates was to introduce a new default
service which has very limited access, and if people ask for more, give
them the access after they have read through various 'educational'
pages.... Perhaps a simple online quiz at the end -just 3-5 questions
with the answers being very clearly explained in the previous pages -
just to show the people have actually read the pages, rather than
skipped to the end and hit 'I accept'

I also suggested that if ISPs have the technology perhaps a simple IP
pools method of allocating the users IP, where they could turn on and
turn off access to certain protocols - eg: have a pool for P2P users, a
pool for VOIP etc..

/ Ma

[Matthew Sullivan]

Owen DeLong wrote

> Frankly, I don't want to have to read the *@#( tutorial. I should at
> leas
> have the option of skipping to the questions. I don't mind "You must b
> this tall to ride." I do mind "Now we, who have been in business fo
> fewer years than you have been running backbone routers, are going t
> give you a brief tutorial on internet security.

No, I referred to the questions as simple questions where someone would
have had to have read the tutorial (or already knows the answers) to get
a less restricted account....

There would of course be the option to say 'I want a completely
unrestricted incoming and outgoing account, I do know what I'm doing'...

The point being that the majority of mum's, dad's and indeed small
businesses don't have a clue about what they are doing, and most just
want to be able to browse the web, do some internet banking or shopping,
and have access to email

Your

Ma

[Owen DeLong]

[Matthew Sullivan]

Owen DeLong wrote

> Until they sign up for Vonage, get hooked on that new multiplayer
> realtim
> game, discover that they can share music with their friends, or jus
> want to see what that next killer-app is all about

> Oh, yeah, there's also IRC, YIM, AIM, etc

> Those are just the applications I ran up against when I put a stric
> firewall in for my parents (who I regard as being pretty typical of th
> we don't know what internet is, but, we want it mom/dad set).

I'm not saying don't permit them at all, I'm saying create a default
account where access is not available, where the customers have to know
a bit about what's going on to make that default blocked account into a
default not blocked account - there gives the ability to force
education. You could also then add extra terms into the equation - as
part of the 'non blocked account agreement' the customer has a 'bond'
where they get infected without due dilligence, they loose their
bond.... there are hundreds of ideas, some which will work some which
won't - the key point is most of the ISPs in the USA (but not only them,
other countries too) are doing NOTHING about the problem except saying
'it costs money, whose going to pay?'... Well why should I pay, when
your customers DDoS me? Why should I pay to keep my email free of spam
sent via your customers..? Why should I pay for firewalls and spend all
my time looking for hacking incidents because you don't want to pay for
a little education....

> And, there's still the question of funding. Adding simple filter
> costs money (labor, if nothing else). Adding stateful inspection filter
> costs more money (same labor, roughly, but, most provider-side router
> don't do stateful inspection, at least not in a scalable way). The fe
> that do, usually require additional hardware options (ASPIC, for
> example)

> Who should pay for that? I don't think the responsible clueful customer
> of an ISP should have to subsidize the clueless, even if the clueless ar
> the majority

No you're right, but then the large ISPs should have working abuse
desks, and they should are responsible for traffic originating from
their network. It's only a matter of time before something will
break... The way things are going now with infections and exploits, I'm
surprised people are still signing up for the internet, if something is
not done about the problems sooner rather than later I guarentee you the
Internet will go the way of the CB radio.... Noise will drown out the
signal, people will stop using it because it is no longer useable,
people who can afford it will setup on either own private frequency, the
noise will continue until there are just a few die hards left, at which
point the noise will slow and stop because there is no fun in drowning
those few anymore, and all channels will become disused and quiet.....
Then all those large ISPs out there who say 'filtering costs money why
should we...?' will realise that it's too late to fix the problem, and
they will either diversify or die

/ Ma

PS: Owen, this mail is not directed specifically at you, or anyone in
particular, I'm just on my soap box again

[Owen DeLong]

[Paul Vixie]

> > so you aren't going to google for "chemical polluter business model", huh
>
> I hope you also google for Nonpoint Source Pollution
>
> ISPs don't put the pollution in the water, ISPs are trying to clean u
> the water polluted by others. ISPs are spending a lot of money cleanin
> up problems created by other people

where you got it from before you dumped it into the stream that feeds me i
a yet another problem that i'd rather you resolved without my involvement

[Per Gregers Bilse]

Just because one can find a counter argument against an argumen
doesn't mean the original argument is invalid

Do you lock your front door when you leave home? Yes
Can a burglar break in? Yes
Is the police responsible for maintaining law and order? Yes

Are car owners responsible for keeping their cars roadworthy? Yes
Are road authorities responsible for keeping the roads carworthy? Yes
Are car manufactureres responsible for manufacturing roadworthy cars? Yes

Do pilots have responsibility? Yes
Are air traffic controllers responsible for air traffic? Yes

Are you allowed to shout "FIRE" in a crowded theatre? Yes

Does paper wrap rock? Yes
Do scissors cut paper? Yes
Does rock blunt scissors? Yes

"Yes to all?" Yes

Anybody care to mention Hitler and Nazis? Yes? Please? Pretty please

-- Pe

[Dave Howe]

Per Gregers Bilse wrote

> Just because one can find a counter argument against an argumen
> doesn't mean the original argument is invalid
Sometimes it does :

disproof by counterexample is a valid technique

[Per Gregers Bilse]

On Jun 13, 4:15pm, Dave Howe <***@gmx.co.uk> wrote
> disproof by counterexample is a valid technique

Debating techniques belong in debating societies, not NANOG

Bring back com-priv

-- Pe

[Rafi Sadowsky]

How the H*** did "Hitler and Nazis" relate to the subject ??

Susan ???

--
Raf

## On 2004-06-13 16:08 +0100 Per Gregers Bilse typed

PGB>
PGB>
PGB> Anybody care to mention Hitler and Nazis? Yes? Please? Pretty please
PGB>
PGB> -- Pe
PGB>
PGB>

[Randy Bush]

> How the H*** did "Hitler and Nazis" relate to the subject ??

google for godwin's la

i thought i had invoked it when mentioning ashcrof

rand

[Alex Bligh]

--On 13 June 2004 16:15 +0100 Dave Howe <***@gmx.co.uk> wrote

> disproof by counterexample is a valid technique

only where the "law of excluded middle holds" true - that means i
everything is black & white with no shades of grey

It is quite clear if nothing else from the circularity of thread
on NANOG about this sort of stuff, the number of iteration
around the circles, and the number of years this has been going o
that there is no silver bullet. So there are two other possibilities

a) There is at least one (probably more) type of action which mitigate
but does not fully solve the problem [in which case telling u
why solution X doesn't work because it doesn't address example
is not much help, as by assumption no solution is perfect], o

b) There are no types of action which mitigate the problem. In whic
case go do something more interesting than read/write NANOG o
the subject

There are a lot of (a)'s that are quite helpful. If anyone thinks
for example, that installing a decent firewall doesn't hel
prevent intrusions (no, it doesn't stop them all), or online acces
to OS fixes (ditto), I would suggest some statistics to show thi
would be useful

Ale

[Smith, Donald]

First are the consumers willing to pay for a "safer" interne
DSL/dial/isdn
I believe if they were there would be a safer service available. I hav
seen several "secure" isp's fail in the las
few years. If you have any data that shows that there is a market for
more secure dialup/DSL/isdn... please share it

2nd blaming infected machines on the internet is similar to blaming you
postal carrier for bringing you junk mail and bills. About 1/2 of all o
the large "infection" events on the internet are the result of peopl
running unpatched unsecured applications on their machines. The othe
half of the infections I see are due to an end user opening an email an
running an attachment. Even with a secure OS this simple method o
infection will continue to work

How and when did it become the responsibility of the ISP to protect th
end users machines?=2
Do ISP's get paid to protect end user machines
If you want to blame someone maybe the company that provided th
insecure os that requires monthly patches to fix portions of the broke
code they sold. Or you could blame the end users who open unknow
attachments.=2

I would like a real solution to the problem. Simply blocking ports i
not successful.=2
So I recommend 2 steps.=2

First buy OS's that are more secure out of the box

2nd Teach users NOT to click on every thing they see

***@qwest.com GCI
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDC
pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDC
Brian Kernighan jokingly named it the Uniplexed Information an
Computing System (UNICS) as a pun on MULTICS

> -----Original Message----
> From: owner-***@merit.edu [mailto:owner-***@merit.edu] On=2
> Behalf Of Matthew Sulliva
> Sent: Sunday, June 13, 2004 5:02 P
> To: nano
> Subject: Re: "Default" Internet Servic
>=2
>=2
>=2
> Christopher L. Morrow wrote
>=2
> >On Sat, 12 Jun 2004, John Curran wrote
>
> > =2
>
> >>The real challenge here is that the "default" Internet service i
> >>wide-open Internet Protocol, w/o any safeties or controls. Thi
> >>made a lot of sense when the Internet was a few hundred=2
> sites, but is=2
> >>showing real scaling problems today (spam, major viruses
> >>etc.
> >
> >>One could imagine changing the paradigm (never easy) so that the=2
> >>normal Internet service was proxied for common applications=2
> and NAT'ed=2
> >>for everything else... This wouldn't eliminate all the=2
> problems, but=2
> >>would dramatically cut down the incident rate
> >> =2
> >
>
> >This sounds like a fantastic idea, for instance: How much direct IP=2
> >does joe-average Internet user really require? Do they=2
> require anything=2
> >more than imap(s)/pop(s)/smtp(+tls) and dns/http/https ? I=2
> suppose they=2
> >als
> >need
> >1) internet gamin
> >2) voi
> >3) kazaa/p2p-app(s)-of-choic
> >4) I
>
> >Actually I'm sure there are quite a few things they need,=2
> things which=2
> >require either very smart NAT/Proxy devices or open access. The=2
> >filtering of IP on the broad scale will hamper creativity and=2
> >innovation. I'm fairly certain this was not what we want in the long=2
> >term, is it
> > =2
>
> I acutally suggested something like this at the recent AusCERT 2004=2
> conference... It's not such a bad idea...
>=2
> The real question being "why are we giving mum's and dad's=2
> who sign up=2
> to the internet, and know nothing about either the Internet or=2
> computers, full unrestricted incoming and outgoing access...?" ...=2
> answer because the more bandwidth they use the more the ISP=2
> earns... so=2
> the ISPs don't care (in some cases) if the mum's and dad's=2
> get trojaned,=2
> because it's all money
>=2
> My suggestion to the AusCERT delegates was to introduce a new default=2
> service which has very limited access, and if people ask for=2
> more, give=2
> them the access after they have read through various 'educational'=2
> pages.... Perhaps a simple online quiz at the end -just 3-5=2
> questions=2
> with the answers being very clearly explained in the previous pages -=2
> just to show the people have actually read the pages, rather than
> skipped to the end and hit 'I accept'.
>
> I also suggested that if ISPs have the technology perhaps a simple IP
> pools method of allocating the users IP, where they could turn on and
> turn off access to certain protocols - eg: have a pool for
> P2P users, a
> pool for VOIP etc...
>
> / Mat
>
>
>
>

[Matthew Sullivan]

Smith, Donald wrote

>First are the consumers willing to pay for a "safer" interne
>DSL/dial/isdn

Why should they have to

>I believe if they were there would be a safer service available. I hav
>seen several "secure" isp's fail in the las
>few years. If you have any data that shows that there is a market for
>more secure dialup/DSL/isdn... please share it

No, but it won't belong before you will find half a dozen reasons why as
an ISP you will want to do it - but then it may be too late

>2nd blaming infected machines on the internet is similar to blaming you
>postal carrier for bringing you junk mail and bills

Cra

> About 1/2 of all o
>the large "infection" events on the internet are the result of peopl
>running unpatched unsecured applications on their machines. The othe
>half of the infections I see are due to an end user opening an email an
>running an attachment

Correc

> Even with a secure OS this simple method of infection will continue to work

Correc

However you are ignoring the fact that once the machine is infected, the
machine can be used by hundreds of people (skript kiddies) to damage
other parts of the internet, further they can (and are) being used by
organised crime to extort money out of large financial institutions and
companies, and that's not to mention DDoS's on the smaller people who
are just in the way

>How and when did it become the responsibility of the ISP to protect th
>end users machines?

It hasn't, however the data coming from an ISPs network has always been
the responsibility of the ISP.... and I would suggest if you cannot stop
the endusers getting infected, then you should look at stopping those
machines from abusing other machines on the internet.... If you will
not do that you should not be peered

>Do ISP's get paid to protect end user machines

No, they get paid for traffic, which is the reason some ISPs out there
don't care if their customers are DDoSing anothers network

>If you want to blame someone maybe the company that provided th
>insecure os that requires monthly patches to fix portions of the broke
>code they sold. Or you could blame the end users who open unknow
>attachments.

Yup, we've been doing that for years, and they have been fixing things
as fast as possible (not always, and not until more recently) however
they are making steps in the right direction, so I feel it's about time
ISP's started taking some of the responsibility for traffic on their
network. As far as the attachments go, education is the only way - and
if they cannot be educated they shouldn't be on the Internet

>I would like a real solution to the problem. Simply blocking ports i
>not successful.
>So I recommend 2 steps.

>First buy OS's that are more secure out of the box

That's not going to happen anytime soon, even with Microsoft starting to
follow the 'right' road

>2nd Teach users NOT to click on every thing they see
>

..and how are you going to do that? If you give a user a $10 account
where they have full internet access they click on everything, then they
get infected, their machine is controlled by someone else across the
world and is used for DDoS attacks or spam (or..hacking, or...?) .. what
are you going to do to educate them in the middle....? What is the ISP
going to do to make sure that the enduser has been educated? What are
you the ISP going to do to ensure the machine that was infected has now
been disinfected...

I don't expect you the ISP to solve all these problems, nor do I expect
you the ISP to stop your users from getting infected.... However you the
ISP are responsible for traffic coming from and going to your users, and
most of us don't care if you want to allow your users to get infected,
however we do care if you allow your customers to attack us.... Whether
it be an attack in the form of spam, DDoS or trojan/virus spreading

/ Ma

[Scott Weeks]

: Regulations could fix that

: The US Postal Service has the Postal Inspection Service. They hav
: jurisdiction anywhere the mail goes. The post office didn't creat
: the Anthrax, they delivered the envelopes as addressed

: Most railroads have railroad police with jurisdiction anywhere th
: railroad tracks go. Some railroad police departments hav
: trans-national jurisdiction in multiple countries

:: My suggestion to the AusCERT delegates was to introduce a new defaul
:: service which has very limited access, and if people ask for more, giv
:: them the access after they have read through various 'educational
:: pages.... Perhaps a simple online quiz at the end -just 3-5 question
:: with the answers being very clearly explained in the previous pages
:: just to show the people have actually read the pages, rather tha
:: skipped to the end and hit 'I accept'

::: All other traffic will be blocked. This means that if you ar
::: using any other internet-based applications, such as on-line gaming
::: peer to peer file-sharing, etc., they will not work with Censorco
::: These applications have been demonstrated to be unsafe, and, are no
::: accessible while still using the TrainingWheels(tm) service. If yo
::: want to do this, you will need to contact your account representative
::: pass a brief internet knowledge and security test, and sign th
::: appropriate waiver. We will then remove the TrainingWheels(tm) fro
::: your internet service and you will receive a full, unfiltered, unsaf
::: connection to the internet

Four words why these regulatory/testing things won't work: It's a globa
network. It has been shown across many wars that global regulation isn'
going to work..

: Also the problem of off shoring spam probably should be taken int
: consideration. No matter how good the plan is if a country is willin
: not to enforce it there will be a problem

<ding, ding, ding> We have a winner! Someone please give sgorman1
cigar for winning the NA vs. global network game in this round

scot

[Smith, Donald]

***@qwest.com GCI
pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDC
Brian Kernighan jokingly named it the Uniplexed Information an
Computing System (UNICS) as a pun on MULTICS

> -----Original Message----
> From: owner-***@merit.edu [mailto:owner-***@merit.edu] On=2
> Behalf Of Matthew Sulliva
> Sent: Monday, June 14, 2004 3:26 P
> Cc: nano
> Subject: Re: "Default" Internet Servic
>=2
>=2
>=2
> Smith, Donald wrote
>=2
> >First are the consumers willing to pay for a "safer" internet=2
> >DSL/dial/isdn
>
> Why should they have to

Because it costs money to mitigate the attacks coming from thei
infected machines
It takes people and people want to be paid. Given a larger securit
abuse team we could do more

>=2
> >I believe if they were there would be a safer service=2
> available. I have=2
> >seen several "secure" isp's fail in the last few years. If=2
> you have any=2
> >data that shows that there is a market for a more secure=2
> >dialup/DSL/isdn... please share it
>
> No, but it won't belong before you will find half a dozen=2
> reasons why as=2
> an ISP you will want to do it - but then it may be too late
>=2
> >2nd blaming infected machines on the internet is similar to blaming=2
> >your postal carrier for bringing you junk mail and bills
>
> Cra
>=2
> > About 1/2 of all o
> >the large "infection" events on the internet are the result=2
> of people=2
> >running unpatched unsecured applications on their machines.=2
> The other=2
> >half of the infections I see are due to an end user opening an email=2
> >and running an attachment
>
> Correc
>=2
> > Even with a secure OS this simple method of infection will=2
> continue to=2
> > work
>
> Correc
>=2
> However you are ignoring the fact that once the machine is=2
> infected, the=2
> machine can be used by hundreds of people (skript kiddies) to damage=2
> other parts of the internet, further they can (and are) being used by=2
> organised crime to extort money out of large financial=2
> institutions and=2
> companies, and that's not to mention DDoS's on the smaller people who=2
> are just in the way

Agreed

>=2
> >How and when did it become the responsibility of the ISP to=2
> protect the=2
> >end users machines
>
> It hasn't, however the data coming from an ISPs network has=2
> always been=2
> the responsibility of the ISP.... and I would suggest if you=2
> cannot stop=2
> the endusers getting infected, then you should look at stopping those=2
> machines from abusing other machines on the internet.... If you will=2
> not do that you should not be peered

AFAIK all major ISP's are processing 1000's of infected host. Thi
includes notification of the end user
assistence in cleaning and identifing the infections and responses t
the people providing the lists of infected hosts

>=2
> >Do ISP's get paid to protect end user machines
>
> No, they get paid for traffic, which is the reason some ISPs=2
> out there=2
> don't care if their customers are DDoSing anothers network

Most US ISP's end users (DSL/DIAL/ISDN/CABLE) are on a flat rate.=2
The end user is not charged for the bandwidth
I have received NO PUSHBACK from sales on any of the projects we hav
worked on to mitigate the effects of bots/worms/virii on our network.
personally don't believe there are ISP's that don't mitigate so they ca
get the extra $$$ the worm traffic is generating

>=2
> >If you want to blame someone maybe the company that provided the=2
> >insecure os that requires monthly patches to fix portions of=2
> the broken=2
> >code they sold. Or you could blame the end users who open unknown=2
> >attachments
>
> Yup, we've been doing that for years, and they have been=2
> fixing things=2
> as fast as possible (not always, and not until more recently) however=2
> they are making steps in the right direction, so I feel it's=2
> about time=2
> ISP's started taking some of the responsibility for traffic on their=2
> network. As far as the attachments go, education is the only=2
> way - and
> if they cannot be educated they shouldn't be on the Internet.

How will you keep them off?


>
> >I would like a real solution to the problem. Simply blocking
> ports is
> >not successful. So I recommend 2 steps.
> >
> >First buy OS's that are more secure out of the box.
> >
> That's not going to happen anytime soon, even with Microsoft
> starting to
> follow the 'right' road.

I believe there are OSes that are much more secure out of the box then
Microsoft's products.

>
> >2nd Teach users NOT to click on every thing they see.
> >
> >
> ...and how are you going to do that? If you give a user a

Education as you stated above.

> $10 account
> where they have full internet access they click on
> everything, then they
> get infected, their machine is controlled by someone else across the
> world and is used for DDoS attacks or spam (or..hacking,
> or...?) .. what
> are you going to do to educate them in the middle....? What
> is the ISP
> going to do to make sure that the enduser has been educated?
> What are
> you the ISP going to do to ensure the machine that was
> infected has now
> been disinfected...?

You have not convinced me that either of these is currently an ISP
responsibility.

>
> I don't expect you the ISP to solve all these problems, nor
> do I expect
> you the ISP to stop your users from getting infected....
> However you the
> ISP are responsible for traffic coming from and going to your
> users, and
> most of us don't care if you want to allow your users to get
> infected,
> however we do care if you allow your customers to attack
> us.... Whether
> it be an attack in the form of spam, DDoS or trojan/virus spreading.

As an ISP I am responsible to ensure my users can send and receive
packets.

Want to contribute?
Consider volunteering time at one of the public internet security sites.
Complaining that ISP's are not doing enough is not productive.


>
> / Mat
>
>
>
>

[Owen DeLong]

[Owen DeLong]

[Adi Linden]

> It's not crap. Infected machines are no more the fault of the internet tha
> junkmail in your mailbox is the fault of the post office. There's literall
> no difference to the model. The post office delivers mail that is addresse
> to you. They don't care if it's junk mail or not. They deliver it

So what about little envelopes with white powder? Does the post office
still have an obligation to deliver it or should they be concerned about
the welfare of their customers? Perhaps they should insist that customers
are properly vaccinated...

Point I am making is that the post office is not responsible and/or liable
for the content of the packages they deliver. However, if they deliver
packages that are obviously visibly dangerous to the recipient they have
an obligation to investigate and not deliver the package.

> Most residential ISPs get paid the same whether the customer spew
> abuse or not. Their costs go up some when they get abuse complaint
> and when abuse starts using more bandwidth, so, for the most part, mos
> residential ISPs have no incentive to support abuse, but, not enoug
> incentive to pay to staff an abuse department sufficiently to be trul
> responsive. Further, most abuse departments don't get enough suppor
> from management when the sales and marketing departments come whinin
> about how much revenue that abusing customer produces each month
> This is one of the unfortunate realities of a free-market economy. I
> doesn't always tie profit to doing the right thing, and, it favor
> short-term thinking over long-term planning

Who do you suppose pays for the abuse department staff? Those are
operational costs passed on to all customers. If increasing abuse results
in increasing staff, hopefully eventually, these cost will most likely be
passed on to all customer. It would be nice to see per incident billing so
only offenders and repeat offenders pay. I doubt that'll happen (just a
gut feeling, no other justification)

Ad

[Niels Bakker]

Owen DeLong <***@delong.com> writes
>> It's not crap. Infected machines are no more the fault of the interne
>> than junkmail in your mailbox is the fault of the post office. There'
>> literally no difference to the model. The post office delivers mai
>> that is addressed to you. They don't care if it's junk mail or not
>> They deliver it

* ***@adis.on.ca (Adi Linden) [Tue 15 Jun 2004, 00:58 CEST]
> So what about little envelopes with white powder? Does the post office
> still have an obligation to deliver it or should they be concerne
> about the welfare of their customers? Perhaps they should insist tha
> customers are properly vaccinated...

Don't you think you're stretching this analogy way past its breakin
point

Besides, the post office (supposedly) cares about its workers and a
such has a problem with delivering dangerous packages..

> Point I am making is that the post office is not responsible and/o
> liable for the content of the packages they deliver. However, if the
> deliver packages that are obviously visibly dangerous to the recipien
> they have an obligation to investigate and not deliver the package

If they were so obviously visibly dangerous, why did postal workers di
during the first few anthrax scares

Again, the analogy breaks down. (Packets don't kill people, packages do?

Don't junk mailers pay extra anyway? Or is that an urban legend..

-- Niels

[Owen DeLong]

[Edward B. Dreger]

AL> Date: Mon, 14 Jun 2004 17:57:21 -0500 (CDT
AL> From: Adi Linde

AL> Who do you suppose pays for the abuse department staff? Thos
AL> are operational costs passed on to all customers

Unless one does nothing, in which case the cost goes to the res
of the world. I'd rather take on a handful of infected users an
hosts on the inside than deal with crud from the rest of th
world

Yet another slew of NANOG threads with hundreds of posts tha
boil down to sociotechnical issues and how to shift the costs t
the guilty parties

Edd
-
EverQuick Internet - http://www.everquick.net
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com
Bandwidth, consulting, e-commerce, hosting, and network buildin
Phone: [phone] Lawrence and [inter]nationa
Phone: [phone] Wichit
________________________________________________________________
DO NOT send mail to the following addresses
***@brics.com -or- ***@intc.net -or- ***@intc.ne
Sending mail to spambait addresses is a great way to get blocked

[Hannigan, Martin]

Actually, these problems are economical and business model problems.

Socio went out in 97/98. If not sooner.


Regards

-
Martin Hannigan (c) 617-388-266
VeriSign, Inc. (w) 703-948-701
<http://www.verisign.com/


-----Original Message----
From: owner-***@merit.edu <owner-***@merit.edu
To: nanog <***@merit.edu
Sent: Mon Jun 14 16:23:48 200
Subject: Re: "Default" Internet Servic

AL> Date: Mon, 14 Jun 2004 17:57:21 -0500 (CDT
AL> From: Adi Linde

AL> Who do you suppose pays for the abuse department staff? Thos
AL> are operational costs passed on to all customers

Unless one does nothing, in which case the cost goes to the res
of the world. I'd rather take on a handful of infected users an
hosts on the inside than deal with crud from the rest of th
world

Yet another slew of NANOG threads with hundreds of posts tha
boil down to sociotechnical issues and how to shift the costs t
the guilty parties

Edd
-
EverQuick Internet - http://www.everquick.net
A division of Brotsman & Dreger, Inc. - http://www.brotsman.com
Bandwidth, consulting, e-commerce, hosting, and network buildin
Phone: [phone] Lawrence and [inter]nationa
Phone: [phone] Wichit
________________________________________________________________
DO NOT send mail to the following addresses
***@brics.com -or- ***@intc.net -or- ***@intc.ne
Sending mail to spambait addresses is a great way to get blocked