Subject: RE: [tcpm] syn flooding draft

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 13 Apr 2006 13:44:18 -0700

Wesley Eddy wrote:
> FYI: An updated version of the draft on TCP SYN flooding and defenses 
> (including SYN cookies) is available:
> http://www.ietf.org/internet-drafts/draft-eddy-syn-flood-02.txt
> 
> I am soliciting comments/questions/suggestions.

A well written summary. My only suggestion is that it might be worth
adding
language emphasizing that both Syn Caching and Syn Cookies *are* RFC
compliant
and merely represent host choices on how to select the ISN and/or encode
the
TCB (Syn Cookies essentially "storing" the TCB for the SYN- Received
state
through its choice of ISN).

_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Christian Huitema" <[email-masked]>
Date: Thu, 13 Apr 2006 16:54:45 -0700

> through its choice of ISN).

The SYN-Cookies approach actually modifies TCP in a significant way, by
removing protection against the loss of the first ACK message. Consider
the following:

	Initiator      Responder
	SYN ---->
	       <------ SYN+ACK
	ACK ---*(loss)

At this point in the state machine, the initiator will not repeat the
SYN, since it has already received the ACK. In standard TCP, this is
taken care of by the responder, which is supposed to repeat the SYN+ACK
until the SYN is acknowledged.

This is not a problem for applications like HTTP in which the first
message in the session is sent by the initiator. The HTTP sequence looks
like:

	Initiator      Responder
	SYN ---->
	       <------ SYN+ACK
	ACK ---*(loss)
	DATA+ACK --->

Even if the DATA + ACK is lost, it would be repeated. However, consider
a protocol like FTP, where the first DATA message is sent by the client.
If you use SYN cookies, the stack is not repeating the SYN-ACK. The loss
of the ACK results in the loss of the connection.

Now, consider a SYN flooding scenario. The responder is under attack,
the line is probably flooded, the packet loss rate is likely quite high.
Many good connections are going to be lost!

-- Christian Huitema