QUIC

• connection establishement latency

• improved congestion control algorithm

• multiplexing without head of line blocking

• forward error correctoin

• connection migration

• combines featuers from multiple layers of the OSI model

• -> cuts down overhead…

• not implemented in kernel

• -> has to be supported by application itself

  
  

• does not rely on OS updates for QUIC updates itself…

• requires a kernel-based transport protocol to work on top of

• -> uses UDP

• UDP unreliability

  • -> QUIC takes care of it

  • implements congestion control that is stream based rather than packet based

  • => allows to mitigate HoL blocking (compared to TCP)

• UDP no handshake

  • -> QUIC has own handshake and merges TLS v1.3 handshake into it

  • reduces connection time

• Connection migration is possible

  • -> QUIC connection not (unlike TCP) based on IP and Port

  • -> client and host maintian connectoin ID…

• no can be several…

• each QUIC packet can have several frames as payload…

• always encrypted -> mandatory (no nosec mode…)

• -> each packet payload is fully encrypted

• only exception:

  • version negotiation

  • retry packet

  • => contain no payload and also no protected header fields

• long header packets

• short header packets

• only send before establishment of connection

• -> then switchted to short header to save header overhead

• version negotiation packet

• intitial packet

• 0-RTT packet

• handshake packet

• retry packet

• header form (first bit in header)

• -> if set : long header; else short header

• header form

• fixed bit

• long packet type

• type specific bits

• version

• destination Connection ID length

• Destination connection ID

• source connectoin ID length

• source connectoin ID

• always set in thie QUIC version

• -> unless it is version negotiation packet

• -> or else packet invalid and discarded

• 0x0 -> initial

• 0x1 -> 0-RTT

• 0x2 -> Handshake

• 0x3 -> Retry

• reserved for the different packet types

• reserved bits

• packet number length

• length

• packet number

• packet payload

• two first most significant bytes must be 0 after dectyption

• -> else considerred invalid…

• response only sent by hosts

• -> if client tris to establish connection to host not supporting its QUIC version

• -> uses this packet to respond

• -> host transmits its supported versions as list of 32 bit identifiers

• -> iside the supported versions field

• -> client than can try to reestablish connectoin with suported QUIC version

• must be independant of QUIC implementaitons

• -> requires to be recognizable by all QUIC users…

• has no specific assigned type number

• destionation connection ID and source connection ID can be longer than the specified 120 bit

• -> so that future QUIC versions are not limited by this constraint…

• carries initial handshake for client and host

• to exchange their keys

• => also servers as response to initial packet as it carries ACKS in either direction

• token length field

• token field

• “early” data from the client

• -> can be rejected or accepted by host prior to handshake completion

• sent back and forth between client and host

• exchange acknowledgements and cryptographic handshake messages

• after the initial handshake packet

• sent by host when conneciton establishement failed

• by initial or 0-RTT oacket from client

• contains to type specific flags

• BUT contain fields

  • retry token

  • retry interity tag

• added by client for use in initial packets

• ping

• padding

• crypto

• ack

• 1-RTT header

• header form

• fixed bit

• spin bit

• reserved bits

• key phase

• packet number length

• destionation connection ID

• packet number

• packet payload

• same as long header

• -> but contrary to long header, flag not set…

• optional feature of QUIC

• -> allows PASSIVE latency monitoring over course of connection

• 200

• fields that can be ommited:

  • version

  • destination connectin ID length

  • source Connection ID length

  • source connection ID

• added fields.

  • packet number field

• no

• -> can vary in their length

  
  

• merging allows ommiting second exchange in handshake

-> : client server

<- : server client

-> TCP SYN

<- TCP SYN + ACK

-> TCP ACK

-> TLS Client Hello

<- TLS Server Hello

-> TLS Finished

<-> application layer

-> QUIC clietn hello

<- QUIC server hello

-> QUIC FIN

<-> Application Layer

=> saves full RTT compared to TCP/TLS…

• 0-RTT handshake

• => built upon previously exchanged keys

• => directly transmit encrypted data with key from previous connection….

• forward secrecy not provided until new keys are exchanged…

• -> data sent during 0-RTT can be captured by on-path attackers

• browsing same websit with many calls for new pages

• where each call creates new connection

• => 0-RTT featuer kicks in…

=> contrary: downloadign

• establishing connection faster

• but not necesarry transfer…

