In our last article on TCP, we talked about how TCP was designed step by step to ensure the reliability of its message delivery. See also: TCP’s Sliding Window mechanism: How its design evolved (from scratch to Reliable?)

In this section, we will start with the TCP three-way handshake and learn the details of the use of serial numbers in TCP transmission.

TCP three-way handshake

Before data transmission between the two parties of TCP communication, a connection needs to be established.

This connection is virtual and is primarily identified by a socket pair, or quad, that is, source IP, source port number, destination IP, and destination port number. Actually, to be exact, there’s another protocol type, TCP.

Through this connection process, several things can be done:

  • The server knows the information of the client and knows who to establish a connection with.
  • For each new connection, both parties inform each other of their initial ISN for the first subsequent data transfer.
  • The parties exchange control information to control how the subsequent interaction should proceed.

TCP marks a

For the TCP three-way handshake, two flag bits are involved, namely the SYN flag and the ACK flag.

The SYN Flag (Synchronize Flag) is a one-bit field. If the value is set to 1, a new connection is initialized and the ISN (Initial Sequence Number) is synchronized.

ACK (Acknowledgement Flag), the length of the field is 1 bit. If this parameter is set to 1, the confirmation serial number on the header is valid. It is used for the receiver to confirm the received data after receiving the packet segment. It can also be used to confirm SYN packets.

The basic three handshakes

To establish a connection, both parties send a SYN packet and receive an ACK packet from the other party.

Theoretically, each party has to go once, and a total of four control messages need to be sent to complete the connection.

Typically, the server is listening on a port, the client sends a request connection message, and the server responds. Because the server also needs to send SYN packets to the client, you can merge the SYN packets and ACK to the client into the same packet, reducing one interaction.

This is the TCP three-way handshake.

handshake

A very important purpose of the three-way handshake is to inform each other of their initial sequence number, so that the subsequent two parties can send and join data based on this sequence number to prevent packet order out of order.

The procedure for notifying the initialization of Sequence Numbers is called SYN (Synchronize Sequence Numbers).

The flow of the three-way handshake is shown below:

