Bug 242492 - [tcp] TCP fast open observability
Summary: [tcp] TCP fast open observability
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 12.1-RELEASE
Hardware: Any Any
: --- Affects Only Me
Assignee: Michael Tuexen
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-06 22:31 UTC by j2465
Modified: 2021-04-18 15:13 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description j2465 2019-12-06 22:31:25 UTC
A TCP connection made by sendto() with TCP_FASTOPEN set always sets the
TCP_FASTOPEN readback getsockopt.  It would be (possibly more) useful to the
client application to know if a supposedly valid TFO cookie was sent on the SYN
(as opposed to the current possibilty of only having sent a TFO request) and/or
whether the server agreed that the cookie was acceptable.

TCP_INFO TCPOPT_FAST_OPEN appears to match getsockopt/TCP_FASTOPEN, for a client.

I'm not sure that we really want to go so far as knowing whether client
data-on-SYN was actually accepted with the SYN, but it's another item in the
bucket.
Comment 1 j2465 2021-04-18 15:13:22 UTC
Related, though possibly should be a separate bz:

API for a server application to arrange for Fast Open data to travel in
the SYN,ACK packet.  I can see two possible implementations:
a) where the application pre-loads data before the SYN arrives
b) where the application supplies data between the SYN arriving and the
   SYN,ACK being sent, permitting the data to depend on the initiating IP

Primary use-case is for SMTP, where the server banner is the first data sent
for the application-level protocol.  I could see it being of use for TLS also,
where the Client Hello can travel on the SYN and the Server Hello on the
SYN,ACK (in fact, with kTLS this may not need a kernel/user API).