Why is in TCP a 3-way handshake used during establishing a connection? Meaning, why it is not enough to use a 2-way handshake?
6 Answers
So that both ends can be fairly confident that the other end knows that the connection is established.
EDIT: Two way is not enough, as the recipient cannot know that the sender knows that the recipient has responded, and the connection is ready to go and this make it (2-way handshake connection) unreliable in comparison to 3-way handshake
-
Nice, but way 2-way is not enough? – Artem Barger Jul 05 '09 at 08:21
-
4If I spoofed a SYN packet from a fake address, and then the receiver responded with an ACK packet to that address, if it was only a two way handshake, the receiver of the SYN packet would think it had established a connection, when it hadn't, because the spoofed address would have just dropped the ACK packet. The three way handshake avoids this. – Dentrasi Jul 05 '09 at 08:48
-
@Dentrasi: That is a nice additional benefit. – womble Jul 05 '09 at 09:47
The handshaking mechanism used in TCP is designed so that two hosts, attempting to communicate, can negotiate the parameters of the network connection before beginning the communication. Both sides can assume that the other computer is ready and start to reliably send data.
Here is a simplified diagram of the packets being sent on both sides during the handshake:
SYN -> SYN received Host A <- SYN ACK Host B SYN ACK received ACK -> ACK received TCP connection is established
SYN (synchronize) and ACK (acknowledge) messages are specified by a bit/number inside the TCP header of the segment.
The process is also designed so that both ends can initiate and negotiate separate connections at the same time.
In order to end a connection between two computers, another 3-way communication is performed to tear down the TCP connection. The initiation and teardown of a TCP connection is part of what makes TCP a reliable protocol.
Realize that it is really a 4-way handshake (two in each direction). There is a SYN -> ACK and and a SYN <- ACK. Host-B just saves time by sending his SYN at the same time he ACK's Host-A.
Also, Dentrasi had a comment that the 3-way handshake prevents spoofing but this is not entirely true.
See more information at the nmap site: http://nmap.org/book/osdetect-usage.html
"TCP Sequence Prediction Systems with poor TCP initial sequence number generation are vulnerable to blind TCP spoofing attacks. In other words, you can make a full connection to those systems and send (but not receive) data while spoofing a different IP address. The target's logs will show the spoofed IP, and you can take advantage of any trust relationship between them. This attack was all the rage in the mid-nineties when people commonly used rlogin to allow logins to their account without any password from trusted IP addresses. Kevin Mitnick is alleged to have used this attack to break into Tsutomu Shimomura's computers in December 1994."
Additional information on TCP sequence prediction attacks here: http://en.wikipedia.org/wiki/TCP_sequence_prediction_attack
- 5,403
- 1
- 25
- 32
Non-tech explanation-- 3 way handshake is required for a full duplex conversation/connection. A Connection means agreement between two parties. Agreement means, when X send then Y receive and when Y send X receive. Each of this single sided agreement requires two steps each, ask for permission (SYN) and to know other will listen/receive/take (ACK) what you send. So two SYN-ACK steps.
It essentially is a 4-Way Handshake, the step-2 (sending ACK to X by Y) and step-3 (sending SYN to X by Y) are merged (step-3 piggy-backed on step-2), in the end resulting in one step. This is possible since both are send at the same time from Y (same host), and the information is carried in a bit in TCP header (no over-size issues). Thus in total 3-steps from 4-steps.
tech-explanation -- TCP is a stateful protocol, the way its state machine operates and changes its states is symmetric at both the ends. The established state is reached, when you receive the ACK from the other machine. For the both the entities to reach the connection established state, the states machines has to receive an ACK. So ACK receiving is important, and to receive an ACK a host has to send a SYN. Well again 4-step process merged into 3-steps, see quoted explanation.
Rest are details -- like picking a random SYN value, so that predictions attacks can be prevented. As far as an attack is concerned, Man-in-the-middle is imminent. ps put a comment if anyone wants to know how. I think most of you would know how, its very obvious, so i saving you reading time.
- 465
- 2
- 5
- 14
The three way handshake establishes the connection. Just like when you pick up your telephone, get a dial tone, dial the number, hear ringing, and then the other party says "hello".
- 1,672
- 1
- 23
- 33
There was an attempt long ago to reduce the number of "administrative" packets required to set up and tear down an short-lived TCP connection. It was called "TCP for Transactions" or "T/TCP" and is described in RFC1644:
http://www.faqs.org/rfcs/rfc1644.html
TCP was originally designed to provide a virtual circuit for long-lived connections, where setup and tear down time wasn't as important. As the client-server model became more prevalent, the need for something like T/TCP became more apparant.
T/TCP uses some server-caching mechanisms to allow the first packet of a new connection to contain data. The teardown request from the server side can also piggyback on the last data packet. That reduces the number of packets required for a single-packet-payload message fto three.
Unfortunately, T/TCP never reached critical mass.
- 6,549
- 1
- 25
- 23