Schnelle Schiene

von Benjamin Pfister

Rund 40 Jahre nach dem ersten RFC für TCP stellte die IETF 2021 mit QUIC – kurz für Quick UDP Internet Connections – den potenziellen Nachfolger vor. Das UDP-basierte Protokoll bringt eine zwingende TLS-Verschlüsselung, bricht mit dem klassischen OSI-Schichtenmodell und verspricht eine höhere Geschwindigkeit. Da nun die ersten Implementierungen erfolgen, werfen wir einen näheren Blick auf das Protokoll, dessen Aufbau und mögliche Einsatzgebiete.

Ursprünglich entstand QUIC (Quick UDP Internet Connections) [1] 2012 als Google-Projekt unter Führung von Jim Roskind, um die Sicherheit und Performance im Vergleich zu TCP zu erhöhen. Das Protokoll erreichte nach gut fünf Jahren Entwicklungszeit bei der Internet Engineering Task Force (IETF) 2021 den Sprung hin zu vier Requests for Comments (RFCs) [2, 3, 4, 5] unter den Nummern 8999 bis 9002. An der Weiterentwicklung des Transportprotokolls beteiligten sich in der IETF neben Google unter anderem Entwickler von Fastly und Mozilla.

Dass QUIC jedoch nicht nur akademischen Wert hat, zeigt sich an den ersten bereits darauf aufbauenden Applikationsprotokollen. So nutzt die dritte Version des Hypertext Transport Protocols (HTTP/3) bereits QUIC. Aber auch erste Entwürfe zum SIP-Nachfolger RIPT für VoIP-Netze bauen auf QUIC auf. Beides dürfte die Verbreitung in naher Zukunft schnell steigern.

Spezifika und Einsatzbereiche

QUIC gilt als potenzieller TCP-Nachfolger, jedoch fällt insbesondere Netzwerkern die Anerkennung schwer. Dies begründet sich in der Zusammenführung der OSI-Schichten 4 (Transportschicht) und 5 (Sitzungsschicht), was mit alten Paradigmen bricht. QUIC baut grundsätzlich auf dem eigentlich verbindungslosen User Datagram Protocol (UDP) auf und verwendet dessen Port 443. QUIC selbst hat jedoch eine verbindungsorientierte Architektur. Das Protokoll soll in Version 1 einen Wechsel des Kommunikationspfads während einer laufenden Session ermöglichen, was in mobilen Szenarien interessant sein könnte. Die Sicherstellung der Vertraulichkeit, Integrität und Verfügbarkeit soll eine obligatorische TLS-1.3-Verschlüsselung sicherstellen. Dies entspricht dem Security-by-Default-Ansatz. Zusätzlich soll damit ein Eingriff aktiver Netzwerkkomponenten im Netzwerkpfad auf Basis von TCP-Header oder Content-Informationen vermieden werden.

Zudem wurde im Gegensatz zum Multilayer-Session-Aufbau bei klassischer Kommunikation in Form eines TCP- und TLS-Handshakes Letzterer direkt in den QUIC-Handshake integriert. Dies soll geringere Latenzen im Verbindungsaufbau und folglich eine verbesserte Nutzererfahrung bringen. Gerade Cloudservices und Webseiten, die auf eine Vielzahl von Content-Quellen zurückgreifen, führen zu einer multiplen, sequenziellen Abarbeitung der Handshake-Prozesse, wodurch es in Folge zu erhöhter Latenz des Verbindungsaufbaus kommt. Dies möchte QUIC besser machen. Gerade bei WAN-Anbindungen, die per se eine höhere Latenz aufweisen, stellt dies eine zunehmende Herausforderung dar.

Auch Paketverluste und Stausituationen des Flows innerhalb der Kommunikationsbeziehung kann das Protokoll in seiner aktuellen Version erkennen. In Ergänzung verhindert es auch "Head of Line Blocking", also Situationen, in denen die Übertragung eines Pakets andere ausbremst. TCP-Sockets bauen auf Quell-IP/Port- und Ziel-IP/Port-Kombination auf. Jedoch kommt es insbesondere bei mobiler Nutzung in vielen Fällen zu einem IP-Change. So zum Beispiel bei einem Wechsel vom Enterprise-Netz hin zu öffentlichen Mobilfunknetzen, wenn die Mitarbeiter das Unternehmensgebäude verlassen.

