Technical Overview of QUIC
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Technical Overview of QUIC

on

  • 8 views

Technical Overview of QUIC protocol presented in HTTP2 Conference Japan 2014

Technical Overview of QUIC protocol presented in HTTP2 Conference Japan 2014

Statistics

Views

Total Views
8
Views on SlideShare
6
Embed Views
2

Actions

Likes
2
Downloads
0
Comments
0

2 Embeds 2

http://http2study.connpass.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Technical Overview of QUIC Presentation Transcript

  • 1. QUICの話 Technical Overview of QUIC 大津繁樹 Shigeki Ohtsu InternetInitiative Japan 2014 Nov. 3 HTTP/2 Conference Japan 2014
  • 2. CurrentIssues in TCP •TCP Head of Line Blocking. •Handshake cost by 3way handshake. •Small initcwndand slow start. •Large backoffcaused by packet loss. •Increase socket buffer. •NAT timeout and IP roaming •TCP Buffer Bloat TCP Fast Open initCWND10 TCP cubic Random packet drop in router TCP_NOT_SENT_LOWAT Need to upgrade OS on both end and middle box. It’s a long way.
  • 3. Current Issues in TLS •Handshake cost in TLS negotiation •Blocking in Change Cipher Spec •256bytes limit in ClientHelloby Load Balancer bug. •Server Certificate Chain gets large to send. •Renegotiation and Resumption is not optimized. LB Ballooning Extension TLS Ticket, Channel ID TLS False Start Need to upgrade TLS library on both end and middle box. It’s a long way, too.
  • 4. SPDY TCP HoL and TCP+TLS Handshake 5 4 3 1 missed 7 6 BLOCKED! TCP syn syn+ack ack ClientHello ServerHello Certificate Server Key Exchange Client Key Exchange Change Cipher Spec FInished Application Data TCP Handshake Change Cipher Spec Finished TLS Handshake SPDY SPDY SPDY SPDY SPDY SPDY
  • 5. QUIC(QuicUDP Internet Connections), MULTIPLEXED STREAM TRANSPORT OVER UDP= sophisticated TLS + TCP on UDP IP(IPv4/IPv6) UDP TCP TLS QUIC SPDY HTTP Encryption, Authentication Session Establishment, Flow Control Error Correction, Congestion Control
  • 6. http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf IETF-88 TSV Area Presentation By Jim Roskind
  • 7. HTTP on UPD. Really? http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf IETF-88 TSV Area Presentation By Jim Roskind •91-94% of users can make outbound UDPto Google. ambient 1% rest of 20% IPv6 50% 60sec
  • 8. QUIC History •2012 Oct: First Appeared in commit log •2013 Feb 25: First News in Tech Crunch. Known to the world. •2013 Jun. 27: Officially Announced in Chrome Blog(Experimenting with QUIC) Start serving QUIC on www.google.cometc. •2014 Aug. 29: Field Trial (Stable Channel: 0.2% desktop, 2% Android, Beta: 25% desktop, 50% Android) from net-devannouncement.
  • 9. QUIC Version History Date Version Date Version Topics 20131/18 QUIC1 20142/9 QUIC15 20137/26 QUIC7 20142/27 QUIC16 add STOP_WAITING 2013 8/9 QUIC8 2014 3/31 QUIC17 stream flow control (DATA) 2013 8/22 QUIC9 2014 4/28 QUIC18 add PING 2013 9/5 QUIC10 2014 5/17 QUIC19 connection flow control 2013 10/11 QUIC11 2014 6/20 QUIC20 2013 10/31 QUIC12 2014 7/2 QUIC21 Flow control(HEADERS, CRYPTO) 2013 12/20 QUIC13 2014 8/8 QUIC22 2014 2/6 QUIC14 2014 8/25 QUIC23 timestampin Ack, CONGESTION_FEEDBACK deprected AlmostMonthly VersionUP Q023 seems to be more stable than before
  • 10. QUIC on Chrome
  • 11. QUIC Wire Frame Format (Public Header) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 public flag (1) connection id (0,1,4,8) version(0,1) sequencenum(1,4,6,8) Encrypted Payload byAEAD (Chcha20+Poly1395 or AES128+GCM12) ConnectionID (a.k.aGUID) is a 64bit random value to identify client connection. Even after client’s ipor port was changed, QUIC can handle connection. public header is protected by AEAD Crypto Stream(stream=1) is not Encrypted but protected FNV1a-128 hash(using lower 96bit)
  • 12. QUIC Public Flag(8bit) - - - - - - - 0 NONE VERSION - - - - - - - 1 RST - - - - - - 1 - - - - - 0 0 - - - - - - 0 1 - - - - - - 1 0 - - - - - - 1 1 - - - - 0 0 - - - - - - 0 1 - - - - - - 1 0 - - - - - - 1 1 - - - - 0BYTE_CONNECTION_ID 1BYTE_CONNECTION_ID 4BYTE_CONNECTION_ID 8BYTE_CONNECTION_ID 1BYTE_SEQUENCE 2BYTE_SEQUENCE 4BYTE_SEQUENCE 6BYTE_SEQUENCE Use 8byteConnection ID by default unless negotiated. Sequence Number is fixed 64bit. but it can be sent only 1byte on the wire. Version field is no longer needed after negotiation.
  • 13. Why 64bit seqnumcan send via 8bit length on the wire? next epoch epoch prevepoch last_seq_no+ 1 seq_noon wire seq_noon wire seq_noon wire Candidate#1 Candidate#2 Candidate#3 the real seqno is the nearest of last_seq_no+1 sequence number length (255) 0 ～ ～2^64-1 •Less than 256 frames on the fly. But their arrival is not ordered. •Endpoint should remember the last_seq_nothat was received lately. •Choisethe nearest number to last_seq_no+1 from the epoch number + received 8bit number. •If we received very old frame, it can’t be decrypted because seqis used in IV.
  • 14. QUIC Wire Frame Format (Private) 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 public flag (1) connection id (0,1,4,8) version(0,1) sequencenum(1,4,6,8) private flag(1) FECoffset(0,1) frame_type(1) Frame Data Private Flag - - - - - - - 0 NONE ENTROPY - - - - - - - 1 FEC_GROUP - - - - - - 1 - - - - - - 1 - - FEC Random bit this frame is in FEC group FEC parity data is included
  • 15. Entropy hash to defense Optimistic Ack Attack 1byte entropy: entropy flag << seq number%8 1byte entropy hash = frame1_entropy XOR frame2_entropy XOR …. XOR frameN_entropy entropy hash is cleared when ACK is received ACK entropy_hash STOP_WAITING entropy_hash FRAME1 entropy_flag FRAME2 entropy_flag FRAME_N entropy_flag entropy_hash check ENTROPY - - - - - - - QUIC Private Flag 1bit entropy flag 0 or 1 Random entropy hashes are accumulated Entropy hash shows that this ACK is really replied by the server.
  • 16. FEC (Forward Error Collection) like a RAID in network packets (disabled on Chrome now) FEC Group FRAME_N fec_offset:n FRAME0 fec_offsest:0 FRAME FEC XOR Parity FRAME0～N FRAME1 fec_offsest:1 FRAME2 fec_offsest:2 FRAME_N fec_offset:n FRAME0 fec_offsest:0 FRAME FEC FRAME2 fec_offsest:2 FRAME1 fec_offsest:1 Missing! XOR FRAME_0 XOR FRAME_2～N XOR Parity FRAME0～N ＝ Hi, I’m revived! No need to resend a missing frame!
  • 17. QUIC FrameType 1 0 0 0 0 0 0 0 StreamMask AckMask CongestionFeedbackMask 0 1 0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0: PADDING 0 0 0 0 0 0 0 1 1: RST_STREAM 0 0 0 0 0 0 1 0 2: CONNECTION_CLOSE 0 0 0 0 0 0 1 1 3: GOAWAY 0 0 0 0 0 1 0 0 4: WINDOW_UPDATE 0 0 0 0 0 1 0 1 5: BLOCKED 0 0 0 0 0 1 1 0 6: STOP_WAITING 0 0 0 0 0 1 1 1 7: PING (deprecated in Q022)
  • 18. Frame Type (Stream) 1 - - - - - - - StreamMask - - - - - - - - stream_id_length - - - - - - - - offset_length - - - - - - - - has_data_length - - - - - - - - FIN 0x00-0x03 (length: 1～4) 0x00-0x07 (length: 0, 2～8) whether data_lengthis appended or not
  • 19. QuicStream 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 public flag (1) connection id (0,1,4,8) version(0,1) sequencenum(1,4,6,8) private flag(1) FECoffset(0,1) frame_type(0x80～) stream_id(1,2,3,4) offset(0, 2,3,4,5,6,7,8) data length(0, 2) StreamDATA
  • 20. Crypt Functionality in QUIC •Encryption both http:// and https:// •Server Cert Proof is made on https://
  • 21. QuicCrypto Stream (stream_id=1) public flag (1) connection id (0,1,4,8) version(0,1) sequencenum(1,4,6,8) private flag(1) FECoffset(0,1) frame_type(0x80～) stream_id= 0x01 offset(0, 2～8) data length(0, 2) FNV1a-128 hash truncated higher 32bit (12) snipped Message Tag(4) Number of Entries(2) Padding(2) Tag#1(4) end_offset#1(4) Tag#2(4) end_offset#2(4) Value#1 Value#2
  • 22. QuicTag List (some of 60 total) Crypto Tag Meaning CHLO Client Hello SHLO Server Hello SCFG Server Config REJ Reject CETV Client encrypted tag-value pairs PRST Public Reset SCUP Server ConfigUpdate P256 ECDHCurve P-256 C255 ECDH Curve25519 NULL null algorithm AESG AES128 + GCM-12 CC12 ChaCha20+ Poly1305 STK SourceAddress Token timestamp client ip Random Encrypted by Sever with AES128 + GCM-12 STK(56byte) Default Default Key Exchange AEAD
  • 23. Example CHLO CHLO PAD : (607 bytes of padding) SNI : 0x717569632D64656D6F2E69696A706C75732E6A70 STK : 0x95ACC8F704031697A396019034133971C0C65868BBBB32306B2929930C12FA0BF5889191CD1CAC1B7AE2B7FF17AF1C2F4880BC11 VER : 'Q023' CCS : 0x399FF95340F7FEC97B26E9E7E45C71FF NONC: 0x5452D757288EE7AC8D6709DD289D0C6BA0723C74960E2F4F30814F64C48F436A MSPC: 100 AEAD: 'AESG' UAID: canary Chrome/40.0.2205.0 SCID: 0x83F4EA5D3EFD8BC21B829BA2BFDF304E SWND: 20 ICSL: 30 KATO: 0 PUBS: 0x65F638326982B96A6B7251AEF0A61B568A6EE5D34FDD7B2E3C46D9453B809F36 KEXS: 'C255' COPT: CGST: 'QBIC' IRTT: 957 CFCW: 10485760 IFCW: 10485760 SFCW: 10485760 Server Name Indicator Source Address Token Version Nonce Common Certificate Set Max streams per connection AEAD algorithm User Agent ID Server ConfigID Server’s Initial Congestion Window Idle connection state lifetime Keep alive Timeout Public Key Key Exchange methods Connection Option Congestion Control Feedback Type Estimated initial RTT in use Initial session/connection flow control receive window Initial stream flow control receive window Initial flow control receive window
  • 24. 2-RTT (worst case) Client Server inchoate CHLO (VER, CCS, PDMD) REJ(STK, SNO, SCFG) inchoate CHLO(STK, SNO) REJ(STK, SNO, PROF, CRTx0ff) CHLO(STK, SNO, SCID) Encrypted Application Data Thank you, your Source Address Token is valid but no SCID. I give you my Certificate chain. I can’t trust your server cert with my chain. I send one more inchoate CHLO. I’m afraid you have no STK. I give you a Source Address Token and Server Config. It’s my first time so I send you an inchoate CHLO To avoid packet loss, I send 3 CHLOs at startup.
  • 25. 1-RTT (normal) Client Server CHLO (STK, VER, CCS, PDMD, SCID) REJ(STK, SNO, SCFG) CHLO(STK, SNO, SCID) Encrypted Application Data I’ve got a new STK and SCID. I send a full CHLO. You STK is expired. I give you a new Source Address Token and Server Config. It’s been a long time since I connected you.
  • 26. 0-RTT (repeated resumption) Client Server CHLO(STK, SNO, SCID) Encrypted Application Data I remember the server address token and sever config. It’s a repeated access in a short time. You have a right STK and SCID. So let’s begin to use the previous shared master secret.
  • 27. non Blocking during Cipher Secret Update Client Server Pleas Key Update! I don’t known when client update key. So I try decrypt frame with two (old and new) keys. SCUP(STK, SCFG{AEAD, SCID, OLD KEY PUBS, KEXS, OBIT, EXPY}) OLD KEY OLD KEY NEW KEY NEW KEY NEW KEY decrypter alternative decrypter
  • 28. Hashed Cert Chain and Compressed Server Cert CHLO(STK, …,CCS) CCS : 0x399FF95340F7FEC9 REJ(CRT, PROF) Client send FNV1a hash of local cert chain as CCS Server find missed Certs from CCS and send gzip compressed cert chain as CRT and signature as PROF Cert List + Hash Cached Cert List + Hash Cert List#1 + Hash Cert List#2 + Hash gzip compressed
  • 29. Transport Functionality
  • 30. ACK Frame 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 public flag (1) connection id (0,1,4,8) version(0,1) sequencenum(1,4,6,8) private flag(1) frame_type(0x40～0x7f) entropy hash(1) Largest Observed LargestObserved Delta Time(2) numof received packet(1) delta largest observed#1 time delta#1 delta largest observed#2 time delta#2 delta largest observed#3 time delta#3 numof missing packet(1) missing packet seq#1 range length#1 missing packet seq#2 range length#2 missing packet seq#3 rangelength#3 numof revivedpackets(1) revivedpacket seq#1 revivedpacket seq#2 revivedpacket seq#3 revivedpacket seq#4 ACK conveys Largest Observed Seq, Packet Timestamp, Missing Packets and Revived Packets
  • 31. ACK flag 0 1 - - - - - - AckMask 0 1 - - - - - - Missing SequenceNumberLength 00: 1byte length 01: 2byte length 10: 4byte length 11: 6byte length 0 1 - - - - - - Largest Observed SequenceNumberLength 0 1 - - - - - - IsTruncated 0 1 - - - - - - HasNack
  • 32. Retransmit a lost frame as a new stream STREAM_FRAME ACK(largest_observed: 11, missing: [10]) Lost id=9 id=10 id=11 id=13 retransmit as id=10 id=12 id=10 was lost. retransmit it as a new stream(id=13) Non-Blocked! Retransmitted as a new stream
  • 33. QuicStream and SPDY Binding CryptoStream stream_id= 1 HeadersStream stream_id= 3 SPDY SYN_REPLY SPDY SYN_STREAM DataStream stream_id= spdy’sstream_id SPDY DATA QUIC Priority(64bit) High Low Flow Controlled QUIC Priority(64bit) Middle
  • 34. Congestion Control •Default TCP Cubic + pacing with bandwidth estimation •Baseline: prevents Internet Congestion Collapse •Google shows the graph that pacing causes good performance •Maybe No time to present now. •Need more investigationfor me. http://www.ietf.org/proceedings/88/slides/slides-88-tsvarea-10.pdf IETF-88 TSV Area Presentation By Jim Roskind with pacing •no pacing •startup
  • 35. QUIC vs SPDY demo •https://www.youtube.com/watch?v=bP-8vfDX2ts
  • 36. QUIC vs SPDY demo #1 (1000ms RTT delay)
  • 37. QUIC vs SPDY demo #2 (30% packet loss) start at 1 min 30 sec
  • 38. Thanks