Scribd
Upload
239 views

TCP Fast Open

TCP Fast Open (TFO) is a technique that allows for data exchange during the TCP three-way handshake to reduce latency by one round-trip time for some connections like HTTP requests. It uses a cookie granted by the server as proof of IP ownership to address security issues with sending data in the initial SYN packet. Mitigations are proposed to limit the impact of potential denial of service attacks using spoofed SYN packets. The technique has been implemented privately in the Linux kernel and Chrome browser, and tests on live Internet connections showed it worked to reduce latency on connections to servers on major networks.

Uploaded by

philscribd611
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
239 views

TCP Fast Open

TCP Fast Open (TFO) is a technique that allows for data exchange during the TCP three-way handshake to reduce latency by one round-trip time for some connections like HTTP requests. It uses a cookie granted by the server as proof of IP ownership to address security issues with sending data in the initial SYN packet. Mitigations are proposed to limit the impact of potential denial of service attacks using spoofed SYN packets. The technique has been implemented privately in the Linux kernel and Chrome browser, and tests on live Internet connections showed it worked to reduce latency on connections to servers on major networks.

Uploaded by

philscribd611
Copyright
© Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 11

TCP Fast Open

draft-cheng-tcpm-fastopen-00.txt

Yuchung Cheng, Jerry Chu, Sivasankar Radhakrishnan, Arvind Jain {ycheng, hkchu, sivasankar, arvind}@google.com

TCP fast open (TFO)


First HTTP request needs to do TCP 3way handshake (3WHS) 1 RTT slowdown 35% Chrome HTTP requests
www.ietf.org/proceedings/80/slides/tsvarea-0.pdf

Goal Data exchange (client and server) in 3WHS

Naive data-in-SYN?
RFC793 TCP 3WHS Allows data in SYN Forbids processing data until 3WHS completes Problems with data exchange in 3WHS? 1. Duplicate/old data from prior connections 2. Server resource exhaustion attack 3. Amplified reflection attack

TCP fast open design


Default: off App that tolerates duplicate SYN-data does setsockopt(TFO) Cookie: server grants cookie as proof of IP ownership [we exchanged data before] TCP option (64bits) MAC of client IP and a server secret

Network dropping SYN with data or new options?

Mitigating security issues


Spoofed TFO SYN flood is still possible Obtain some (valid) cookies: DHCP / NAT, Moles Flood spoofed SYN w/ data/cookie Server resource exhaustion attack
TFO Syn-flood Goal Requirement Exhaust data processing resources 1. Vantage point to flood spoofed SYNs 2. Obtain some validate cookies 1. Limit max TFO connections in SYN_RCVD 2. Update server key every X min Traditional Syn-flood Overflow syn queue 1. Vantage point to flood spoofed SYNs RFC4987 (Syn-cookies)

Mitigations

RST in rsp to SYN- Fuel the damage ACK

Lower the damage

Mitigating security issues (cont'd)


Amplified reflection attack 1 SYN+data to trigger multiple server packets to random victim Disrupt/DOS victim's network Mitigations Limit TFO connections in SYN_RCVD Update the server key every X min Extra mitigations for server farms for extreme cases Respond only SYN/ACK during 3WHS Server can still process request one RTT earlier

Related work
TCP Fast Open (TFO) TCPCT (RFC6013) Designed Cheng et al., 2010 Bill Simpson, 2009 T/TCP (RFC1644) Bob Braden, 1994

Goal

Data exchange in 3WHS

1. Defend any SYN flood 1. At-most-once semantic 2. Quick conn setup/ tear- 2. Quick conn setup / down teardown DNSSEC Transactional one packet RPC per-IP counter at client/server ?

Motivating Application Additional States

Web

client caches server cookies

no Partially implemented in Linux

Implementation (private) Linux and Chrome patch

Conclusion
TCP Fast Open Data exchange in TCP handshake 1 RTT savings on 35% of HTTP requests Cookie to mitigate security vulnerabilities Implementation Linux (private patch) and Chrome Tested TFO on live Internet connections Worked on Comcast, ATT, etc. web server application: only setsockopt(TFO) Questions/comments?

Alternate design: one-time cookie


1. Generation: cookie = AES_128_encrypt(IP | counter, key) counter += 1 2. Validation: IP_c | counter_c = AES_128_decrypt(cookie, key) IP_c == IP in SYN 3.

TFO Server states O(1) (key)

One-time cookie O(n): n #cookies small scalar factor one cookie per connection 128bits

Client states Cookie Size

one cookie per svr IP 32bits - 128bits

Amplified reflection attack

1 (small) SYN for ${init_cwnd} data packets

You might also like