2

Four-way handshake connection termination can be reduced to three-way and even two way one. Is it possible the three-way handshake connection establishment would be extended to four-way?

SYN=>
<=ACK
<=SYN
ACK=>
SerG
  • 1,251
  • 4
  • 18
  • 37

1 Answers1

4

Given the semantics of SYN and ACK it should be possible to send SYN+ACK in different packets and those delay the handshake. E.g. client sends a SYN, server replies with an ACK to acknowledge the wish of the client for a new connection, but it does not grant the wish yet. Later the server sends a SYN and gets the matching ACK back from the client and the connection is established. But I doubt that anybody does connection establishment this way and it might be, that some OS will croak on it.

But, there is another scenario for a four-way-handshake, however with a different ordering of the packets. It could happen, if both side try to establish a connection to the other side at the same time, e.g. both send a SYN to the peer, and get an ACK back. It is described in the RFC 793 (TCP) section 3.4. But I doubt you will ever see such a handshake, because it does not fit into the typical client-server-scenario where one end is waiting for connects and the other end does the connect.

Edit: the handshake you envision exists and it is called "split handshake". See http://hackmageddon.com/2011/04/17/tcp-split-handshake-attack-explained/ . And like I expected, it is not universally supported.

Steffen Ullrich
  • 114,247
  • 10
  • 131
  • 172
  • "Given the semantics ... it should be possible" I'm not sure if you prove the point basing on your RFC knowledges or just supposed it. – SerG Feb 08 '14 at 19:25
  • 2
    The semantic of ACK is only to acknowledge that data are received, the semantic of SYN is only to request a connection. Both flags are orthogonal to each other and don't have a special meaning when used together, similar to FIN and ACK, so it should not matter if they are send together or in separate packets. – Steffen Ullrich Feb 08 '14 at 19:49