IETF: Netzwerker wollen Quic-Pakete tracken

Eigentlich kommt die Standardisierung des Quic-Protokolls gut voran. Doch Netzwerker und um Privatsphäre besorgte Entwickler streiten sich schon jetzt heftig darüber, ob und wie Quic-Pakete verfolgt werden können. Und das hat wohl auch sehr große Auswirkungen auf das gesamte Internet.

Ein Bericht von Sebastian Grüner veröffentlicht am 21. Juli 2017, 15:56 Uhr

Ohne Gegenmaßnahmen für Quic verstopfen die Netzwerke, befürchten einige Betreiber. (Bild: Robert, flickr.com/CC-BY 2.0)

Die erste Sitzung der Quic-Arbeitsgruppe auf dem IETF Meeting 99, das derzeit in Prag stattfindet, startet mit Erfolgsmeldungen aus dem Hackathon, der am Wochenende vor dem Meeting stattgefunden hat. Dass diese Erfolge auf der Sitzung von nur einem Thema verdrängt werden und viele andere neue Vorschläge für Quic vorerst nicht mehr diskutiert werden können, zeigte sich im Grunde aber schon beim Streit um die "statischen Schlüssel" für TLS 1.3.

Erste echte Datenübertragungen

Zunächst zu den Erfolgen: Auf dem Hackathon haben es die Beteiligten geschafft, mit unterschiedlichen Implementierungen, die sich an den vorliegenden Entwurf halten, eine Interoperabilität zu erreichen. So sind Handshakes erfolgreich durchgeführt und auch schon einige Daten in einem sehr geringen Umfang unter speziellen Bedingungen ausgetauscht worden.

Laut Mark Nottingham, dem Co-Vorsitzenden dieser sowie der HTTP-Arbeitsgruppe, ist dieser laufende Code ein "wichtiger Meilenstein" sowie ein "vielversprechender Start". Er hoffe außerdem, so Nottingham, dass die Leute jetzt begreifen, dass das von der IETF standardisierte Quic Wirklichkeit werde.

Das Vertrauen der Entwickler in den Erfolg von Quic ist sogar schon so weit gediehen, dass diese kurz diskutieren, ob und unter welchen Umständen das sogenannte Wire-Format bereits eingefroren werden soll. Dies wird aber unter anderem auch deshalb vorerst verworfen, weil Google sehr negative Erfahrungen mit seiner eigenen Quic-Version habe.

Verschiedene Middleboxen, also Rechner und Geräte auf den Transportwegen zwischen Client und Server, benutzen inzwischen einige spezifische Bytes, um Quic-Pakete erkennen zu können. Google habe deshalb aber das Problem, sein Format nicht mehr ändern zu können. Bei dem IETF-Quic, das auf der Grundlage von Googles Ideen und Erkenntnissen entsteht, soll dies wohl aber so lange wie möglich hinausgezögert werden.

Diskussion um Roundtrip-Messungen

Dass darüber hinaus aber nur noch ein weiteres Thema von der Tagesordnung besprochen werden würde, hat der zweite Co-Vorsitzende der Quic-Arbeitsgruppe, Lars Eggert, vermutlich schon geahnt. Unmittelbar vor der Quic-Sitzung sagte er im Treffen des Security-Arbeitsbereichs der IETF, dass er die Diskussionen um die statischen Schlüssel bei TLS 1.3 mit "großem Interesse" verfolgt habe.

Vermutlich war für Eggert schon abzusehen, dass ein Vorschlag für Quic ähnlich heftige und beherzte Diskussionen auslösen würde und derartige Streits auch langfristig Teil des Prozesses der Standardisierung von Quic sein würden. Im konkreten Fall ist erläutert worden, dass Netzwerkbetreiber zur Qualitätsverbesserung und für das Trafficmanagement die Paketumlaufzeit (Round Trip Time) bestimmen.

Anders als bei TCP ist bei dem auf UDP basierenden Quic aber fast der gesamte Traffic absichtlich verschlüsselt. Das betrifft insbesondere auch die ACKs, weshalb das Bestimmen der RTT bei Quic durch die Netzwerkbetreiber nicht mehr trivial möglich ist. Der Google-Angestellte Ian Swett stellte deshalb mögliche Lösungen für das Problem vor (PDF).

Die Diskussion dieser Lösungen sorgte allerdings für eine ähnlich klare Spaltung in zwei Fraktionen, wie dies bereits bei TLS der Fall gewesen ist.