TCP for today’s Web

Connections today Web-page > 300KB but objects are small 7.5KB -2.4KB [25] lots of small objects in a page. Implication: TCP Handshake == 10%-30% penalty

Add data into Handshake SYN-Flag SYN/ACK-Flag ACK-Flag+Data Let’s talk

How about HTTP1.1 What is HTTP1.1 – Persistent keep alive – Re-use old connections so no more TCP handshakes But … – browser tries to be fast opens multiple TCP connections (limits reuse) – Domain sharding -- place resource on different domains to further increases parallelism (so forced to use diff connections). – MB terminate idle conns to reduce state --> so persis con no longer persistent. – mobile devs shut down conns to conserve power

Status of HTTP1.1 92% conn use HTTP1.1 – But still Handshake has 5-7% overhead in general – For first use of connect, overhead is 8-27% Chrome always uses HTTP1.1 – But 33% of conn use new TCP

New Security Attacks SYN-Flag+ Data SYN/ACK-Flag+ Data ACK-Flag+Data

New Attacks: SYN Flood SYN-Flag+ Data Make up a false ip address Send a bunch of SYN pks with data Server does a lot processing And gets overloaded Note: Since you used a fake address, the response from the server don’t come to you, so you don’t maintain state or devote resources

New Attacks: Reflection SYN-Flag+ Data Use host B’s IP as source Send a bunch of SYN pks with data Note: Every server responds to host B with a flood of packet. Host B gets attacked. Once against you don’t devote any resources on your machine to do attack. And since response is larger than syn-flag+data it is better than you attack direction

Attack Model Attacks work because: – Attacker can spoof SRC IPs. To prevent this: – TFO adds a cookie to the protocol – Client must include cookie in the handshake – The cookie is an encrypted version of source IP Source IP encrypted with the server’s private key Server unencrypts cookie and compares

System Assumptions Acceptable Changes: 1. symmetric crypto – (can be done in fast path) but no asymmetric. 2. soft state – (can't keep permanent state-- scale issues) 3. minor App changes – Don’t want to prevent adoption

Add Cookie to the First Handshake SYN-Flag+TFO-Option SYN/ACK-Flag+ Cookie ACK-Flag+Data Let’s use TFO Here’s a cookie for next time

Second Connection to Same server benefits SYN-Flag+Cookie+Data SYN/ACK-Flag+ Data ACK-Flag+Data We are using FTO: here’s a cookie for proof.

Second Connection to Same server benefits SYN-Flag+Cookie+Data SYN/ACK-Flag ACK-Flag+Data

Attacks Revisited Reflection – To get cookie must compromise host or network If you can then you don’t need reflection SYN Flood – We limit the number TFO connections – So server is still always willing to accept regular TCP connections

Deployment Issues Middleboxes are HORRIBLE – They drop new TCP options – NAT changes IP addresses so cookies can’t work

Deployment Issues: Load Balancers LoadBalancer

Deployment Issues: Load Balancers LoadBalancer All servers need to share the same key so TFO can work. So, you may need to also change the keys more frequently

Lessons A webpage === lots of small objects – Harder to ameliorate overheads TCP Handshake overhead 2 RTT  Loss detection Most common loss pattern in WAN – Last packet in small connection – Use redundancy (FEC) to overcome this. Eliminate Handshake overhead – Send packet during the handshake – Insert secret cookie in handshake to eliminate attacks