North American Network Operators Group

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

Re: dsl providers that will route /24

  • From: John Payne
  • Date: Fri Mar 30 00:26:22 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?

> > 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.

Duh

> > 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.

Yes, but with unspoofed packets, 99% of the tracking work is done.

> > 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.

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?

> 	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.

> > 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.

and the one we're talking about.

> > 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.

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.

> > 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.

I'm glad you're so confident.  Personally, I hope never to find out.

> > 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

No, because if its filtered, I'm gonna be calling the right NOC first time.

> 	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.

-- 
John Payne      http://www.sackheads.org/jpayne/    [email protected]
http://www.sackheads.org/uce/                    Fax: +44 870 0547954
        To send me mail, use the address in the From: header