Besonders interessant für mobile Endgeräte ist die im Gegensatz zu TCP nun mögliche Veränderung der Verbindungsparameter IP-Adresse und Port. Bei Wechsel von verkabelten in drahtlose Netze kann so erreicht werden, dass keine neue Session aufgebaut werden muss. Falls ein NAT zur Anwendung kommt, kann es bei längerer Zeit ohne aktive Übertragung zu Timeouts und folglich zu einer Port-Anpassung kommen. Um die Effizienz der Kommunikationsbeziehung zu erhöhen, bietet QUIC auch ein Multiplexing multipler Flows. So hatten die Entwickler das Ziel, all diese Verbesserungen ohne Anpassung an bestehende Netzwerke zu ermöglichen.

Aufbau des Protokolls

Das verbindungslose UDP liefert die Basis des QUIC-Protokolls. Der Datenaustausch von Applikationen findet über eine QUIC-Connection in Form von Streams statt, die sowohl unidirektional als auch bidirektional sein können. Eine solche Verbindung bietet die Möglichkeit mehrerer Streams. Eine Kommunikationsbeziehung wird über einen sogenannten Connection Identifier von IP-Adressen und Ports abstrahiert, um eine Entkopplung dieser volatilen Informationen zu ermöglichen. Der Wechsel darf jedoch aktuell nur vom Client aus erfolgen. Trotz Änderung der IP- oder Portinformation stellt der Identifier also sicher, dass die Daten am richtigen Endpunkt eintreffen und eine eindeutige Zuordnung möglich ist.

Die Festlegung des Connection Identifiers findet jeweils auf Client und Server statt. Der Gegenpart der Kommunikationsbeziehung muss die zu übertragenden Daten an den von der Gegenseite festgelegten Connection Identifier senden. Sollte keine Notwendigkeit zur Differenzierung zwischen unterschiedlichen Connections auf einem Endpunkt bestehen, gibt es auch eine Möglichkeit: "zero-length connection IDs". Diese dürfen natürlich nicht in Kombination mit Connection-Multiplexing auf der gleichen IP-Adresse/Port-Kombination zum Einsatz kommen.

Wie kommt jedoch der Sender von Daten an die jeweilige initiale Connection-ID, die der potenzielle Empfänger vergeben hat? Im Handshake gibt es hierzu im Long Packet Header ein Source-Connection-ID-Feld. Hat der Empfänger dem Sender diese Information im Handshake mitgeteilt, kann in rückwärtiger Richtung eine Adressierung mit dem korrekten Destination Connection Identifier erfolgen. Falls neben den initial im Handshake übermittelten IDs noch zusätzliche Connection-IDs notwendig sind, lassen sich diese über "NEW_CONNECTION_ ID"-Frames ankündigen.

Die zuvor angesprochene Handshake-Phase bildet auch den Ausgangspunkt einer QUIC-Connection. Client und Server handeln darin neben den Connection-IDs auch einen Shared Secret auf Basis von TLS 1.3 sowie das auf QUIC aufbauende Applikationsprotokoll aus. Neben dem klassischen Verbindungsaufbau über Handshakes bietet QUIC bei Vorliegen bestehender Verbindungsinformationen einer alten Connec-tion für Clients auch die Möglichkeit, vor einem Erhalt von Daten eines Servers Daten an diesen zu versenden – also eine Wiederaufnahme der Kommunikationsbeziehung. Dieses Leistungsmerkmal nennt sich "Zero Round-Trip-Time" (0-RTT) und ist optional und nicht zwingend anzubieten. Das Problem dabei ist der fehlende Schutz vor Replay-Attacken.

Headeraufbau verstehen

QUIC arbeitet mit über Short und Long Headern. Bis die sogenannten One-Round-Trip-Time-(1-RTT)-Schlüssel ausgetauscht sind, kommen die etwas ineffizienteren Long Header zum Einsatz, erst anschließend die Short Header. Wie im Wireshark-Mitschnitt in Bild 1 ersichtlich, verfügt der QUIC Header in den Connection-Informationen über ein Header-Form-Feld.

