[tcpm] Review of draft-ietf-tcpm-syn-flood-04

"Christian Vogt" <christian.vogt@nomadiclab.com> Wed, 23 May 2007 10:15 UTC

Return-path: <tcpm-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqnsk-0001CV-Tu; Wed, 23 May 2007 06:15:50 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hqnsj-00019g-MH; Wed, 23 May 2007 06:15:49 -0400
Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hqnsg-0006zZ-Ri; Wed, 23 May 2007 06:15:49 -0400
Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2F6481986A5; Wed, 23 May 2007 13:15:46 +0300 (EEST)
Received: from www.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C292D1986A2; Wed, 23 May 2007 13:15:45 +0300 (EEST)
Received: from 194.237.142.7 (SquirrelMail authenticated user chvogt) by www.piuha.net with HTTP; Wed, 23 May 2007 13:15:45 +0300 (EEST)
Message-ID: <6575.194.237.142.7.1179915345.squirrel@www.piuha.net>
Date: Wed, 23 May 2007 13:15:45 +0300
From: Christian Vogt <christian.vogt@nomadiclab.com>
To: weddy@grc.nasa.gov
User-Agent: SquirrelMail/1.4.10a
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: ClamAV using ClamSMTP
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135
Cc: tcpm@ietf.org, gen-art@ietf.org, faber@isi.edu, mallman@icir.org
Subject: [tcpm] Review of draft-ietf-tcpm-syn-flood-04
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
Errors-To: tcpm-bounces@ietf.org

Wesley,

I read your draft on "TCP SYN Flooding Attacks and Common Mitigations" as
part of my work as a Gen-ART reviewer.  Below some feedback.

(For background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).

Please wait for direction from your document shepherd
or AD before posting a new version of the draft.

Document: draft-ietf-tcpm-syn-flood-04.txt
Reviewer: Christian Vogt
Review Date:  May 23, 2007
IESG Telechat date: --

Summary:

The draft is certainly ready for publication.  I found it very
well-structured and easy to read.  The introduction gives the
unexperienced reader an excellent overview on the topic.  I also think
that the draft is a valuable contribution, finally providing a concise and
well-citeable summary on SYN flooding prevention mechanisms.

Comments:

(1)  Section 3.3 (Reducing SYN-RECEIVED Timer):  Maybe you could state
here /why/ this technique might prevent legitimate connections from
becoming established.  The reason obviously is that the RTT to a
legitimate peer might be longer than a shortened connection establishment
timeout, but this should be written down explicitly.  Also, it might be
good to add that RTTs can be quite long in some wireless access
technologies, e.g., due to long buffering delays.

(2)  Section 3.4 (Recycling the Oldest Half-Open TCB):  Again, this
technique could again prevent legitimate connection establishments
especially when the RTT is long.

(3)  Section 3.6 (SYN Cookies), 3rd paragraph:  Referring to the example
that SYN cookies might not interoperate with MSS encodings in initial
sequence numbers:  I am not an expert in this area, but I could imagine
that the problem is due to the TCP responder not being able to store the 2
MSS bits in the sequence number from the SYN, nor being able to
reconstruct these bits in the sequence number from the ACK following the
SYN-ACK.  Reconstruction of the MSS bits from the ACK are not feasible
because the SYN might have options, which, at the time the ACK is
received, have been forgotten by the TCP responder.  If this is what
causes the problem, then it might be good to spend one or two more
sentences explaining it.

Editorial nits:

(1)  Section 1, 1st paragraph:  s/denial of service
method/denial-of-service method/

(2)  Section 3.6, 2nd paragraph:  s/implementation
dependent/implementation-dependent/

(3)  Section 3.6, 6th paragraph:  s/never is/is never/

That's it.  Excellent work, go ahead and publish!

- Christian




_______________________________________________
tcpm mailing list
tcpm@ietf.org
https://www1.ietf.org/mailman/listinfo/tcpm