TCP Fast Open (TFO) is a relatively new TCP feature. The corresponding RFC7413 was published in 2014 and labeled "Experimental" [1]. The feature has been showing up in browsers and operating systems in the last couple of years. In particular, together with TLS 1.3, it can significantly decrease the time it takes to set up a connection.

The "textbook" TCP handshake starts with an "SYN" packet from the client to the server. The server responds with an "SYN-ACK," and finally, the client completes the handshake with an "ACK." The original RFC for TCP (RFC793) does allow the first "SYN" packet to hold data, but the server does not process the data until the handshake is complete. As a result, there is no point in sending data that early, and historically, data on SYN was hardly ever seen legitimately.

One of the reasons TCP servers do not respond immediately is the danger of spoofing. It is possible to spoof TCP SYN packets. A spoofed HTTP request over TCP could trick the server into flooding an unsuspecting victim with data, leading to amplification attacks as we usually see with UDP. By waiting until the handshake is completed, some spoofing danger is reduced by verifying the sequence numbers.

TFO is built for a particularly common use case where a client establishes multiple connections to a server in quick succession. The first time the client connects, it uses a specific TCP option to request a "TFO Cookie." The server will respond with a unique cookie. Future SYN packets by the same client will include this cookie, validating that the packet is not spoofed. Data is processed immediately if the cookie is valid. Any data will be buffered if the cookie is invalid until the handshake is complete, falling back to the pre-TFO behavior.

The cookie itself has to be at least four bytes long. The RFC suggests that the server encrypts the IP address with a secret only known to the server. Four bytes is as long as the TCP sequence number and should provide a similar level of security. As far as the client is concerned, the cookie is a "random" value that is saved for a particular server.

Now why the lengthy introduction?

Lately, I am seeing a good number of Suricata alerts like:

[**] [1:2200036:2] SURICATA TCP option invalid length [**] [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 

Investigating them, I found that these alerts point to connections with short 2-byte TCP cookies. I see these packets from about a dozen different sources, but one source, 135.181.78.222 is by far the most "popular" one.

Here is a decoded sample packet:

The packets always use a 2-byte TFO cookie. No server provides a cookie, so the cookie is "spoofed." The source IP itself may be spoofed. TTLs appear to be "random," and other parameters like the MSS change from packet to packet.

So the real question: Why? Is this an attempt to detect how servers respond to these invalid cookies? Maybe someone found some form of application attack? The packets do not include payload, so a bit hard to tell. Or some cover channel using TFO cookies as a "key"?

I am attaching a copy of the traffic I saw recently from 135.181.78.222. The destination IP is obfuscated.

https://isc.sans.edu/diaryimages/oddtfo.pcap

[1] https://www.rfc-editor.org/rfc/rfc7413.html 

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|