Wer den Schlüssel hat, hat die Macht

Jana Iyengar ist einer der Hauptautoren des kommenden Internetprotokolls QUIC (Quick UDP Internet Connections). Der gerade von Google zum Cloud-Anbieter Fastly gewechselte „Distinguished Engineer“ stand anlässlich der 101. IETF-Tagung in London Rede und Antwort zum Status der QUIC-Entwicklung.

c’t: Was zeichnet QUIC aus, warum ist es besser als das bisher im Internet übliche Transportprotokoll TCP?

Jana Iyengar: Es gibt mehrere Gründe. Natürlich zunächst die bessere Performance. TCP könnte man zwar auch dahingehend trimmen, aber dafür sind Änderungen an den Betriebssystemen von Netzelementen wie Routern erforderlich. QUIC wird in Anwendungen implementiert und kann sich schneller ausbreiten.

Zudem verschlüsselt QUIC per Design, sodass sich zum Beispiel Header nicht willkürlich ändern lassen, wie es Mittelboxen stillschweigend bei TCP tun. Mit TCP gibt es ja, anders als vorgesehen, tatsächlich keine Punkt-zu-Punkt-Kommunikation zwischen zwei Internet-Hosts mehr. QUIC nutzt hingegen UDP als Transportprotokoll und wird daher durchgewunken. So kommt QUIC auf kürzere Laufzeiten und bessere Leistung.

c’t: Manchmal wird QUIC schon als „das nächste TCP“ bezeichnet. Wird es tatsächlich TCP ablösen?

Jana Iyengar: (lacht). Ich weiß nicht – ich hoffe, dass es ein wichtiges Transportprotokoll wird. Aber TCP bleibt erhalten und das sollte es auch. Der Wert des TCP liegt darin, dass es sehr simpel ist. Und bestimmte Anwendungen brauchen genau das. Gleichzeitig wird es auch fortentwickelt. Auch bei TCP haben wir an einem schnelleren Handshake und einer besseren Loss Recovery gearbeitet.

c’t: Wie viel IP-Verkehr läuft aktuell über QUIC?

Jana Iyengar: Bei Googles eigenem Verkehr sind es über 40 Prozent. Weltweit sind es laut neueren Schätzungen 9 bis 10 Prozent. Der Anteil hängt davon ab, wo im Netz man misst. Die 10 Prozent weltweit ergeben sich aus Googles Anteil am gesamten Internetverkehr. Der beträgt zurzeit rund 20 Prozent.

c’t: Und wie viel Nicht-Google-Verkehr läuft über QUIC?

Jana Iyengar: Das ist vernachlässigbar und liegt daran, dass es bislang nur die Google-Implementierung im Livebetrieb gibt, und das wiederum liegt auch daran, dass die Spezifikation noch in Arbeit ist.

c’t: Ist QUIC, das bei Google entstanden ist, für große Content-Anbieter optimiert? Und wird TCP dann das Protokoll des kleinen Mannes?

Jana Iyengar: Ich hoffe, dass wir niemals so eine Klassifizierung machen. QUIC ist neu, aber nicht das erste seiner Art. Nehmen wir das Stream Control Transport Protocol. Wenn man heute einen Anruf macht, nutzt man SCTP. Als generelles Transportprotokoll scheiterte es aber an den Mittelboxen und weil es nicht in Betriebssysteme implementiert wurde. QUIC hat aus den Erfahrungen seiner Vorläufer gelernt. Ja, Google hat QUIC ursprünglich gestartet. Aber es ist auch das Kind einer längeren Ideengeschichte.

c’t: Und ist es optimiert für Google?

Jana Iyengar: Natürlich haben sich die Entwickler bei Google von den Anforderungen der eigenen Dienste leiten lassen. Die Standardisierung bei der IETF dient aber dazu, QUIC auch für andere Ansprüche abzustimmen. Es soll ein Protokoll für jedermann werden. Die Implementierung ist aber aufwendig und kann daher ein Ausschlusskriterium sein. Dennoch gibt es schon eine Reihe von Open-Source-Implementierungen, darunter Quicly, Quic-Go und natürlich Mozilla und Chromium. Wir hoffen, dass am Ende nicht nur Google und Facebook QUIC implementieren.

Außerdem haben wir mit QUIC eine Reduzierung der Video-Buffer-Zeiten von etwa 13 bis 18 Prozent gemessen. Als Effekt eines einzigen Protokolls ist das beträchtlich. Bemerkenswert ist, dass davon am meisten Regionen mit hohen Latenzen und Verlustraten profitieren, beispielsweise Indien. Den Qualitätsgewinn dort haben wir mit über 22 Prozent gemessen. Das heißt, die Nutzer, die über schlechte Netze angebunden sind, profitieren mehr. Oft sind das Netze von Entwicklungsländern.

