Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: dsl providers that will route /24

  • From: David Schwartz
  • Date: Fri Mar 30 03:34:11 2001

> On Thu, Mar 29, 2001 at 07:19:54PM -0800, David Schwartz wrote:

> > > On Thu, Mar 29, 2001 at 06:40:03PM -0800, David Schwartz wrote:
> > > So you automatically know about every single spoofed packet your
> > > customers send?

> > 	We know every pair of source and destination IP addresses
> > and the number of
> > packets and number of bytes. We also know (approximately) the
> > start and stop times.

> And you have someone watching the logs in realtime 24 hours a
> day?  Ready to
> start investigation within seconds of your customer flooding someone, or
> kicking off a smurf attack?

	Log analysis is automatic. If a traffic flow is sufficiently suspicious, it
will summon someone to investigate it. The definition of 'sufficiently
suspicious' is quite complex.

	I don't want to go into too much detail about how my network works because
I really don't want people to know what they can get away with and what's
likely to get them caught. But this really isn't supposed to be about about
how I run my network.

> No, I'm arguing proactive against reactive.  Do you install all
> your servers
> with open mail relays and wait for them to be abused before
> closing them down?
> Do you install your servers with an empty root password and wait
> for someone
> to abuse that before you do something?

	I don't give the world as a whole the benefit of the doubt -- I give my
customers the benefit of the doubt. I take reasonable steps to minimize the
damage they can do, but I can't drop it to zero.

> > As I've already said, every provider must come up with a
> > strategy for
> > dealing with spoofed packets, unspoofed floods, compromised
> > customers, and
> > so on. Ideally, though, the actual structural problems would be fixed.
> OK, so go rewrite IP, or at least a means of unspoofable packet tracing.

	Whatever needs to happen to solve this at its root won't happen so long as
people continue to insist that all it takes is proper filtering.

> > 	The problem of spoofed packets. But this is just one of many, many
> > problems.
> and the one we're talking about.

	No. Unspoofed floods will hurt you just as badly as spoofed ones. And
knowing the source won't help you much if it's 5:30 on a Friday and nobody
who can fix the source network is around.

> No, it will make a big difference though.  Same as closing open
> mail relays
> and blocking direct-to-MX connections won't solve the spam problem.

	Sure, if every ISP created and adopted a good policy for dealing with
abuse, DoS attacks, and the rest, that would go a long way. But just like
with mail, closing open relays and blocking direct connections is not the
real solution, it's just a bunch of bandaids. Yes, the bandaids are better
than nothing, but they're hardly the right solution.

> > 	On the other hand, if it were coming from my network, odds
> > are someone here
> > would be calling you. And I'd probably be blocking packets to
> > your machine
> > before you even noticed you were being flooded.
> I'm glad you're so confident.  Personally, I hope never to find out.

	You probably never will. We get attacked far more often than we are the
source of attacks. (We are lucky in the fact that we've been able to be
highly selective in our customers, so they are probably generally more
clueful than most people's.)

> > 	1) Someone isn't monitoring his network because he thought
> filtering solved the problem, or
> No, because if its filtered, I'm gonna be calling the right NOC
> first time.

	Again, doesn't help you 5:30 on a Friday if the only person who can log
into the router isn't there. If they're an OC3 government site and you're a
small site whose T1 is being saturated, I don't think their provider is
going to shut them down.

> > 	2) You don't have tools to trace/block the packets because
> > they weren't
> > developed because people believed that filtering would solve
> > the problem.
> That doesn't stop them being developed though.

	It's been my experience that it has. No demand equals no supply. Read this
list, and you'll see it over and over, "if everyone would just ingress
filter ...".

	In many cases, the 'edge' at which you're supposed to filter is mythical.


Discussion Communities

About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home

Merit Network, Inc.