Skip to content

RFC 7413 TFO Summary

Jump to bottom
derikclive edited this page Oct 16, 2017 · 1 revision

RFC 7413 - TFO Summary

What is TCP Fast Open?

TCP Fast open is an update to TCP that enables data to be transferred during the TCP Handshake. TFO allows data to be carried in the SYN and the SYN-ACK packets during the 3 way handshake thereby save one full RTT compared to the standard TCP.

Need for TCP Fast Open

Today’s web services are dominated by TCP flows so short that they terminate a few round trips after handshaking. Today’s TCP standard permits data exchange only after the client and server perform a handshake to establish a connection. This introduces one RTT of delay for each connection. TCP Fast Open (TFO) enables data to be exchanged safely during TCP’s initial handshake. TCP fast open decreases the latency by 1 RTT and hence decreases the load time of web pages.

How TFO Works?

The key components of TFO are:

  • Fast Open Cookie
  • Message Authentication Code (MAC)

Steps Involved

  • When the client is communicating for the first time with the server using TFO, it requests for a Fast Open Cookie. This is done by the following steps:

    1. The client sends a SYN packet to the server with the Fast Open option and the cookie slot empty.
    2. The server generates a cookie and sends it through the Fast Open option of the SYN-ACK packet.
    3. The client then stores the cookie for future TFO connections.

  • Now that the client has a Fast Open Cookie it can establish TFO connections with the server. The various steps involved in a TFO connection are:

    1. The client sends an SYN packet to the server with the data and the cookie.
    2. The server then validates the received cookie:
      • If the cookie is valid the server sends an SYN-ACK acknowledging the SYN as well as the data and delivers the data to the Application Layer.
      • If the cookie is not valid, the server drops the data and sends an SYN-ACK packet acknowledging only the SYN sequence number.
    3. If the cookie was valid the server sends the requested data before the handshake finishes.
    4. The client sends an ACK acknowledging the SYN and the server data. If the client’s data is not acknowledged, the client retransmits the data in the ACK packet.
    5. The rest of the connection proceeds like a normal TCP connection.

Details of the Protocol

1. Fast Open Cookie

The purpose of this cookie is to mitigate new security vulnerabilities caused by exchanging data during the handshake. It cannot be read by the client. The minimum size of the cookie is 4 bytes.

2. Handling of the Cookie at the Server side

The server is in charge of cookie generation and authentication. The generated cookie shoulds satisfy the following properties:

  • The cookie authenticates the IP address (IPv4 or IPv6) of the client’s SYN packet.
  • The cookie can be generated only by the server and no one else.
  • The generation and verification of the cookie must be fast compared to the SYN and the SYN-ACK processing.
  • The server can accept more than one valid per client at any time.
  • The cookie expires after a certain period of time.

The server maintains two variables:

  • FastOpenEnabled: It is turned off by default, it should be turned on explicitly by the application.
  • PendingFastOpenRequests: Tracks the number of pending TFO connections in SYN-RCVD state. If this value goes over a certain limit the server disables all TFO connections.

The server supports two functions cookie-generation and verification.

3. Handling of the cookie at the client side

The client must cache the cookie received from the server for later TFO connections. The client can also cache the Maximum Segment Size (MSS) advertised by the server. The client MAY limit the cached MSS to 1460 bytes for IPv4 or 1440 for IPv6.

The client must cache negative responses from the server in order to prevent connection failures. For any negative response, the client should disable TFO on that specific path at least temporarily.

Vulnerabilities of TFO

  1. Resource Exhaustion Attack by SYN Flood with Valid Cookies An attacker can obtain valid cookies from compromised hosts and flood the server with spoofed SYN packets with data and valid cookies. But here the damage is more severe than a normal TCP as it can exhaust the server’s CPU and memory resources.

This can be prevented by limiting the maximum number of pending TFO connections. When the number of connections increases over the limit the server disables the TFO connections.

Clone this wiki locally