Middleboxen verkalken das Internet

Inhaltsverzeichnis

Theoretisch sollte es sie gar nicht geben, faktisch sind sie eine Plage: Netzwerkgeräte, die Header und Nutzlastdaten von IP-Paketen auf dem Weg durchs Internet auf undurchschaubare Weise verändern und so jede Vorstellung von einem transparenten, protokoll- und anwendungsunabhängigen Ende-zu-Ende-Routing ad absurdum führen.

Unter Entwicklern sind sie bekannt wie berüchtigt. Größere Aufmerksamkeit fiel auf sie im Rahmen der Entwicklung des Multipath-TCP-Protokolls, mit dem sich zwei oder mehr Internet-Leitungen zu einer zusammenfassen lassen, um den Durchsatz zu erhöhen oder die Ausfallsicherheit zu verbessern. Ein ausführliches Interview zum MPTCP-Entwicklungsstand erschien auf heisenetze. Wie die Technik im Detail funktioniert, beschreibt ein Artikel in der aktuellen c't-Ausgabe 6/2014.

Wenn nun zwei Hosts mehr als eine Leitung ins Internet aufgebaut haben und diese trotz Multipath-TCP-Ausstattung nicht bündeln können, dann liegt das in aller Regel an einer oder mehreren Middleboxen auf der Strecke zwischen den beiden Hosts. Wo der Weg für MPTCP nicht durchlässig ist, müssen die beiden Gegenstellen also trotz mehrerer aktiver Internet-Anschlüsse auf eine einzige TCP-Verbindung zurückgreifen.

Gut gemeintes Traffic Engineering

Dass es Middleboxen überhaupt gibt, liegt daran, dass Netzbetreiber zunehmend mehr Geräte für ihr Traffic Engineering einsetzen, die Optionen entweder löschen oder auf unvorhersebare Weise ändern. Dazu gehören nicht nur die Network Address Translators (NATs), die globale IP-Adressen mehrfach auf lokale IP-Adressen abbilden und dazu die Portnummern in den TCP-Headern heranziehen; die Palette der Geräte umfasst Firewalls, Proxies, Intrusion Detection Systeme und Policy Manager, die mittels Deep Packet Inspection Netzbetreibern das Filtern unerwünschter Anwendungen ermöglichen.

Die IETF definiert im RFC 3234 diese Middlebox genannten Kisten als "any intermediary box performing functions apart from normal, standard functions of an IP router on the data path between a source host and destination host". Dazu gehören unter anderem, oft in Kombination:

Router: Router sind oft so konfiguriert, dass sie IP-Pakete verwerfen, die im Header ihnen unbekannte oder auch nur andere Transportprotokolle als TCP und UDP ausweisen oder die im Anschluss an den Header zusätzliche Optionen enthalten.

NATs: Network Address (and Port) Translators; sie wurden ursprünglich eingeführt, um der Knappheit an IPv4-Adressen zu begegnen. Sie setzen die lokalen IP-Adressen eines privaten Subnetzes auf eine öffentliche IP-Adresse um und verbergen so die intern verwendeten Adressen hinter der öffentlich sichtbaren.

ALGs: Application-Level Gateways sind ein spezieller NAT-Typ, der sogar Nutzlastdaten verändern kann – beispielsweise durch das Einfügen von Steuerungsbefehlen, damit auch FTP durch ein NAT hindurch funktioniert.

PEPs: Performance-Enhancing Proxies spalten zur Leistungssteigerung eine TCP-Verbindung in zwei auf – mit sich selbst als zwischengeschaltetem Host. An der Schnittstelle zu einem schnellen und zuverlässigen Netz können sie selbst ACKs anstelle des Empfängers senden und so den sendenden Server von Timeouts entlasten, die der eigentlich adressierte Host in einem langsamen und möglicherweise unzuverlässigen Anschlussnetz verursachen könnte.

IDS/Firewalls: Intrusion Detection Systems und Firewalls sollen unerwünschte Zugriffe auf das Netz aufdecken und unterbinden. Sie interpretieren Unregelmäßigkeiten wie beispielsweise Abweichungen von der fortlaufenden TCP-Sequenznummerierung häufig als Eindringversuch und sperren die Verbindung.

TSO/LRO: TCP Segmentation Offload und Large Receive Offload sind Techniken, die im Zusammenspiel von CPU und Netzwerkkarte TCP-Segmente aufspalten oder zusammenlegen, um den Datendurchsatz zu erhöhen.

Wie man Middleboxen aufspüren kann

