Perform TFO cookie exchange for all TFO cookie requests

[rscheff]

Summary

when sysctl net.inet.tcp.fastpath.acceptany is enabled,
FastPath would accept incoming SYN with data, even when
they only request a cookie (TFO option without data).

[tuexen]

My understanding is that if net.inet.tcp.fastpath.acceptany is set, all cookies are excepted. This includes empty cookies as mentioned in RFC 7413.

[rscheff]

In D28686#641967, @tuexen wrote:

My understanding is that if net.inet.tcp.fastpath.acceptany is set, all cookies are excepted. This includes empty cookies as mentioned in RFC 7413.

Correct, it may generate an empty cookie - and accept SYN data with a empty cookie. However, with acceptany, the server will never actually generate a FastOpen response, thus a Client will not know that TFO is supported by the server.

A client will have to perform SYN+data speculatively, since the Server never response even with an empty TFO.

Looking at the client side, it appears that SYN+data is only sent on a subsequent sendto(), if a prior session carried the TFO in the SYN,ACK from the server - when the client has a key entry for that server.

Let me expand the special case here perhaps, to return a zero-filled, minimum-length cookie without doing the hashing.

[tuexen]

In D28686#641972, @rscheff wrote:

In D28686#641967, @tuexen wrote:

My understanding is that if net.inet.tcp.fastpath.acceptany is set, all cookies are excepted. This includes empty cookies as mentioned in RFC 7413.

Correct, it may generate an empty cookie - and accept SYN data with a empty cookie. However, with acceptany, the server will never actually generate a FastOpen response, thus a Client will not know that TFO is supported by the server.

A client will have to perform SYN+data speculatively, since the Server never response even with an empty TFO.

Looking at the client side, it appears that SYN+data is only sent on a subsequent sendto(), if a prior session carried the TFO in the SYN,ACK from the server - when the client has a key entry for that server.

Let me expand the special case here perhaps, to return a zero-filled, minimum-length cookie without doing the hashing.

In my personal view, the net.inet.tcp.fastpath.acceptany is for debugging only. I would like to get rid of it, after adding a way to use empty cookies which can be controlled by a socket option. So if you don't need the protection, just use empty cookies as described in RFC 7413. And you can control this on a socket level granularity.

[rscheff]

Glancing at this, the current fastopen infrastructure doesn't seem to have any mechanism to provide shorter key-length keys. The server side key generation is apparently done asynchonously, and reused for all clients requesting TFO. Thus special casing the acceptany when sending out the TFO option, to send out a shorter key there.

[rscheff]

The problem is with the negotiation part - a zero length cookie, while acceptable per RFC, still needs to be sent back to a client, for it to send out SYN+data. Otherwise, a regular SYN followed by a PUSH,ACK appears to be happening.

However, it appears that dealing with zero length cookies needs more work - the alternative would be to send out a length=4, zero filled cookie, to save slightly on option space. Also, the server cookie length is hardcoded and fixed (not controlled by any sysctl), which may pose problem when multiple SYN options use up space...

The above tweak will guarantee the TFO negotiation to take place with the existing server-side key (and client-IP-specific hashing).

[tuexen]

Let's discuss this at the next Transport call...