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 addressSend a bunch of SYN pks with data

Server does a lot processingAnd 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 sourceSend 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