Design

Question 1

Why build security mechanisms into TFO to protect both the server and
other hosts from such attacks.

Answer 1

DDos: an attacker or set of attackers could send HTTP GET
requests to a server while spoofing the source address of a
victim host, thereby causing the server both to perform potentially
expensive request processing and to send a potentially
large response to a victim host

Question 2

goal in designing TCP Fast Open

Answer 2

to enable each
end of a TCP connection to safely transmit and process any
received data while the 3WHS is still in progress

Question 3

TFO accepts old SYN packets with data in some

rare cases

Answer 3

to manage stale or duplicate SYN packets

would add significant complexity to the design and the tradeoff is of

Question 4

TFO is restricted to applications

that are tolerant to duplicate connection / data requests.

Answer 4

But, Since a wide variety of applications can tolerate duplicate
SYN packets with data (e.g. those that are idempotent or perform
query-style transactions), we believe this constitutes an
appropriate tradeoff.

Question 5

Another assumption when using TFO

Answer 5

We assume that servers cannot
maintain permanent or semi-permanent per-client state since
this may require too much server memory, and that servers
may be behind load balancers or other such network devices

Question 6

More assumptions when using TFO

Answer 6

We also assume that servers cannot perform any operations to support TFO that are not reasonable to implement on the kernel’s critical path (e.g. symmetric cryptography is possible, but asymmetric is not)

Question 7

Big assumption here

Answer 7

Finally, we assume that it is acceptable to leverage other security mechanisms within a server’s domain (if needed) in concert with TFO to provide the required security guarantees.

Question 8

Our primary goal in the design of TFO is to prevent the
source-address spoofing attack mentioned above. To prevent
this attack, we use a

Answer 8

security “cookie”.

Question 9

an encrypted data string that is used

to validate the IP ownership of the client

Answer 9

The TFO cookie

Question 10

responsible

for generation and validation of TFO cookies

Answer 10

The Server

Question 11

The server periodically

revokes cookies it granted earlier by

Answer 11

rotating the secret key used to generate them. This key rotation prevents malicious parties from harvesting many cookies over time for use in a coordinated attack on the server.

Question 12

TFO’s goal (evolving…)

Answer 12

to allow data exchange during TCP’s initial

handshake while avoiding any new security vulnerabilities.

Question 13

A way to mitigate attackers

Answer 13

the server maintains a counter of total pending TFO connection requests either on a per service port basis or for the server as a whole

Question 14

When users often click refresh in web browsers if a page does not load quickly, this can result in

Answer 14

duplicate transactions

Question 15

If the TFO cookie is not

available

Answer 15

it falls back on a regular TCP three-way handshake

and the data is queued up for transmission when the 3WHSis completed.

Question 16

the use and handling of TFO cookies

is done by the networking stack and is

Answer 16

completely transparent to the application.

Question 17

The TFO cookie handling is transparent to applications

and the cookies received by a client from a server are not directly readable by applications unless they have

Answer 17

root privileges to sniff packets on the client. This prevents malicious sites from using simple browser hacks to trick users by making connections to other websites and stealing those TFO cookies for mounting an amplified reflection attack