Skip to main content

TCP SYN Flooding Attacks and Common Mitigations
draft-ietf-tcpm-syn-flood-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the Yes position for Lisa Dusseault
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Ronald Bonica
2007-06-01
05 (System) IANA Action state changed to No IC from In Progress
2007-06-01
05 (System) IANA Action state changed to In Progress
2007-05-31
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-05-31
05 Amy Vezza IESG state changed to Approved-announcement sent
2007-05-31
05 Amy Vezza IESG has approved the document
2007-05-31
05 Amy Vezza Closed "Approve" ballot
2007-05-31
05 Lars Eggert State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Lars Eggert
2007-05-30
05 (System) New version available: draft-ietf-tcpm-syn-flood-05.txt
2007-05-29
05 Lisa Dusseault [Ballot Position Update] Position for Lisa Dusseault has been changed to Yes from Discuss by Lisa Dusseault
2007-05-25
05 (System) Removed from agenda for telechat - 2007-05-24
2007-05-24
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2007-05-24
05 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded by Cullen Jennings
2007-05-24
05 Jari Arkko [Ballot Position Update] New position, Yes, has been recorded by Jari Arkko
2007-05-23
05 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2007-05-23
05 Russ Housley
[Ballot comment]
Based on Gen-ART Review by Christian Vogt:

  Excellent work!

  The draft is certainly ready for publication.  I found it very
  …
[Ballot comment]
Based on Gen-ART Review by Christian Vogt:

  Excellent work!

  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.  A few comments follow:

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

  (4) Editorial nits:

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

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

      (c)  Section 3.6, 6th paragraph:  s/never is/is never/
2007-05-23
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2007-05-23
05 Magnus Westerlund [Ballot Position Update] New position, Yes, has been recorded by Magnus Westerlund
2007-05-22
05 Tim Polk [Ballot Position Update] New position, No Objection, has been recorded by Tim Polk
2007-05-22
05 Sam Hartman [Ballot Position Update] New position, Yes, has been recorded by Sam Hartman
2007-05-15
05 Lars Eggert State Changes to IESG Evaluation from IESG Evaluation::AD Followup by Lars Eggert
2007-05-15
05 Lars Eggert Revision addresses various directorate reviews and some early IESG comments. Back on the agenda for May 24.
2007-05-15
05 Lars Eggert Placed on agenda for telechat - 2007-05-24 by Lars Eggert
2007-05-14
05 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-05-14
04 (System) New version available: draft-ietf-tcpm-syn-flood-04.txt
2007-05-14
05 Ron Bonica [Ballot Position Update] Position for Ron Bonica has been changed to No Objection from Discuss by Ron Bonica
2007-05-08
05 Yoshiko Fong Correction.

IANA Comment was NOT Last Call comment, but Evaluation
Comment.
2007-05-08
05 Yoshiko Fong IANA Last call Comment:

NO IANA Considerations section.
We understand this document to have NO IANA Actions.
2007-05-07
05 Lisa Dusseault
[Ballot discuss]
One part of this document reads a lot like a BCP:

A note to
  the tcp-impl mailing list explains that this code …
[Ballot discuss]
One part of this document reads a lot like a BCP:

A note to
  the tcp-impl mailing list explains that this code does not retransmit
  SYN-ACKs, which is a practice we discourage [B97].

I'd like to see this made clearer.  Who is "we", what do we discourage, and can we avoid a reference to a mailing list thread in what seems to be a recommendation?

  [B97]      Borman, D., "Re: SYN/RST cookies (was Re: a quick
              clarification...)", IETF tcp-impl mailing list, June 1997.

The email referred to seems to be , which does not really make it clear whether the failure to retransmit SYN-ACKs is encouraged or discouraged.  If the reference to the email is simply there to source the facts about Borman's implementation then this belongs more in section 3.4 than in the section titled "Analysis".

Although I got a lot out of this draft, I didn't get a clear picture about the difficulties of retransmitting SYN-ACKs nor about the desirability (the cost/benefit).  I get the sense that's an interesting question, however.
2007-05-07
05 Lisa Dusseault [Ballot Position Update] New position, Discuss, has been recorded by Lisa Dusseault
2007-05-03
05 Samuel Weiler Request for Telechat review by SECDIR Completed. Reviewer: Pasi Eronen.
2007-05-02
05 Lars Eggert Removed from agenda for telechat - 2007-05-10 by Lars Eggert
2007-05-02
05 Lars Eggert State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Lars Eggert
2007-05-02
05 Lars Eggert Author has indicated that a late sec-dir review and other late reviews require a revision.
2007-04-28
05 Ron Bonica
[Ballot discuss]
Do we need permission from PANIX to use their name in an RFC?