Die vielen Middleboxen im Netz "optimieren heutige Anwendungen zu Lasten der künftigen", beklagen die MPTCP-Architekten in RFC 6182 diese "Verkalkung" des Internet. Ihretwegen müssten sich "künftige Anwendungen in einer ähnlichen Weise verhalten wie die existierenden, um die Chancen zur erfolgreichen Einführung zu vergrößern. Zudem ist das genaue Verhalten all dieser Middleboxen nicht klar spezifiziert und Fehler bei der Implementierung machen alles noch schlimmer, sodass sich die Hürden für die Einführung neuer Techniken erhöhen".

Aus den Arbeiten zu Multipath-TCP ist mit tracebox ein neues Werkzeug hervorgegangen, das es gestattet, die Wirkungsweise der Middleboxen präziser zu analysieren. Tracebox ist ein traceroute-Vetter, der aber nicht nur zwischengeschaltete Router auf dem Weg zu einem bestimmten Zielhost auflistet, sondern auch den Inhalt der auf die Echo Requests á la traceroute zurückgesandten Echo-Reply-Pakete des Internet Control Message Protocol (ICMP) auswertet.

Laut RFC 792 enthalten diese Pakete den IP-Header und die ersten 64 Bit der Nutzlast des ursprünglichen Echo Requests. Und wenn es sich bei der IP-Nutzlast um ein TCP-Segment handelt, entsprechen die ersten 64 Bit dem Quell- und Zielport sowie der TCP-Sequenznummer im Header. Der Vergleich des ursprünglichen Pakets mit dem in der ICMP-Antwort zitierten lässt dann Rückschlüsse auf Middlebox-Aktivitäten auf dem Pfad zu; durch sukzessives Steigern der Zahl der Hops beziehungsweise Time-To-Live in den Echo Requests lassen sich sogar einigermaßen genau lokalisieren.

Tracebox ist für Linux ausgelegt, der Quellcode ist auf Github veröffentlicht. Auf Mac OS X kann man das Tool über den Paketmanager Homebrew einrichten. Ein Beispiel sieht so aus:

tracebox -p IP/TCP/MSS/MPCAPABLE/WSCALE bahn.de

Je nachdem, ob eine Middlebox im Weg steht oder nicht, und ob sie TCP-Optionen verfrickelt oder nicht, liefert das Tool unterschiedliche Ausgaben. Die Autoren haben in einem Beispiel die Strecke von der belgischen Universität Löwen zum Web-Server der Deutschen Bahn untersucht und dabei eine Middlebox aufgespürt, die die MSS-Option verändert (Maximum Segment Size) und die Optionen MP_CAPABLE und WSCALE gleich ganz entfernt (diesen Elementen sind in der Tracebox-Ausgabe Minus-Zeichen vorangestellt). Ein Host könnte auf dieser Strecke also zum Webserver der Bahn nur herkömmliche TCP-Verbindungen aufbauen, also keine Leitungen bündeln.

Auf anderen Strecken und bei anderen Zielen kann das Ergebnis aber ganz anders aussehen. Beispielsweise verläuft eine gängige Strecke aus dem heise-Netz zum Bahn-Server über ganz andere Hops und dabei steht nicht die Middlebox der Bahn im Weg – dafür freilich eine hauseigene, die die Option MPJOIN entfernt.

In der Tabelle unten sind die Optionen aufgeführt, die bei MPTCP-Verbindungen übertragen werden. Das Tracebox-Tool akzeptiert zum Test derzeit nur die beiden ersten, also MPCAPABLE und MPJOIN.

Multipath-TCP-Optionen
Wert	Optionstyp	Funktion
0x0	MP_CAPABLE	signalisiert dem Empfänger die Multipath-Fähigkeit
0x1	MP_JOIN	fügt der bestehenden Verbindung einen weiteren TCP-Teilfluss hinzu
0x2	DSS	Data Sequence Signal, enthält die DATA_ACK und die Zuordnung von DSN zu SSN
0x3	ADD_ADDR	signalisiert der Gegenstelle eine weitere verfügbare Adresse
0x4	REMOVE_ADDR	entfernt einen Pfad (Addresse) aus der Multipath-Verbindung
0x5	MP_PRIO	mit MP_PRIO signalisiert ein Host bei der Initialisierung eines neuen Pfads, ob dieser regulär oder als Backup genutzt werden soll
0x6	MP_FAIL	signalisiert Kommunikationsstörungen in einem Subflow (z. B. Prüfsummenfehler), sodass Hosts etwa den problematischen Pfad entfernen oder zum Einzelpfad-TCP zurückkehren können
0x7	MP_FASTCLOSE	Analogon des Reset Signals (RST) für TCP für Multipath-Verbindungen, signalisiert der Gegenstelle, dass die Verbindung sofort abgebrochen wird und keine Daten mehr angenommen werden

(dz)