Subject: [tcpm] WGLC for SYN flooding

From: Ted Faber <[email-masked]>
Date: Tue, 27 Mar 2007 14:28:27 -0700

Mark and I would like to start a WG last call on the SYN flooding and
countermeasures document:

        Title           : TCP SYN Flooding Attacks and Common Mitigations
        Author(s)       : W. Eddy
        Filename        : draft-ietf-tcpm-syn-flood-02.txt
        Pages           : 23
        Date            : February 2007
        http://www.ietf.org/internet-drafts/draft-ietf-tcpm-syn-flood-02.txt

which is slated for informational.  Our understanding is that all
feedback to date is reflected in this version and that there are no
known outstanding issues.  But, it'd be great if folks can verify that
and in general give this one more look.  Please send feedback (even if
just of the form "yep, looks good"). 

Despite the fact we're starting this a day later than we intended, we're
planning on wrapping up comments on 13 Apr 2007.  Yes, that's a Friday.

Again, please send comments, especially of the form "I read it and think
it's fine."

-- 
Ted Faber
http://www.isi.edu/~faber           PGP: http://www.isi.edu/~faber/pubkeys.asc
Unexpected attachment on this mail? See http://www.isi.edu/~faber/FAQ.html#SIG
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: Lars Eggert <[email-masked]>
Date: Wed, 28 Mar 2007 11:14:32 +0300

Summary: Basically good to go.

--- COMMENTS ------------------------------------------------

INTRODUCTION, paragraph 13:
 >    This document archives explanations of the attack and
 >    common defense techniques for the benefit of TCP implementers and
 >    administrators of TCP servers or networks.

   Suggest to add "but does not make any standards-level
   recommendations."

Section 2.1., paragraph 4:
 >    Some of these techniques have
 >    become important pieces of the TCP implementations in certain
 >    operating systems, although some significantly diverge from the  
TCP
 >    specification and have not yet been standardized or sanctioned  
by the
 >    IETF process.

   s/and have not yet been/and none of these techniques have been/

Section 2.2., paragraph 6:
 >    The goal is to send
 >    a quick barrage of SYN segments from spoofed IP addresses that  
will

   "from spoofed IP addresses" - not necessarily spoofed; think botnets
   (you discuss this below)

Section 4., paragraph 0:
 >   4.  Analysis

   Part of this section discusses history - move those parts into  
Section
   2.1?

--- NITS ---------------------------------------------------

Section 2.2., paragraph 15:
 >    network.  The attack also attepts to prevent only the  
establishment

   Nit: s/attepts/attempts/

Section 2.2., paragraph 17:
 >    case, each host utilized in the attack would have to supress its

   Nit: s/supress/suppress/

Section 3.2., paragraph 1:
 >    An obvious attempt at defense is for end hosts to use a larger

   Nit: s/at defense/at a defense/

Section 3.4., paragraph 3:
 >    Measurments at one site's border router [All07] logged  
2,545,785 SYN

   Nit: s/Measurments/Measurements/

Section 3.5., paragraph 3:
 >    attack, or via adminstrative action.

   Nit: s/adminstrative/administrative/

Section 7.0, paragraph 0:
 >    way that it is from the sequence number / acknowledgedment in a  
basic

   Nit: s/acknowledgedment/acknowledgment/

Section 7.0, paragraph 1:
 >    compromises inherrent in SYN cookies is unique to the FreeBSD

   Nit: s/inherrent/inherent/

Section 7.0, paragraph 4:
 >    the passive side side's application-layer never is notified of the

   Nit: s/side side's/side's/

Appendix A., paragraph 2:
 >    number, MSS, a time counter, and the relevent addresses and port

   Nit: s/relevent/relevant/