• 1, 2, 3 RTT

• -> QUIC either 0 or 1 (0-RTT or regular…)

• TCP + TLS either 1,2 or 3

• 1-RTT:

  • TCP + TLS with 0-RTT -> 1 RTT

• 2-RTT

  • TCP + TLS

• 3-RTT:

  • TCP + TLS < 1.3

• one single resource prevents other resources from making progress

• TCP independent of Applicatoin Layer

• -> usually multiple resources transmitted at once using TCP

• -> if one packet is lost…

• -> all following packets are held back

• -> until lost is re-transmitted

• -> succeeding resources being held back unnecessarily (as lost packet might be from other resource…)

• => TCP unaware of upper layer resources…

• implements multiple streams on a single transport layer connection

• => one stream per resource

• QUIC makes use of so called STREAM frames

• if STREAM frame is missing -> single STREAM frame re-requested instead of whole packet…

• -> re-transmission of this strean will not hinder other streams…

• HTTP pipelining

• out of order delivery of packets

• large sequentially sent resources

• input buffered network switches

• lost packets on transport layer

• reserves TCP connection until each request and response pair is finished

• => packet dedicated to resource…

• -> then rest of resouce in next packet and part of new resource…

• -> browser not aware of resource size

• -> large resources could block whole connection, even if smaller resources are more important

• modern browsers open multiple TCP connections for HTTP/1.1 to combat this albeit resulting in TCP handshake overhead

• introduces applicatoin layer streams

• each resource sent as its own stream

• Thus, each TCP packet can conatin multiple parts of a resource at once and longer / shorter resources can be loaded concurrently

• !!! but if packet lost -> blocks rest of the resouces in subsequent packets that do not belong to the ones in the lost one…

• some features offered by HTTP/2 are already offered by QUIC itself

• based on entirely different transport protocol

• not all previous HTTP/2 features can be mapped to be used with QUIC

• woud not have made sense to semd same data as for HTTP/2

  • -> because HTTP stream headers would lead to “double header”

• HTTP/1.1 -> application layer

• HTTP/2 -> transport layer

• IP and Port independent

  • makes use of connectoin IDs… (instead of IP-5 tuple)

• allow change of interface on the fly while keeping connection alive over different netwok paths

• can be used if interface / IP changes…

• -> server transmits path challenge

  • frame with random payload

• -> client transmits path response

  • with same payload

• => QUIC knows path is valud anc client cna receive sent data…

• can also be used after some inactivity to see wether path is still valid…

• if path challenge not answered (correctly)

• -> might close connectoin

• except there is other valid path for the connection…

• to counter address spooffing when connection migration is initialized

• -> client to host

• -> if answered, client knows it can reach host with new path…

• host on other hand uses path validation to ensure return reachabliity with new address

  
  

• path validation in both ways

• non-probing communication is received from client by server

• => regular communicatoin can continue…

• NAT rebinding

• changing used ports

• moving from one network interface to another

• changing the used IP address

Anonymity by proxys or similar can not be achieved on the fly.

• In QUIC, connection establishment latency is reduced by using a connection ID and a source address token.

• Vulnerable to resource exploitation

• Congestion control may be too restrictive, e.g. wireless networks

• Changing IP Address with changed network e.g. roaming

• Growing amount of mobile devices

• Slow connection establishment

• Encryption is not required

• Cookie security

• Head-of-line Blocking

1. Decrease handshake delay

2. Get rid of head-of-line blocking

3. Faster development cycles

4. Middlebox resistance

5. IP mobility

• substitute for the TCP/TLS protocol stack, based on UDP

• Initially developed by Google, deployed in Google Chrome and Chromium

• Originally Quick UDP Internet Connections, but not an acronym

• Applcation:

  • HTTP/2 and TLS

  • vs

  • HTTP/3 and QUIC

• Transport:

  • TCP

  • vs

  • QUIC and UDP

• network

  • both IP

-> inchoate CHLO

<- REJ

-> Complete CHLO

-> Encrypted Request

<- Server Hello

<- Encrypted Response

-> complete CHLO

-> encrypted request

<- SHLO

<- encrypted response

-> complete CHLO

-> encrypted request

<- REJ

-> complete CHLO

-> encryped request

<- SHLO

<- encrypted response

• DH values

• certificate chain

• signature

• token

• …