Also, how much operational experience do we really have with …
[Ballot discuss]
Do we need permission from PANIX to use their name in an RFC?

Also, how much operational experience do we really have with SYN Cookies? You say that they are implemented in LINIX, but not enabled by default. Could they introduce yet other vulnerabilities?
2007-04-28
05 Ron Bonica [Ballot Position Update] New position, Discuss, has been recorded by Ron Bonica
2007-04-27
05 Samuel Weiler Request for Telechat review by SECDIR is assigned to Pasi Eronen
2007-04-27
05 Samuel Weiler Request for Telechat review by SECDIR is assigned to Pasi Eronen
2007-04-23
05 Lars Eggert Placed on agenda for telechat - 2007-05-10 by Lars Eggert
2007-04-23
05 Lars Eggert [Ballot Position Update] New position, Yes, has been recorded for Lars Eggert
2007-04-23
05 Lars Eggert Ballot has been issued by Lars Eggert
2007-04-23
05 Lars Eggert Created "Approve" ballot
2007-04-23
05 (System) Ballot writeup text was added
2007-04-23
05 (System) Last call text was added
2007-04-23
05 (System) Ballot approval text was added
2007-04-23
05 Lars Eggert State Changes to IESG Evaluation from AD Evaluation by Lars Eggert
2007-04-23
05 Lars Eggert Performed AD review during WGLC.
2007-04-23
05 Lars Eggert State Changes to AD Evaluation from Publication Requested by Lars Eggert
2007-04-23
05 Lars Eggert [Note]: 'Document Shepherd: Mark Allman (mallman@icir.org)' added by Lars Eggert
2007-04-23
05 Lars Eggert State Change Notice email list have been change to tcpm-chairs@tools.ietf.org, weddy@grc.nasa.gov from tcpm-chairs@tools.ietf.org
2007-04-23
05 Dinara Suleymanova
PROTO Write-up

>>> (1.a) Who is the Document Shepherd for this document? Has the
>>> Document Shepherd personally reviewed this version of the
>>> document …
PROTO Write-up

