IETF 96: Google bringt sein Quic-Protokoll auf den Weg zum Internet-Standard

Die Internet Engineering Task Force wird auf der Basis von Googles Quic ein neues Transportprotokoll standardisieren. Das entschied eine breite Mehrheit von rund 360 Experten beim aktuellen Treffen der Standardisierungsorganisation in Berlin. Die Entwürfe von Google, das Quic im hauseigenen Desktop- und Mobil-Browser Chrome für viele eigene Dienste einsetzt, seien aber nicht sakrosankt, hieß es beim ersten Treffen der künftigen Mega-Arbeitsgruppe. Gegenwind kam unter anderem von Cisco-Vertretern, die Probleme für das Netzwerkmanagement durch Mittelboxen befürchten.

Mittelboxen

Mittelboxen sind Netzwerkgeräte, die Header und Nutzlastdaten von IP-Paketen auf dem Weg durchs Internet verändern. Netzbetreiber setzen sie beispielsweise für das unverzichtbare Verkehrsmanagement ein. Aber weil Mittelboxen unstandardisiert arbeiten, sind ihre Eingriffe vom Sender und Empfänger nicht vorhersehbar. Daher untergraben Mittelboxen das Konzept eines transparenten, protokoll- und anwendungsunabhängigen Ende-zu-Ende-Routing. Lesen Sie dazu auch:

• Middleboxen verkalken das Internet

Seit 2013 hat Google das neue Transportprotokoll in der Mache, seit 2014 läuft es auf Google Chromium. Aktuell implementiert das Unternehmen das Protokoll für die Android-Version der Youtube-App. Mit Quic strebt Google vor allem höheren Datendurchsatz bei automatischer Verschlüsselung im Zusammenspiel mit HTTP an. Auch Vertreter von Akamai und Microsoft unterstützen Quic, lobten die Möglichkeiten und verwiesen auf eigene Implementierungen. Ein Vertreter von Vodafone sprach davon, dass man Quic im Mobilfunknetz in 30 Ländern beobachtet habe. Demnach funktioniert Quic auch in Vodafones Mobilfunknetzen gut. Google bilanziert, dass 93 Prozent seiner Nutzer per Quic auf die Google-Dienste zugreifen. Ein Problem gibt es freilich, wenn UDP netzseitig blockt wird; UDP ist die Basis des Quic-Protokolls.

Erste Änderung

Auf der IETF kündigte sich bereits die erste substantielle Änderung an. TLS 1.3 soll die bislang eingesetzte Crypto-Technik von Google ersetzen. Googles eigene Verschlüsselung gehörte zu den Spezialitäten von Quic, da sie den Crypto-Handshake in den Verbindungsaufbau vorgezogen hat. Der schnelle Aufbau des Tunnels, bei dem schon im ersten Roundtrip Applikationsdaten mitgeschickt werden können, sorgt für die von Google, Akamai und anderen gewünschte Beschleunigung in der Startphase. Doch die Änderung ist logisch, denn der neue TLS-Standard war durch Quic inspiriert worden, unterstrich Martin Thomson von Mozilla. Thomson ist Koautor der in Berlin vorgelegten Quic-TLS Dokumente.

Laut Quic-Mitentwickler Jana Iyengar werden die Header voll authentifiziert – und damit besser gegen Spoofing geschützt – und zum großen Teil auch verschlüsselt. Gleichzeitig sei das Protokoll so modular aufgebaut, dass auch eine Weiterentwicklung im Kryptobereich aufgenommen werden könnte, also zum Beispiel ein kommendes TLS 1.4.

Viel Diskussion gab es zum Thema, wieviel Informationen der IP-Header für Mittelboxen zum Netzwerkmanagement oder für Firewalls enthalten soll. Falls die Quic-Pakete zu wenig Informationen über die beförderten Inhalte weitergeben, könnten sie von Mittelboxen und Firewalls blockiert werden. Für Anwendungen, die nicht auf TCP zurückschalten können, wäre das fatal. Doch viele Experten forderten, eher in Richtung Ende-zu-Ende zu entwickeln und kein Zugeständnis an die Mittelboxen zu machen. Eine Entscheidung werden erst weitere Treffen bringen. (dz)