• authenticated key exchagne

  • server always authenticated (e.g. cert)

  • client optionally authenticated

• authenticated exchange of values for transport parameters

• negotiating connection ids

• TCP higher slope for increasing minimum RTTs than QUIC

• QUIC 1-RTT higher than 0-RTT and 1-RTT combined

• faster deployment

• middleboxes

• -> lots of manufacturers, obscure behavior, …

• -> simply use UDP, headdrs above not accessible to middleboxes…

  
  

• TCP connections are identified by the 5-tuple

• Client IP address may change during the connection

• DSL connection gets re-established after 24h

• Mobile clients move from one network to another

• NAT entry might expire -> port changes

• Do not use the 5-tuple as connection identifier

• QUIC identifies connections by a Connection ID

• Last client IP address to send a valid packet for a given Connection ID is client’s current IP address

• no, several

• not all compatible with each other

examples:

• aioquic (python)

• lsquic (c)

• gqquic (go)

• UDP datagram with Ports and Cheksum {

  • QUIC Pakcet 1 with Connectoin ID and Packet Number {

    • QUIC Frame 1 with Type

    • …

    • QUIC Frame n with Type

  • }

  • …

  • QUIC Pakcet n with Connectoin ID and Packet Number {

    • QUIC Frame 1 with Type

    • …

    • QUIC Frame n with Type

  • }

• }

• multiple QUIC packets in a UDP datagram possible

• connection id -> get connection

• packet number -> decrypt payload

• integer in range 0 to 2^(62-1)

• Used in determining a cryptographic nonce for packet protection

• Different packet number spaces for initial packets, handshake packets, and application packets

• Start at packet number 0 and must be increased by at least 1 for subsequent packets

• minimal overhead

• used after connection is established

• id lengths

• version

  
  

• first crypto frames and acsk

• sent by cleint and server to perform key exchange

• used to carrry “early” data from clietn to server as part of first flight

• -> prior to handshake completion

• e.g. HTTP request

• with short header once 1-RTT keys are available

• ensures that smaller integer values require fewer bytes to encode

• -> used in e.g. Stream IDs

• two most significant bits of first byte encode log2 of integer encoding length

• -> e.g. 00 -> 1 -> 6 usable bits

• -> 01 -> 2 -> 14 usable bits

• …

• -> 11 -> 8 -> 62 usable bits

1. Minimizing connection establishment and overall transport latency for applications, starting with HTTP/2

2. Providing multiplexing without head-of-line blocking

3. Requiring only changes to path endpoints to enable deployment

4. Enabling multipath and forward error correction extensions

5. Providing always-secure transport, using TLS 1.3 by default

• confidentiality

  • only encrypted data transfer

• authenticaion

  • server is authenticated

  • clietn optinoally

• integrity

  • use MACs

• authenticated encryption with assocaited data

• -> encrypt and compute MAC simultaneously

• C = f(k,N,A,P)

• P = f(k,N,A;C)

with

• Plaintext P, ciphertext C, associated data A, nonce N, key k

• Compute packet nonce

  • IV xor packet number

• compute C = AEAD(key, nonce, associated data (header), payload)

  • => result in protected payload

• add header protection

  • encrypt certain 128bit of ciphertext C with hp key

  • mask so that only some header fields are protected (e.g. packet number)

  • xor with original header

  • => result in protected header

• remove header protection

  • reverse masking wiht xor enc(hp, C)

• compute packet nonce

• compute P = AEAD(key, N, associated data, C)

• client sends used verion in long header

