TCP Fast Open

We know this Web services use the TCP protocol at the transport layer. Standard TCP protocol to Three-way handshake (Three-way handshaking), the server can respond to the client's request to SE nd data. If The Three-way handshake phase, the client can send a request to the server, and the server sends a response, you can re Duce the delay of the WEB services.

1. Background

The standard TCP specification allows the client to carry application data in the SYN packet in the initialization connection, but the server's application will not be able to get the data that the SYN packet carries from the kernel until the three-way handshake is complete. If we remove this restriction directly, the client can carry the HTTP GET Request in the SYN packet, and the server will carry the response data in the Syn+ack package, although this can meet the requirements of TFO (TCP Fast Open), but it is vulnerable to a denial of service attack. An attacker could use a forged IP address to send a large number of SYN packets carrying an HTTP GET request to the server, which would cause the service side to fail to function properly. TFO requires a security mechanism to protect the server against such attacks. The goal of the TFO is to allow both TCP connections to securely exchange data during a three-way handshake.

2, TFO Design

TFO uses cookies to protect against address forgery attacks. If the client wants to use TFO, then the TCP TFO option needs to be turned on and a cookie is requested from the server when the TCP connection is established. Explains how TFO is used:

The entire process can be divided into two stages: the TFO cookie request phase and the TFO cookie usage phase. The Red line section represents the cookie request phase, as follows:

(1) The client opens the TCP TFO option to carry a cookie request in the SYN packet

(2) The server encrypts the client's IP address, generates a cookie, and then carries the cookie to the client in the Syn+ack package

(3) The client receives the cookie and caches it and uses the corresponding cache cookie when initiating the next connection request to the server.

The Blue Line section indicates the use phase of the cookie:

(1) The client sends a SYN packet that carries the cached cookie and application data to the server (need to open the TCP TFO option)

(2) After receiving the SYN packet from the server, the cookie is verified. If the cookie is valid, the server sends the SYN+ACK packet to confirm the client's SYN packet and the application data carried, and the server application can obtain the application data. If the cookie is invalid, the server discards the application data that the SYN packet carries, only confirms the SYN packet itself, and then uses the regular three-way handshake method to establish the connection

(3) If the server application receives the data carried in the SYN packet, the server may send the response data to the client before the client's ACK arrives, that is, the server can send the data to the client during the TCP connection.

(4) The client sends an ACK packet to the server to confirm that if the client carries data in the SYN packet is not confirmed, it will be re-routed in the ACK packet.

(5, the client and the server next use normal TCP processing method for data exchange

3. TFO Cookie

The TFO cookie is an encrypted data string that the server is responsible for generating and validating the TFO cookie. The client or the active open side of the connection caches the cookie and is used in subsequent initialization connections. The server encrypts the source IP address in the client SYN packet, generating up to 16 bytes of cookies. The encryption and validation of cookies is very fast compared to the processing time required for normal SYN packets or syn+ack packets. The client cannot generate a valid cookie without the key used by the server to generate the cookie.

4. Security Considerations

The goal of TFO is to exchange data during TCP connections and to avoid any new security issues.

4.1. SYN Flood Attack

If an attacker provides an invalid TFO cookie, the data in the SYN packet is discarded and the connection is then established using a normal TCP three-way handshake, then the server can use existing technologies such as SYN cookies to defend against the attack. If the cookie provided by the attacker is valid (any client can obtain a valid cookie from the server), then the server is at risk of resource exhaustion. To solve this problem, the server can maintain a pending TFO connection count for each port or all ports. A pending TFO connection indicates that the server has accepted the client's request and sent the Syn+ack packet, but has not yet received the ACK packet from the client. When a pending TFO connection count exceeds a certain threshold, all new TFO connections use the normal three-way handshake directly, allowing the service to be protected against attacks using an existing flood-resistant approach. In other words, an attacker could make the server and the client temporarily unable to establish a connection using TFO, but the two sides can still establish a connection using a three-way handshake to ensure that the server can continue to work.

The flood attack initially occurred in the late 90, and the attacker's goal was to overflow the server backlog queue, causing the new SYN packet to be discarded and the server not functioning properly. An attacker would normally send a SYN packet to the server using a spoofed, non-responsive address, or the server would receive an RST packet after sending the Syn+ack packet to the client. Once the RST packet is received by the server, the half-connection of the response is released, causing the attack to fail. For TFO connections, this type of RST packet increases the damage caused by the attacker because the server receives the RST packet and then releases the corresponding pending TFO connection, which makes the new TFO connection available. To solve this problem, the server does not release the pending TFO connection after receiving the RST wave until the timeout occurs.

4.2, Amplified Reflection Attack

The TFO connection allows the server to send response data to the server after the Syn+ack packet, and if there is no TFO cookie mechanism, it is susceptible to amplified reflection attacks. As mentioned before, the number of pending TFO connections on the server is limited, which guarantees that the server's resources are not exhausted.

5. Duplicate SYN packet

The current standard TCP allows application data to be carried in the SYN packet, but only after the three-way handshake is completed, the server application can obtain data from the kernel, primarily to handle duplicate SYN packets. Although the TFO connection does not carry data in the Retransmission SYN packet, it is possible to generate duplicate SYN packets with data in the network, which results in the server-side application re-receiving the data. Suppose that the TFO client sends a SYN packet carrying the data and actively closes the connection before the duplicate SYN packet arrives, and the server acts as a passive shut-down party that receives the duplicate SYN packet and processes the data that is carried. If the duplicate package is generated within 2MSL time, the server sends the Syn+ack package to the client, and the client is in the TIME_WAIT state at this point, it will reply to a RST packet to the server, causing the server to terminate the connection. However, the server still responds to this duplicate request. An exploratory scenario is that when the server receives the last ACK packet from the client, it keeps the server in the Last_ack state for 2MSL of time, which prevents the server from receiving late duplicate packets. Some applications, such as credit cards or banking applications, that do not tolerate duplicate transactions, ensure idempotent in the application layer.

6. Performance analysis

The performance analysis and other details can be referred to in the TCP Fast open article.

TCP Fast Open