Der Wert "0" steht für einen Short Header, der Wert "1" für einen Long Header. Zusätzlich enthalten diese einen Fixed-Bit und einen Packet-Typ, wobei das Fixed-Bit angibt, ob es sich um eine Versionsaushandlung oder ein reguläres Paket handelt. Der Packet-Typ erklärt sich von selbst und verfügt in der Long Form über insgesamt vier Pakettypen: Initial, Handshake, Retry und 0-RTT Protected. Um eine korrekte Interpretation des Headers zu ermöglichen, gibt es auch ein Versionsfeld, das in der aktuellen Fassung auf "1" beziehungsweise "0x00000001" steht. Zusätzlich erkennen wir die zuvor bereits benannten Source- und Destination-Connection-IDs und zugehörigen Längenangaben. Dahinter folgt die eigentliche QUIC-Payload.

Um zu erklären, wie die Versionsaushandlung vonstattengeht, müssen wir RFC 8999 heranziehen. Im Gegensatz zu anderen Vorgängen sind bei der Versionsaushandlung Vertraulichkeit und Integrität noch nicht sicherstellbar. Bei Empfang eines Long Headers mit einer unbekannten oder unsupporteten Versionsnummer sendet der Empfänger im Versionsfeld "0x00000000" zurück. Zusätzlich fügt er im "Supported Version"-Feld eine Liste mit unterstützten Versionen ein.

Nachdem Schlüssel und Version ausgehandelt sind, kommen in der 1-RTT-Phase Short Header zur Anwendung. Daher auch der eindeutige Pakettypname 1-RTT. Da in der Handshake-Phase in den Long Headern bereits die Connection-IDs und Versionen bekanntgegeben beziehungsweise ausgehandelt wurden, enthält der Short Header keine Source-Connection-ID-Informationen, keine Längeninformationen zur Destination-Connection-ID und auch kein Versionsfeld. Dies macht den Handshake effizienter. Zusätzlich kommt dieser jedoch mit einem Spin-Bit-Header-Feld daher, was dem passiven Latenzmonitoring im Kommunikationspfad dient. Dabei reflektiert der Server den empfangenen Spin-Wert nur, wohingegen der Client diesen wieder von "1" nach"0" beziehungsweise umgekehrt dreht. So lässt sich anhand dieser Drehung die Ende-zu-Ende-Round-Trip-Time annähernd ermitteln.

Abbau einer Verbindung

Jede aufgebaute Connection bedarf auch einer späteren Beendigung. Dies kann auf unterschiedliche Arten geschehen. Bei einem Verstoß gegen Protokollfestlegungen kommt ein "Immediate Close" zum Einsatz. Sendet ein Endpunkt einen solchen, wird – wie der Name bereits andeutet –, die Verbindung sofort beendet. Ein "Stateless Reset" kann bei Verbindungsproblemen Verwendung finden. Konkretes Beispiel für ein Verbindungsproblem wäre ein Empfänger, der von einem ehemaligen Sender Pakete an eine nicht mehr vorhandene Destination-Connection-ID erhält.

Neben den genannten Varianten gibt es auch noch einen Idle-Timeout. Fügt ein Endpunkt einen "max_idle_timeout" in den Transportparametern ein, muss also eine Auffrischung stattfinden. Dies findet aufgrund eines erfolgreich empfangenen und verarbeiteten Pakets statt.

Sicherheitsmaßnahmen in QUIC

Einer der wichtigsten Sicherheitsaspekte von QUIC stellt die obligatorische TLS-1.3-Verschlüsselung dar. Diese beinhaltet automatisch auch die Forward Secrecy, die eine nachträgliche Entschlüsselung ausschließt. Der zugehörige TLS-Handshake findet direkt im QUIC-Handshake statt. Die Serverauthentifizierung ist wie auch in anderen TLS-Versionen obligatorisch, wohingegen die Clientauthentifizierung einen optionalen Parameter darstellt. Bei jeder Verbindung kommen eindeutige Schlüssel zum Einsatz, wobei das zugehörige Schlüsselmaterial sowohl in 0-RTT- als auch in 1-RTT-Paketen Verwendung findet.

