220 likes | 311 Views
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.
E N D
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 Server does a lot processing And gets overloaded Make up a false ip address Send a bunch of SYN pks with data 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