>>> (1.a) Who is the Document Shepherd for this document? Has the
>>> Document Shepherd personally reviewed this version of the
>>> document and, in particular, does he or she believe this
>>> version is ready for forwarding to the IESG for
>>> publication?
>
> Mark Allman (TCPM co-chair) is acting as the shepherd for this
> document.
>
> I have read this version of the draft and believe it is ready for
> publication as an Informational RFC.
>
>>> (1.b) Has the document had adequate review both from key WG
>>> members
>>> and from key non-WG members? Does the Document Shepherd
>>> have
>>> any concerns about the depth or breadth of the reviews that
>>> have been performed?
>
> The document has been reviewed by many WG members and has enjoyed
> much support over the course of its development. I have no concerns
> about the review process.
>
>>> (1.c) Does the Document Shepherd have concerns that the document
>>> needs more review from a particular or broader perspective,
>>> e.g., security, operational complexity, someone familiar
>>> with
>>> AAA, internationalization or XML?
>
> I have no concerns that the document needs additional review.
>
>>> (1.d) Does the Document Shepherd have any specific concerns or
>>> issues with this document that the Responsible Area
>>> Director
>>> and/or the IESG should be aware of? For example,
>>> perhaps he
>>> or she is uncomfortable with certain parts of the
>>> document, or
>>> has concerns whether there really is a need for it. In any
>>> event, if the WG has discussed those issues and has
>>> indicated
>>> that it still wishes to advance the document, detail those
>>> concerns here. Has an IPR disclosure related to this
>>> document
>>> been filed? If so, please include a reference to the
>>> disclosure and summarize the WG discussion and
>>> conclusion on
>>> this issue.
>
> I have no specific issues that the IESG should be aware of.
>
> No IPR disclosures have been filed relating to this document.
>
>>> (1.e) How solid is the WG consensus behind this document?
>>> Does it
>>> represent the strong concurrence of a few individuals, with
>>> others being silent, or does the WG as a whole
>>> understand and
>>> agree with it?
>
> I believe the consensus behind this document is quite broad.
>
>>> (1.f) Has anyone threatened an appeal or otherwise indicated
>>> extreme
>>> discontent? If so, please summarise the areas of
>>> conflict in
>>> separate email messages to the Responsible Area
>>> Director. (It
>>> should be in a separate email because this questionnaire is
>>> entered into the ID Tracker.)
>
> I am not aware of any threatened appeals or any discontent with this
> document in any way. (In fact, all the recent work has been fairly
> editorial in nature.)
>
>>> (1.g) Has the Document Shepherd personally verified that the
>>> document satisfies all ID nits? (See
>>> http://www.ietf.org/ID-Checklist.html and
>>> http://tools.ietf.org/tools/idnits/). Boilerplate
>>> checks are
>>> not enough; this check needs to be thorough. Has the
>>> document
>>> met all formal review criteria it needs to, such as the MIB
>>> Doctor, media type and URI type reviews?
>
> The document requires no formal reivews (e.g., by MIB Doctors).
>
> I have run idnits on the document and it shows no issues.
>
>>> (1.h) Has the document split its references into normative and
>>> informative? Are there normative references to
>>> documents that
>>> are not ready for advancement or are otherwise in an
>>> unclear
>>> state? If such normative references exist, what is the
>>> strategy for their completion? Are there normative
>>> references
>>> that are downward references, as described in
>>> [RFC3967]? If
>>> so, list these downward references to support the Area
>>> Director in the Last Call procedure for them [RFC3967].
>
> The references are labeled as "Informative", as they should be.
> This is an informational document.
>
>>> (1.i) Has the Document Shepherd verified that the document IANA
>>> consideration section exists and is consistent with the
>>> body
>>> of the document? If the document specifies protocol
>>> extensions, are reservations requested in appropriate IANA
>>> registries? Are the IANA registries clearly
>>> identified? If
>>> the document creates a new registry, does it define the
>>> proposed initial contents of the registry and an allocation
>>> procedure for future registrations? Does it suggest a
>>> reasonable name for the new registry? See [RFC2434].
>>> If the
>>> document describes an Expert Review process has Shepherd
>>> conferred with the Responsible Area Director so that the
>>> IESG
>>> can appoint the needed Expert during the IESG Evaluation?
>
> The document has an IANA considerations section that is consistent
> with the body of the document. This document has no IANA
> considerations.
>
>>> (1.j) Has the Document Shepherd verified that sections of the
>>> document that are written in a formal language, such as XML
>>> code, BNF rules, MIB definitions, etc., validate
>>> correctly in
>>> an automated checker?
>
> This does not apply.
>
>>> (1.k) The IESG approval announcement includes a Document
>>> Announcement Write-Up. Please provide such a Document
>>> Announcement Write-Up? Recent examples can be found in the
>>> "Action" announcements for approved documents. The
>>> approval
>>> announcement contains the following sections:
>>>
>>> Technical Summary
>>> Relevant content can frequently be found in the abstract
>>> and/or introduction of the document. If not, this
>>> may be
>>> an indication that there are deficiencies in the
>>> abstract
>>> or introduction.
>
> This document describes TCP SYN flooding attacks, which have been
> well-known to the community for several years. Various
> countermeasures against these attacks, and the trade-offs of each,
> are described. This document archives explanations of the attack
> and common defense techniques for the benefit of TCP implementers
> and administrators of TCP servers or networks.
>
>>> Working Group Summary
>>> Was there anything in WG process that is worth
>>> noting? For
>>> example, was there controversy about particular
>>> points or
>>> were there decisions where the consensus was
>>> particularly
>>> rough?
>
> The consensus within the TCPM WG to publish this document as an
> informational RFC is strong.
>
>>> Document Quality
>>> Are there existing implementations of the protocol?
>>> Have a
>>> significant number of vendors indicated their plan to
>>> implement the specification? Are there any reviewers
>>> that
>>> merit special mention as having done a thorough review,
>>> e.g., one that resulted in important changes or a
>>> conclusion that the document had no substantive
>>> issues? If
>>> there was a MIB Doctor, Media Type or other expert
>>> review,
>>> what was its course (briefly)? In the case of a
>>> Media Type
>>> review, on what date was the request posted?
>
> This document details several techniques that have been used in TCP
> implementations for many years. The technology discussed in this
> document is not new, but rather this document is helping the
> RFC-series "catch up" with common practice and details experience
> with several mechanisms.
>
>>> Personnel
>>> Who is the Document Shepherd for this document? Who
>>> is the
>>> Responsible Area Director? Is an IANA expert needed?
>
> The document shepherd for this document is Mark Allman (TCPM
> co-chair). The responsible AD is Lars Eggert. The document does
> not need an IANA expert.
2007-04-23
05 Dinara Suleymanova State Changes to Publication Requested from AD is watching by Dinara Suleymanova
2007-04-20
03 (System) New version available: draft-ietf-tcpm-syn-flood-03.txt
2007-03-08
02 (System) New version available: draft-ietf-tcpm-syn-flood-02.txt
2006-12-11
01 (System) New version available: draft-ietf-tcpm-syn-flood-01.txt
2006-10-17
05 Lars Eggert Intended Status has been changed to Informational from None
2006-08-22
05 Lars Eggert Draft Added by Lars Eggert in state AD is watching
2006-07-19
00 (System) New version available: draft-ietf-tcpm-syn-flood-00.txt