Subject: Re: DDoS Work

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 22 Mar 2001 10:17:21 -0600

In message <[email-masked]>, Jari Arkko writes:
>
>* In the Internet Area, there is the itrace WG which is
>   specifically chartered for looking into DoS, but is
>   looking only at a particular solution. Is this
>   solution sufficient for all DoS issues? We're not sure
>   but at least some of the individual DoS concerns such
>   as attacking address autoconfiguration don't really
>   fall on the area that i-trace can deal with.

Without addressing your general question, IESG policy is that working 
groups should be very carefully focused.  A hypothetical "Fix DDoS Working 
Group" would probably not meet that test -- there are no concrete 
deliverables.  

That said, an RFC that discussed DoS avoidance strategies would be
a good idea.  I'm agnostic about whether that should be done in a
WG or as an individual submission, but BCP status would be a good
one to aim for.  How this process should be organized is up to the
AD's and the IESG.  (Also note that the next rev of draft-rescorla-sec-cons
has a good section on DoS attacks.)

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 22 Mar 2001 11:43:50 -0500

> has a good section on DoS attacks.)

Is this available? The current draft has expired, and there is no new
version in the draft directory.

-- 

                                   Regards
                                   Marshall Eubanks

   Multicast Technologies, Inc.
   10301 Democracy Lane, Suite 410
   Fairfax, Virginia 22030
   Phone : 703-293-9624          Fax     : 703-293-9609     
   e-mail : [email-masked]     http://www.on-the-i.com
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Thu, 22 Mar 2001 19:00:46 +0200

> Group" would probably not meet that test -- there are no concrete 

You are right, and the policy is a good one!

But before we go too far in this question, let's
discuss more about whether there is something
still to be done for DoS prevention, and what.
After finding out that, we could discuss how the
work is organized. Right now, at least I'm uncertain
if we have done everything and how sufficient is
the work on the various WGs. Do some of Pekka's
ideas to protect address autoconfiguration suffice
for all of IPv6 signaling? Does i-trace solve all
tracing issues? Will HIP solve everything? Is
there something in the mobile-IP area that hasn't
and will not be solved by that WG? Is it technically
possible to have some general DoS-prevention
protocols or layers to applications?

Jari

---

From: Robert Stone <[email-masked]>
Date: Fri, 23 Mar 2001 16:41:40 -0500

> has a good section on DoS attacks.)

For what it's worth, the following document could provide a starting point:

http://www.cert.org/reports/dsit_workshop-final.html

It provides some specific recommendations, but is too vague in some areas
and is, perhaps, a little out-of-date.

---
Robert Stone <[email-masked]>, Security Engineer, Arbor Networks, Inc.
www.arbor.net

---

From: "S. Felix Wu" <[email-masked]>
Date: Thu, 22 Mar 2001 16:16:45 -0800

Jari Arkko wrote:
> tracing issues?

I will try here to characterize, from a technical point
of view, which problems can be solved using the potential
solutions developed by the iTrace working group: (if I do
not explain clearly, please accept my appology and let me
know which points are not clear.)

   In high level, iTrace tries to identify the approximate
   location of a source (or sources) that generates a stream
   of source-spoofed IP packets toward a particular
   destination host or network. With the iTrace-backward
   option, it can handle upto one layer of reflecting devices.
   There is an inherent assumption that, in order to make
   iTrace practically useful, the packet stream between the
   source and destination must be big enough to get a
   "reasonably" good probability. Examples are synflood and
   DDoS. Counter-examples are smurf and TCPLand, because in
   both cases, the attack stream is too small (one packet) to
   get a good probability. On the other hand, realizing
   iTrace forces attackers to give up many existing attack
   options -- they have to perform smaller flow attacks or
   launch from a much bigger number of slaves.

   Second, iTrace is only for "identifying the sources." It
   is not by itself a complete solution to resolve the whole
   DDoS problem, for example. It, in some sense, offers a
   "location information" service for other applications or
   human administrators (or FBI). "How exactly such iTrace
   information can be used in a real world environment"
   should NOT be standardized in iTrace (because different
   applications and situations might need different responses),
   but some practical scenarios for utilizing iTrace should be
   described in a document for applicability statements.

-Felix

-- 
----------------------------------------------------------------------
Dr. S. (Shyhtsun) Felix Wu			     [email-masked]
Associate Professor			 http://www.cs.ucdavis.edu/~wu
Computer Science Department			office: 1-530-754-7070
University of California at Davis		fax:    1-530-752-4767
----------------------------------------------------------------------