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
Make up a false ip address
Send a bunch of SYN pks with data
Server does a lot processing
And gets overloaded
SYN-Flag+ Data
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
Use host B’s IP as source
Send a bunch of SYN pks with data
SYN-Flag+ 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
Let’s use
TFO
Here’s a
cookie for
next time
SYN-Flag+TFO-Option
SYN/ACK-Flag+ Cookie
ACK-Flag+Data
Second Connection to Same server
benefits
We are
using FTO:
here’s a
cookie for
proof.
SYN-Flag+Cookie+Data
SYN/ACK-Flag+ Data
ACK-Flag+Data
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