ietf
[Top] [All Lists]

Re: Internet SYN Flooding, spoofing attacks

2000-02-16 10:30:02
Stephen Kent wrote:

Eliot,

Some of the DoS attacks we saw last week were good, old-fashioned SYN
floods.  Hosts do have a responsibility here, more than ISPs, since
it is quite feasible to tie up a host's pool of TCBs with a small
number of packets, even if the attack tool does not use spoofed
sourced addresses (or if the spoofed addresses are from a legitimate
pool allocated to a subscriber site).

And at least one of the attacks last week indeed was a smurf. Filters
would have helped in some cases and not others.


The point I have tried to make, unsuccessfully, is not that
performing ingress filtering is bad, and thus should not be
performed.  Rather, I am pointing out that it is a bad idea to rely
on such filtering as a primary means of defense. There are several
reasons for saying this:

Reliance on any single method will be insufficient. It will take several
methods.

        - not all ISPs will find it feasible to provide such filtering

This needs to be addressed. Feasible due to expense of equipment,
loading, what? ISPs need to implement this now or soon. When purchasing
new gear, the ability to do filtering without affecting performance
should be on the list of features given to manufacturers.

When we first started the drafts for RFC 2267, back in 1996, concerns
were raised that equipment couldn't handle the load. The suggestion then
was the same. NEXT TIME you order equipment, make it a requirement. It
is possible to build the gear to do the filtering. If ISPs don't demand
it of their vendors, they won't get it, though.

        - not all ISPs are trusted to do the filtering (in the global 
Internet)

This issue can be addressed by their upstream providers with terms of
service agreements. Will it be perfect? Unlikely.

        - a number of DDoS attacks can be launched without using
spoofed addresses outside of those "appropriate" to the subscriber
site

Which is NO reason to permit attacks which DO spoof. Filtering is going
to limit the types of attacks which can be launched, and permits
idenitification of the systems and networks where the packets come from.
It may still be necessary to chase down those sites and get action, but
at least it's possible to know WHICH SITES are the sources.

        - some applications may legitimately make use of non-local
addresses, as others have suggested

A point which is in dispute. Beyond that, operational reality is that
filtering DOES occur, and may occur somewhere neither you nor your
upstream ISP can control. To at least some extent it's useful to
understand present operational reality in choosing methodologies.


I have seen a long history of suggested solutions to security
problems which are only partially effective against current forms of
attacks, vs. providing protection against a larger class of attacks.
I'm trying to suggest that we not follow this pattern.

Please suggest another course of action. To date, the IETF has spent a
considerable amount of its security mindshare on IPSec. While developing
that functionality, operational reality resulted in the deployment of
huge numbers of NAT boxes, and IPSec and NAT aren't interoperable.
Another case of operational reality and design colliding.

Ingress filtering does not provide a complete solution. Neither did the
patches to operating systems to guard against SYN flooding. By using
both of those, we limit the effectiveness of those types of attacks. I
expect we will have to add a whole suite of techniques to bring the
problems under some reasonable level of control. What is unclear is why
some think we could or should do nothing in the short term.



-- 
-----------------------------------------------------------------
Daniel Senie                                        dts(_at_)senie(_dot_)com
Amaranth Networks Inc.            http://www.amaranthnetworks.com