Eine Herausforderung bei UDP-basierenden Protokollen stellen jedoch sogenannte Amplification-Attacken dar. Dies bedeutet, dass eine relativ kleine Anfrage eine große Antwort erzeugt. Durch ein Quelladress-Spoofing kann so ein Angriff auf ein Drittsystem stattfinden. Daher legten die Protokollentwickler großen Wert auf die Adressvalidierung, um das Risiko von Spoofing-Angriffen abzumildern. Diese Adressvalidierung kommt sowohl beim Aufbau als auch bei einer Migration der Verbindung zum Tragen. Hat der Empfänger noch keine Adressvalidierung durchgeführt, ist die maximale Größe des Antwortpakets auf die dreifache Größe der zuvor empfangenen Anfrage beschränkt. Außerdem bedarf es eines Payloads mit mindestens 1200 Byte im initialen Paket. Es ist also bei Bedarf aufzufüllen.

Ein Token-Austausch vor rechenintensiven Operationen soll serverseitige Denial-of-Service-Attacken vermeiden. Handshake-Keys ermöglichen nach den Initial-Paketen einen Schutz vor Handshake-Termination-Attacken. Aber auch gegen Optimistic-ACK-Attacken, also die Bestätigung des Erhalts noch nicht erhaltener Pakete, wurden Maßnahmen ergriffen. Zudem geben die Entwickler Empfehlungen gegen Request-Forgery-Attacken.

Erste Implementierungen

Dass der potenzielle TCP-Nachfolger nicht nur eine Protokolldefinition ohne praktischen Nutzen darstellt, unterstreichen bereits zahlreiche Implementierungen. So bauen neben dem bereits zuvor genannten HTTP/3 noch weitere Protokolle darauf auf. Darunter unter anderem das in "Windows Server 2022 Datacenter: Azure Edition" offiziell veröffentlichte SMB-over-QUIC. Bei diesem Protokoll erfolgt eine Kapselung des Server-Message-Block-Protokolls zur Dateiübertragung innerhalb von QUIC, um dessen Vorteile nutzen zu können.

Die integrierte TLS-1.3-Verschlüsselung soll den Zugriff von extern in "Mobile-Worker-Szenarien" und von intern bei hohen Sicherheitsanforderungen besonders interessant machen. Gerade für das mobile Szenario bietet sich auch die Eigenschaft einer möglichen Änderung der IP-Adresse oder des Ports des Clients an, wenn beispielsweise ein Wechsel zwischen Hotspot und mobilen Datennetzen erfolgt. Für den Endanwender geschieht dies bei Microsoft transparent. Der Hersteller aus Redmond möchte damit Public-Cloud-basierte Dateisystem-Zugriffe bei einem hohen Sicherheitslevel und gewohntem Nutzungserlebnis wie bei lokalen SMB-Fileservern ohne dediziertes VPN ermöglichen.

Aber auch im umstrittenen Umfeld der DNS-Verschlüsselung gibt es einen QUIC-Ansatz: DNS-over-QUIC könnte als Alternative zu DNS-over-TLS (DoT) und DNS-over-HTTPS (DoH) interessant werden, weil es die Handshake-Zeiten verkürzt und so zu einem besseren Nutzererlebnis durch höhere Performance führt. In den aktuellen Varianten von Chrome und Mozilla Firefox ist QUIC bereits integriert und aktiviert.

Ein weiteres interessantes Anwendungsfeld für QUIC stellt der Bereich der IP-Telefonie dar. Seit 2020 gibt es die ersten Entwürfe für ein Protokoll namens "Realtime Internet Peering for Telephony" (RIPT), das als potenzieller Nachfolger des Signalisierungsprotokolls SIP gehandelt wird. SIP kommt in vielen Fällen noch immer unverschlüsselt zum Einsatz. Problematisch dabei ist, dass die TLS-verschlüsselte Variante immer auf TCP aufbaut und somit eine höhere Latenz im initialen Verbindungsaufbau mit sich bringt, was Anwender beispielsweise beim Rufaufbau bemerken.

