TCP SYN Flooding Attacks and Common Mitigations
RFC 4987

Note: This ballot was opened for revision 05 and is now closed.

Lars Eggert Yes

(Jari Arkko; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Lisa Dusseault; former steering group member) (was Discuss) Yes

Yes ()
No email
send info

(Magnus Westerlund; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Sam Hartman; former steering group member) Yes

Yes ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Cullen Jennings; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Ron Bonica; former steering group member) (was Discuss) No Objection

No Objection ()
No email
send info

(Ross Callon; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info

(Russ Housley; former steering group member) No Objection

No Objection (2007-05-23 for -** No value found for 'p.get_dochistory.rev' **)
No email
send info
  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/

(Tim Polk; former steering group member) No Objection

No Objection ( for -** No value found for 'p.get_dochistory.rev' **)
No email
send info