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: Thu Mar 29 21:46:20 2001

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

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

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

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

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


Discussion Communities

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

Merit Network, Inc.