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 _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www1.ietf.org/mailman/listinfo/gen-art
