dsl providers that will route /24

Fri Mar 30 03:00:49 UTC 2001

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?

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.

> > > 	Odds are, an attacker will used spoofed packets if he can.
> > > potentially
> > > spoofed packets will trigger an investigation on my network. An
> > > unspoofed
> > > UDP flood probably won't (especially if it hops from victim to victim).
> 
> > Some of us that have been flooded don't appreciate playing the
> > odds that the provider of the flooder will notice.
> 
> 	Right, that's why every provider has to come up with some reasonable way to
> deal with this problem. Filtering is one, but it doesn't solve the whole
> problem. Monitoring is one, but it doesn't solve the whole problem either.

Filtering removes the "is this spoofed or not?" problem.  We wouldn't be 
flooded with packets with sources in unallocated space.  Oh, and smurf would
disappear completely.

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

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

> > > 	So if the attacker uses spoofed packets, he may get cut off
> > > at the source
> > > (and the problem actually solved) sooner. On the other hand, unspoofed
> > > packets will probably trigger a call to the administration of the
> > > source
> > > network faster. Of course, you don't know that attack is
> > > unspoofed, so you
> > > really can't be sure what the source is.
> >
> > No, but it gives a good indication.  And your NOC can find out if
> > the packets
> > are actually coming from your customer (unspoofed) or not
> > (spoofed).  If its
> > unspoofed then we're on the phone to the right people.  If its
> > spoofed, we're SOL.
> 
> 	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.

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

> > > 	The important thing to realize is that neither of these
> > > situations is
> > > ideal. That is, filters don't solve the problem. We need to
> > > acknowledge that
> > > we have a problem and don't have a solution to it. Only then will the
> > > problem be analyzed, solutions proposed, and implemented.
> >
> > Filters mean "least damage".
> 
> 	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.

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.

> > > 	I don't know, I'm not smart enough to solve the problem by
> > > myself. All I
> > > can do is keep yelling as loudly as I can that there is a
> > > problem and that
> > > we do need a really good solution.
> >
> > And until we get a really good solution, a really good workaround is not
> > letting spoofed packets into your network from your customers.
> 
> 	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.

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