Subject: RE: [tcpm] syn flooding draft

From: "Caitlin Bestler" <[email-masked]>
Date: Fri, 14 Apr 2006 09:11:35 -0700

Christian Huitema wrote:
>> 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).
> 
> 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

Only if you have a server that accepts a large number of connections
where the initiator sends no data. I doubt there are many such
servers.

Syn Cookies are indeed designed for unbound listens that
accept connections from virtually anybody. The core of their
design is protection from forged source IP addresses.

You do raise an excellent point, however, that this defense is
not appropriate for specialized connections (such as secondary
connections with FTP). One of the benefits of having an RFC,
even an informational one, is encourage some standardization
of the feature as well as its use. One such suggestion would
be that syn cookies should be enabled on a per listen basis.

In my opinion that enabling should be for any port that has
a signifigant backlog.

Can you cite an example where the passive side would send
the first data and be accepting a large number of connections
from unknown remote peers?

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

---

From: Ethan Blanton <[email-masked]>
Date: Fri, 14 Apr 2006 12:15:44 -0400

> from unknown remote peers?

ssh

Ethan

-- 
The laws that forbid the carrying of arms are laws [that have no remedy
for evils].  They disarm only those who are neither inclined nor
determined to commit crimes.
		-- Cesare Beccaria, "On Crimes and Punishments", 1764
_______________________________________________
tcpm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tcpm

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 14 Apr 2006 10:51:35 -0700

> > from unknown remote peers?

SMTP, if implemented according to RFC2821, which states (section 4.3.1
Sequencing Overview, page 47):

   One important reply is the connection greeting.  Normally, a receiver
   will send a 220 "Service ready" reply when the connection is
   completed.  The sender SHOULD wait for this greeting message before
   sending any commands.

Obviously, implementations of SMTP could decide to override the SHOULD
and send a HELO/EHLO message anyhow, but that is a change in spec...

-- Christian Huitema