Für einen Überblick der Implementierungen empfiehlt sich ein Blick auf GitHub [6]. Dort sind einige Implementierungen mit den jeweilig zugrunde liegenden Programmiersprachen und meist auch den unterstützten Zielplattformen, supporteten QUIC-Versionen sowie der unterstützten Rolle, also Client und/oder Server, dargestellt. Dort stehen seit der Veröffentlichung von Version 1 bereits einige Lösungen bereit – konkret beispielsweise MsQuic (Bibliothek in C für Windows, Linux und macOS), Neqo (Mozilla/Firefox QUIC und HTTP3-Implementierung in Rust), Aioquic (Python-Bibliothek), lsquic (LiteSpeed QUIC und HTTP/3-Bibliothek in C für Linux, FreeBSD, macOS, Android und Windows) und quant (QUIC Userspace Accelerated Network Transfers in C).

Wo es noch hakt

Bei allen Vorteilen von QUIC gibt es jedoch auch noch einige Herausforderungen. So bleibt beispielsweise abzuwarten, wie gut ausgehende Verbindungen über den UDP-Port 443 laufen. Insbesondere in Kombination mit dem darauf aufbauenden HTTP/3 stellt sich beispielsweise die Frage, inwiefern es in Hotspots oder Unternehmensnetzen zu gedroppten Verbindungen an Firewalls oder statuslosen Paketfiltern (ACLs) kommt.

Aber auch Intrusion-Prevention-Systeme und Proxies könnten beim Einsatz von QUIC ein Problem darstellen. So muss der Support für QUIC auch erst in diese Produkte Einzug halten. Ein Fallback auf HTTP/2 oder sogar HTTP/1.1 und folglich auf TCP/443 kommt sicherlich in einigen Fällen zur Anwendung. Die Pandemie hat uns in Kombination mit diversen Securivty-Produkten und den teilweise proprietären Protokollen von Videokonferenzsoftware-Produkten gelehrt, dass UDP-basierte Protokolle in Next-Generation- Firewalls vielfältige Sicherheitsüberprüfungen durchlaufen. Aber auch Rate-Limitings von UDP-Connections können eine Herausforderung darstellen. So können beispielsweise UDP Flood Protections bei Massenübertragungen über UDP einen negativen Einfluss haben.

Auch sei erwähnt, dass es außer in einer Entwicklerversion für NGINX (Stand Januar 2022) noch kein QUIC-Feature für Apache-Webserver gibt. Durch das Zusammenspiel von Transport- und Ses-sion-Layer ist das Protokoll ingesamt auch recht komplex. Inwiefern sich die Überlastungssteuerung von QUIC in lokalen Datennetzen mit hohen Bandbreiten auswirkt, bleibt abzuwarten. Fluch und Segen zugleich ist die Implementierung von QUIC im Userspace. So braucht es bei neuen Protokollversionen clientseitig kein Kernelupdate, sondern nur eines der Applikation.

Fazit

QUIC dürfte seine Stärken insbesondere bei Zugriffen auf Cloudapplikationen und Webseiten ausspielen, bei denen der Content verteilt auf unterschiedlichen Zielservern liegt. Auch Kommunikationsbeziehungen mit hoher Latenz können durch den integrierten TLS-Handshake und das 0-RTT-Feature profitieren. Zudem sind im Umfeld latenzkritischer Kommunikation wie VoIP oder sequentieller Datenbankzugriffe interessante Einsatzszenarien denkbar. Beim Remote Access per VPN könnte sich ein weiteres Anwendungsfeld auftun. Dort greifen einige Hersteller derzeit noch auf das UDP-basierte DTLS, TLS oder das IPSec-Framework zurück. Durch die obligatorische Verschlüsselung mit TLS 1.3 bietet QUIC hier eine echte Alternative.

Nachteilig ist jedoch die im Vergleich zu TCP und TLS höhere CPU-Last einzuschätzen. Es steht aber noch in den Sternen, wie viele Hersteller und Open-Source-Projekte tatsächlich auf QUIC umsatteln und inwiefern die UDP-Kommunikation in aktuellen Netzen freie Fahrt genießt.