• if verion not supported

  • server replies with version negotiation packet listing all supported versions (own version field set to 0x00000000

• client can pick a supported version

• 32 bit unsigned number

• 0x00000000 reserved for version negotiation

e.g.

• 0x5130xxxx -> Google

• 0xfaceb00x -> facebook

• 0xabcd000x -> Microsoft

• lightweight, orderd byte stream abstraction

• bidirectional or unidirectional

• Stream frames can open, carry data for, or close a stream

• Unique stream ID (62-bit integer), two bits used to identify initiator and if bi- or unidirectional

• Multiple streams are sent interleaved, streams can be prioritized (avoidance of head-of-line blocking)

• Packet numbers are acknowledged, after all frames have been processed

• Tries to send ACK frames as often as possible to improve loss and congestion response

• Trade-off between load generation and short response times

• ACK frame contains multiple ACK ranges

• qlog

• qvis

• can differ widely

• -> due to different developers / languages

qlog:

• Based on JSON

• (timestamp, event type, event specific data)

qvis:

• Browser interface to visualize qlog files

• Different diagram types: sequence diagram, congestion diagram, . . .

  • sequence diagram

  • congestion diagram

  • multiplexing diagram

  • packetization diagram

• DDoS-Attack

• QUIC-Reflector Attack

• Higher CPU costs than TCP/TLS

• Possible throughput depends heavily on the application resources

• UDP still far less optimized than TCP

  
  

• can identify connections

• compared to IP-5 tuple, allows for changes in IP and Port

• -> Mobility…

• Multiple streams within a connection

• Each stream provides a reliable bidirectional bytestream

• QUIC packet contains several frames

• QUIC packet can carry stream frames from multiple streams

• control frames

• data and acknowledgemetn frames

• stream flow control

• connection flow control

• retransmssions have different packet number

• -> use stream offset for in order delivery (offset field in stream frame…)

• selective and negative ACK

• -> more elaborate than TCP

-> initial[0]: Crypto[Client Hello]

<- initial[0]: crypto[server hello] ACK[0]

<- Handshake[0]: crypto[Encrypted Extensions, Cert, Certificate Verify, Fin]

<- 1-RTT[0]: STREAM[1,…]

-> Initial[1]: ACK[0]

Handshake[0]: CRYPTO[FIN], ACK[0]

1-RTT[0]: STREAM[0,…], ACK[0]

client hello:

• supported ciphers

• TLS versions

• signature hash algos

• key share for key exchagne

server hello:

• chosen cipher suite

• value for key exchange

• supported TLS version

• crypt. signature over previous handshake message

• -> allows client to

  • 1) verify that server actually has the private key from the cert

  • 2) previous messages have not been tempered with

• mark completion of crypt. handshake

• contains MAC over all previous handshake messages

• -> confirm mutually that handshake completet successfully and both sides have aggreed on crypt. parameters for connection

• is in unencrypted part of header

• -> gets reflected by server

• -> client initializw with 0

• -> inverts the received ones from the server as soon as response arrive…

=> thus, flips every RTT…

=> allows on -path observer (e.g. middlebox) to estimate RTT

• ???

• in 1-RTT packets

• loss

  • -> higher loss decreases transmission rate of CUBIC

  • -> it is loss based, and thus if loss occurs often, it constantly reduces transmission rate and never goes very high up again

  • -> BBR delay based so more robiust to it

• Delay

  • BBR better suited to high delay than CUBIC

• has threshold for when to use BBR or CUBIC

• initially uses BBR until RTT is estimated

• -> low latency -> use CUBIC

• -> performs better …

• yes

• -> consider you have a connection using regular TCP (CUBIC) and the other QUIC (BBR)

• -> one will starve especially when downloading stuff

advantage:

• user space more flexible in terms of introducing new features

• compared to kernel, where lots of testing, and stability is required

disadvantage:

• higher CPU overhead due to syscalls required…

• new connection id

  • during handshake -> add list of valid connection ids that can be used in case of migration

• path challenge

• path response

• retire connection id

  • 
    

    
    

• using new connection id for connection after migration

• two options:

• 1. old connection still exitst

• 2. old connection no longer exists

no longer exists:

• send non-probing packet, initializing connection migratoin

• path validation is perforemd

• get new address validation tokens

exists:

• path validation performed

• get new address validatoin tokens

• send non probing packet to migrate connection

• random strings generated by server and included in initial QUIC pacekts

• on subsequent connections, client sends them back to server

• -> server is able to verify that same client from initial ….

• mobile end users

• -> connection migratoin

• -> high latency (BBR good in this case)

• -> wireless usually high loss (BBR good)

• attacker establishes connection with server -> gets address validation token

• -> releases its used IP address

• -> later time, attacker can initiate 0-RTT connection with server by spoofing same address it had before

• -> IP might belong to different victim endpoint

• -> can cause server to send initial congestion window worth of data towards victim (flooding it if done in large scale, DDoS…) vs small 0-RTT packet…

• or: transmit initial client hello with spoofed IP

• limit address validatoin tokens to certain lifetime…

• -> requires new address validatoin

• initial client hello has minimum size requiring attacker to considerably use bandwidth

• but still larger, so this is still possible