Subject: Re: 3-way handshake delays

From: Bill Fenner <[email-masked]>
Date: Wed, 7 Nov 2001 13:18:17 -0800

Some time ago, I remember seeing an idea which would cause this kind
of 3-way handshake delays.  I don't remember who suggested it or where.
Basically, the idea is to only send the SYN/ACK after the first I/O is
posted to the socket (read, write, probably select).  It "should" be
backwards-compatible, since programs usually do an I/O immediately after
accept(), but programs aware of the different API could, e.g., close the
connection (causing a RST, perhaps) based on IP address access control
(or some such), causing an attacker to think that the port is closed.

I never heard of an implementation of this, but I've always thought it
was a potentially neat idea.

  Bill

---

From: Joe Touch <[email-masked]>
Date: Wed, 07 Nov 2001 16:52:07 -0800

> was a potentially neat idea.

Seems like a good way to cause a timeout.

The data can't go to the application anyway; the connection doesn't 
exist until after the ACK comes back, so making a decision based on any 
connection information seems invalid, IMO.

Joe

---

From: Erich Nahum <[email-masked]>
Date: Thu, 8 Nov 2001 00:28:48 -0500 (EST)

> connection information seems invalid, IMO.

Joe is correct.  The connection can't be delivered to the application
(or accept queue) until the client ACK returns for the server's SYN-ACK.

I mis-understood the original question.  What can happen on AIX is that
the ACK of the SYN-ACK on the *client* can be delayed, hoping to piggyback 
on an outgoing segment (such as the first GET request) (since connect() only
blocks until the SYN is ACKed).  The server shouldn't deliberately delay 
the ACK of the SYN from the client.

-Erich

-- 
Erich M. Nahum                  IBM T.J. Watson Research Center
Networking Research             P.O. Box 704
[email-masked]            Yorktown Heights NY 10598