RE: dsl providers that will route /24

["David Schwartz" <davids () webmaster com>]

> On Thu, Mar 29, 2001 at 06:40:03PM -0800, David Schwartz wrote:

> > > But the *unspoofed* packets are traceable.  The victim can pick
> > > up the phone
> > > and call your operations and alert them.

> >     If they were spoofed, they wouldn't have to because we'd already be
> > investigating. And even if they're not spoofed, you can't know
> > they're not
> > spoofed, so there's no way to know you got the right person.
>
> 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.

> If they're not spoofed, then the operations folk that I would be speaking
> to could verify that they're not spoofed by looking at their customer's
> traffic.

        Exactly. So you would need cooperation from the source network to establish
the source of the attack.

> Monitoring is reactive.  Filtering is proactive.  Filtering means I won't
> be flooded by spoofed packets coming from your customers.  Filtering
> means
> I won't be smurfed by your customers.  (Sure, they could still
> act as smurf
> amps, but they couldn't originate a smurf attack).

        You will instead get flooded by unspoofed packets. And you'll have to start
the process of tracking and fixing the problem.

> Monitoring means I could still be flooded with spoofed packets,
> and you might notice and switch it off.

        This is a classic example of a straw man. I'm arguing for the superiority
of a log, monitor, follow up policy compared to a filtering policy. You're
arguing against a policy that doesn't including monitoring and following up.

        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.

> >     Well that's the real problem. Every attack is potentially
> > spoofed and there
> > are no good tools for dealing with spoofed attacks. Filtering
> > doesn't solve
> > either of those two problems.
>
> If everyone filtered, it would solve the problem.  If most people
> filter, it
> reduces the problem.  If nobody filters it does nothing to
> address the problem.

        The problem of spoofed packets. But this is just one of many, many
problems.

> Do you want to help, or do you want to do as little as possible?

        Actually, I want to do the most possible. And the first thing to do is to
realize that there aren't any really good solutions out there. The worst
possible thing to do is to go around claiming that if people just ingressed
filtered, the problems would go away.

        The fact is that there are very real problems for which there aren't good
solutions. For example, if you own the IP 1.2.3.4, you should have a way of
shutting off packets from 4.3.2.1 to 1.2.3.4 at their source. But you don't.

        We also need a very good general understanding that you shouldn't send 'a
lot' of traffic to a destination unless you can confirm that the real
destination wants that traffic. There are still new protocols coming out
that break this rule very badly.

        So if filtering works well for you, great, filter. However, if you want to
claim that filtering will solve the Internet's DoS problems, then you are
part of the problem.

> >     Again, no. A unicast UDP flood can do just as much damage.
> > So filters do
> > not reduce the damage.
>
> If you're ingress filtering, when I pick up the phone I can call your
> operations folk and they can verify that your customer is flooding me,
> and
> stop the flood  *quickly*.  Speed means a reduction in damage.

        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.

> Sure, someone else could be spoofing your customers addresses, but your
> operations folk would be able to verify that your customer is not
> flooding
> me... so I'm back to square one.  *but* even in this case, I'm no
> worse off
> than I am today... so putting filters in either means that
> attacks get shut
> down more quickly, or they get treated the same as today.  It
> does not make things worse.

        You are *much* worse of if the reason you are getting flooded is because:

        1) Someone isn't monitoring his network because he thought filtering solved
the problem, or

        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.

        For clueless administrators, they'll probably botch their filters, think
they've solved the problems, and not monitor their network. For clueful
administrators, they'll catch the problem early and won't pose a threat to
you, filters or not.

        What you really want are useful *tools*. Tools to allow you to control the
traffic that is heading towards you. Or perhaps source authentication. Or
perhaps something else.

> >     Exactly -- the problem is there's no good way to tell a
> > spoofed packet from
> > an unspoofed packet. Some form of source authentication would
> > solve that.
>
> Or you could make sure you're not part of the problem by putting source
> address filters on your ingress.

        Yes, that's one way to make sure you're not part of the problem. There are
others. None are perfect. The problem really needs to be solved at its root.

        DS