IETF 103: Vom guten und bösen Verkehrsmanagement

Inhaltsverzeichnis

Das neue Transportprotokoll Quic bekommt das vor allem von Netzbetreibern geforderte Spin-Bit, um Laufzeiten zu ermitteln und dadurch Netzwerkprobleme zu detektieren. Bis zuletzt hatten sich zahlreiche Experten dagegen gestellt und die damit verbundenen Risiken für die Vertraulichkeit ins Feld geführt. Und Vertreter von Mozilla, Google und Facebook kündigten beim Treffen der Internet Engineering Task Force in Bangkok an, das Spin-Bit nicht implementieren zu wollen.

Die Kontroverse um das Spin-Bit hat der Einstieg in eine umfassende Verkehrsverschlüsselung ausgelöst. Das neue, auf Vorschlägen von Google basierende Transportprotokoll Quic verschlüsselt grundsätzlich per TLS, sodass nach dem Handshake kaum noch Metadaten über den Inhalt der Pakete ersichtlich sind. Das erschwert für Netzbetreiber das Quality of Service und überhaupt jegliches Verkehrsmanagement.

Laufzeitmessung weiter möglich

Mit dem Spin-Bit, das Server und Client jeweils drehen, haben sich die Netzbetreiber nun ein Merkmal gesichert, das wenigstens Laufzeitenmessungen ermöglicht. Jegliche weitere Signalisierung, die Informationen über Verlustraten oder Eigenschaften des Verkehrs offenlegt, hat die Arbeitsgruppe rundweg abgelehnt.

Außerdem beschloss sie einstimmig, dass das Spin-Bit freiwillig angewendet wird und dass der Client es auch ignorieren kann. Außerdem soll verhindert werden, dass Internet-Nutzer durch eine Opt-Out-Entscheidung Lauscher auf sich aufmerksam machen. Deshalb sollen Betreiber, die das Konzept nutzen, grundsätzlich einen Teil des Verkehrs ohne Spin übermitteln (Anonymity Set).

Eine Quic-Sitzung, mehrere IP-Adressen

Vorstellbar ist noch, dass Dritte, die den Verkehr eines Routers mitlesen können, die verbliebenen Metainformationen von Quic dazu nutzen, um den Client zu identifizieren. Bei herkömmlichen IP-Verbindungen ist das simpel, weil man die Quell-Adressen von Client-Anfragen einem DSL-Router oder einem Smartphone zuordnen kann (es sei denn, Techniken wie Tor sind im Spiel). Quic erschwert das deutlich, weil es so wie das Protokoll Multipath-TCP während einer einzigen IP-Sitzung mehr als eine IP-Adresse nutzen kann. So wie Multipath-TCP kann Quic eine Übertragung zum Beispiel von der Mobilfunkschnittstelle auf die WLAN-Schnittstelle umbetten.

Als Identifikationskrümel könnte man nun im Prinzip das Spin-Bit nutzen – also Verbindungen, die nie ein Spin-Bit senden mit solchen vergleichen, die das manchmal tun, um einzelne IP-Datenströme zu erkennen und so Hinweise auf den tatsächlichen Client zu sammeln. Ein zur Prüfung der Datenschutzfragen eingesetztes Team befand aber, dass das selbst dann nicht gelingen dürfte, wenn man Verkehr von mehreren Servern und zugehörige Laufzeiten von IP-Datenströmen zur Verfügung hat. Die wenigen Informationen, die Quic noch offen legt, seien zu grob für solche Zwecke.

Vom Spin-Bit zum Brems-Bit

Die größte Gefahr sehen die IETF-Teilnehmer darin, dass Provider, die das Spin-Bit verwenden wollen, den Verkehr von Kunden ohne Spin-Bit auf die Schleichspur setzen. Mozilllas neuer CTO, Eric Rescorla sagte: "Ich kann noch nicht erkennen, wie man das Spin-Bit so spezifizieren kann, dass die freie Entscheidung der Nutzer garantiert ist." Neben Rescorla kündigten deshalb auch Entwickler von Chrome, Fastly, Protocol Labs und andere an, das Spin-Bit nicht in ihre Produkte implementieren zu wollen. Microsoft, Apple, Broadcom und andere Unternehmen wollen es hingegen durchaus einsetzen.

Christian Huitema, Mitglied des Internet Architecture Board und einer derjenigen, die auf das "Anonymity Set" setzen, erinnerte daran: "Das Spin Bit ist ein Trade-Off zwischen Netzmanagement auf der einen und Datenschutz und Vertraulichkeit auf der anderen Seite. Ein besseres Netzwerkmanagement reduziert das Risiko von Attacken und erlaubt, sie besser zu detektieren." Dafür müssten die Nutzer ein kleines Stück der mit Quic möglichen Vertraulichkeit aufgeben. (dz)