c’t: Das gilt aber nur für Google-Inhalte?

Jana Iyengar: Ja, aktuell nur für Google-Inhalte. Akamai nutzt QUIC allerdings auch.

c’t: Wird Version 1 des QUIC-Protokolls wie geplant im November fertig?

Jana Iyengar: Es ist ein ambitioniertes Ziel. Aber wir werden hart dafür arbeiten und es ist gut, dass wir die Deadline haben.

c’t: Also wird es ein 2019er Baby?

Jana Iyengar: Das wäre wunderbar. Ich hoffe, dass 2019 der RFC veröffentlicht wird. Die letzten harten Nüsse knacken wir hoffentlich bis zum IETF-Treffen in Montreal im Juli.

c’t: Welche sind das?

Jana Iyengar: Das ist der Handshake. Da gibt es noch Probleme.

c’t: Das Thema Spinbit, also das Bit, das im offenen Teil des Headers einen Anker für die Messung von Laufzeiten bieten soll: Ist das zunächst vom Tisch?

Jana Iyengar: Nein. Der Konsens war, dass man den Spinbit-Vorschlag voll ausarbeitet und im November entscheidet, ob man ihn haben will.

c’t: Sie haben sich entschieden dagegen ausgesprochen. Wegen der möglichen Verzögerung, wegen möglicher Einbußen an Vertraulichkeit oder wegen anderer Gründe?

Jana Iyengar: Als Autor vor allem wegen Ersterem. Es ist heikel, etwas einzubauen, was noch nicht voll ausgearbeitet ist. Leute, die meinen, das sei ein ganz einfacher Mechanismus, verkennen, welche Konsequenzen sich für das Protokoll ergeben können. Ja, das ganze QUIC ist ein Experiment, aber das Spinbit ist anders. Sein ureigener Zweck ist, dass es die Mittelboxen nutzt. Und es ist nicht in der Praxis getestet.

In Bezug auf die Vertraulichkeit macht man stets eine Gratwanderung. Meine persönliche Meinung ist: Wir wissen nicht genau, was das Spinbit am Ende preisgibt. Wir haben lang und hart abgewogen, wie viel wir preisgeben wollen bei QUIC. Ein Design-Team hat das Spinbit auf Privacy-Einschränkungen hin untersucht und hat zwar nichts Kritisches gefunden, aber man weiß nicht, was da eventuell doch lauert. Vor allem aber fehlt mir eine Begründung der Netzbetreiber, was ihnen das Spinbit bringt. Die sind uns das bisher schuldig geblieben. Natürlich beziehen sie aus TCP mehr Daten und natürlich fehlt das in QUIC. Aber das Ziel sollte nicht sein, mehr Features durchzudrücken. Vielmehr sollte man festlegen, was zwingend notwendig ist, um das Netz zu betreiben.

c’t: Die TLS-Spezifikation 1.3 ist gerade dieser Tage fertig geworden (siehe dazu auch S. 29, Anm. d. Red). Erwartet die QUIC-Arbeitsgruppe einen ähnlicher Streit darüber, ob IP-Verkehr für die Betreiber aus Sicherheitsgründen einsehbar bleiben muss?

Jana Iyengar: Das kann sein. Allerdings sprechen wir bei QUIC von einer geringeren Eingriffstiefe. Bei TLS geht es um die Inspektion des Paketinhalts. Wenn wir danach gefragt werden, schicken wir die Leute in die TLS-Arbeitsgruppe zurück. Die hat das gerade abgelehnt.

c’t: Weil TLS in QUIC integriert ist …

Jana Iyengar: Ja. Wenn sie zu uns kommen, dann wegen der Metadaten.

Wir haben bei der IETF-Konferenz in London den Streit um solche Zugriffsrechte gesehen. Ich verstehe, es ist ein schwieriges Problem für die Netzbetreiber. Sie kommen von TCP und haben dessen Freizügigkeit mit Metadaten jahrelang genutzt. Doch Freizügigkeit war nicht Ziel des ursprünglichen Protokolldesigns. Und Kryptografie war nicht so wichtig, als TCP entwickelt wurde. Heute leben wir in einer anderen Welt. Und wir erleben einen Machtkampf. Man verleiht dem Macht, dem man im Protokolldesign den Schlüssel überlässt, und nimmt dem Macht weg, dem man ihn vorenthält. Wer den Schlüssel hat, hat die Macht. (dz@ct.de)