(Photo: coolshell.cn/articles/11…

First, the server listens on a TCP port, then the client initiates a connection and performs a three-way handshake:

  1. The client sends a SYN packet to the server, carrying its own initialization sequence number X. TCP Flags SYN set to 1
  2. The server sends a SYN+ACK packet to the client, carrying the initial sequence number y and the confirmation sequence number X +1 for the client. (TCP Flags SYN and ACK Flags are set to 1.)
  3. The client sends an ACK packet with the sequence number Y +1 to the server. (TCP Flags ACK set to 1)

If the preceding three steps are successful, a virtual connection is ESTABLISHED between the client and server, and the state of the connection is ESTABLISHED.

In this case, the current serial numbers of the client and server are X +1 and Y +1 respectively, which serve as the serial numbers of the next package of both parties.

In addition, the figure shows that the serial number of FIN packets sent by the client and server increases by 1 after the ACK of the other side.

Caught the sample

Using the Wireshark to capture the TCP three-way handshake from 192.168.31.163 to 192.168.31.131:

From top to bottom:

  1. The first packet [SYN] Seq=0, indicating that this is a SYN packet, 192.168.31.163 initialization sequence number is 0;
  2. The second packet [SYN, ACK] Seq=0 ACK =1, indicating that this is a SYN+ACK packet. The initial sequence number of 192.168.31.131 is 0 and the confirmation sequence number of 192.168.31.163 is 1.
  3. The third packet, [ACK], indicates that this is an ACK packet. 192.168.31.163 confirms 192.168.31.131 with sequence number 1.

If we do not know the TCP sequence number, we may mistakenly see that the initialization number of the three-way handshake is 0, which is the real initialization number, and it is the same every time.

To view the true serial number, you can modify the Wireshark configuration: Edit > Preferences > Protocols > TCP Relative Sequence Numbers and deselect the check box to display the absolute serial number. The effect is as follows:

About the serial number

Here is a nice TCP head structure:

(Photo: hauptj.com/2018/10/08/…

The first two parts are the Source Port number and Destination Port number, each with 16 bits.

This is followed by the Sequence Number and Acknowledgement Number, and the TCP Flags in between.

Sequence Number

Indicates the serial number of the sent packet segment. It can also be understood as the position of the sent data. This position represents the first byte of the data part of the packet segment.

The serial number field is an unsigned 32-bit number that ranges from 0 to 2^ 32-1 (4,294,967,295). When the number reaches its maximum value, it increments from 0 again.

Each time data is sent, the serial number accumulates the size of the data bytes. For example, if the serial number is 1 and the data size is 4 bytes, the serial number of the data to be sent next time is 1+4=5.

Main functions of serial numbers: Used to solve the problem of out-of-order network packets. Ensure that the receiver receives and processes the packet data in the correct order.

Acknowledgement Number

The confirmation sequence number is a 32-bit unsigned number used by the receiver to confirm the location of received data to the sender.

After receiving the confirmation number, the sender can assume that all data prior to the confirmation number value minus 1 has been received normally.

Since each byte transmitted is counted, the acknowledgment sequence number contains the next sequence number that the end that sent the acknowledgment expects to receive. Therefore, the confirmation sequence number should be the last successfully received data byte sequence number plus 1.

The confirmation sequence number field is valid only when the ACK flag in the TCP flag header is 1.

The main function of the confirmation serial number is to solve the problem of not losing packets. Notifies the receiver of what data has been received.

Initialize the ISN (Initial Sequence Number)

We’ve talked a lot about serial numbers.

For both sides of the communication, the initial serial number of the data sent starts from the initialization of the serial number.

The initialization sequence number is exchanged between two parties during a three-way handshake.

For each party, the first byte of data actually sent is its ISN+1.

So, how is the initialization sequence generated?

traditionally

Traditionally, a clock counter is used to select an initial sequence ISN. This counter is initialized when TCP starts and then increments by one every four microseconds.

Each time a connection is established, the current value is obtained from the counter as the ISN for the connection.

Increasing the counter from 0 to a maximum of 4,294,967,295 (2^ 32-1) takes about 4.77 hours. Therefore, it is guaranteed that different connection initialization numbers will not conflict.

now

The problem with the counter approach, while it is guaranteed that different connection initialization ordinals do not conflict, is that it makes the ISN predictable because it is time dependent.

To solve the problem of predictability of an ISN, current implementations generally use random numbers to generate an ISN.

When creating a new connection:

  1. Generate an initial ISN at random;
  2. And fill in the number of the head;
  3. The SYN flag in TCP header Flags is set to 1.
  4. Sends a SYN packet to establish a handshake.

This is the simplified process of generating the initialization sequence number and notifying the peer host.

TCP hijacked

If an attacker can obtain an initialization sequence number, then the packet can be forged.

Speculation ISN value

The intruder listens to the ISN at different times through the request reply method and obtains a discrete ISN and time mapping table, for example:

Serial number: ISN0 ISN1 ISN2…

Time: T1, T2, t3…

With the mapping table of time and ISN, it is easy to derive an ISN generating function that depends on time T by some mathematical method.

Using this formula, an attacker can predict the next possible ISN based on the time interval.

For example, in the following test, ISN has a linear relationship with time:

(photo: www.techrepublic.com/article/tcp)…

The problem

Why three handshakes?

In the article “TCP’s Sliding Window mechanism: How its design evolved (From scratch to Reliable?),” TCP requires ACK acknowledgement to ensure the reliability of its messages.

Therefore, there must be at least one acknowledgement packet for each SYN packet.

If the handshake is reduced to two handshakes, the server will not receive the client’s acknowledgement of its SYN packet and will not be able to confirm whether the client received its SYN+ACK packet.

If you increase the number of handshakes, such as four, then you increase the number of communication handshakes, and the efficiency will be reduced. Furthermore, TCP already merges the server’S SYN and ACK to reduce the number of times a connection is established.

Of course, you might also wonder, what if the server doesn’t receive the last ACK from the client? Would it be better for the server to send an ACK to confirm that the server actually received it? You can, but you don’t have to. On the one hand, TCP has a retry mechanism. On the other hand, data is usually sent after a connection is established. This ensures that the connection is established before data transmission.

Therefore, the three-way handshake is a reasonable choice for TCP.

Why doesn’t the initialization sequence number start at 1?

You may wonder why the TCP initialization sequence number is so complicated that it can’t just start at 1.

One problem with starting each connection at serial number 1 is that it is possible for multiple connected datagrams to cross string.

Suppose host S establishes a connection with host D, and S sends some packets to D. If, for some reason, the connection breaks. Then, S and D re-establish the connection and initialize the serial number to 1. At this time, the packet sent last time may be delayed until the arrival of the new connection due to network congestion and other reasons. After receiving these packets, D will mistake them as packets sent from the new connection S.

Therefore, TCP uses the counter or random generation mode to ensure that no conflicts occur within a short period of time.

www.tcpipguide.com/free/t_TCPC…

www.tcpipguide.com/free/t_TCPC…

Hauptj.com/2018/10/08/…

www.techrepublic.com/article/tcp…

Coolshell. Cn/articles / 11…

TCP/IP Volume 1: Protocols

Personal public account

For more articles, please pay attention to the public number: binary road