Zusammenfassung

  • Eine legitime Heimatadresse kann im besuchten Netz als unpassende Quelle erscheinen. Der Rückwärtstunnel setzt für den Weg zwischen den Agenten eine topologisch passende äußere Adresse ein.
  • Die innere Adresse bleibt Teil der ursprünglichen Kommunikation. Bei überlappenden privaten Adressräumen muss der vermittelnde Agent zusätzlich wissen, zu welchem Heimatagenten und welchem lokalen Teilnehmer sie gehört.
  • Registrierung, Zustellverfahren und sichere Zuordnung begrenzen den Dienst. Weder eine passende Adresse noch ein erfolgreicher Registrierungsbescheid garantiert die Zustellung oder authentifiziert jeden Dateninhalt.

Eine Adresse reicht nicht als Zuordnung

Der Anhang von RFC 3024 behandelt eine Situation, die in einfachen Tunnelzeichnungen leicht verschwindet: Mobile Teilnehmer aus unterschiedlichen Heimatnetzen können gleiche private Adressen verwenden. Wenn beide am selben fremden Netz hängen, sagt die innere Adresse allein nicht mehr, zu welchem Teilnehmer ein Paket gehört.

Der äußere Tunnel liefert weiteren Zusammenhang, etwa den Heimatagenten und die Care-of-Adresse. Für die lokale Übergabe braucht der fremde Agent aber auch eine verlässliche Verbindung zum richtigen Teilnehmer auf der Sicherungsschicht. Die Sicherheitsbetrachtung verlangt für diese Anordnung eine sichere Identifikation auf dieser Ebene und empfiehlt kein gemeinsam genutztes Ethernet ohne Authentifizierung.

Das ist keine universelle Lösung für beliebig überlappende Netze. Die beteiligten Agenten müssen sich im äußeren Adressraum erreichen können, und die inneren Adressen müssen in den jeweils betroffenen Bereichen sinnvoll sein. Der Anhang erweitert einen begrenzten Anwendungsfall; er hebt die Bedeutung von Adressräumen nicht auf.

Warum sollte ein Paket überhaupt erst zum Heimatnetz zurückkehren? Die Antwort liegt in einem anderen Kontextwechsel: Eine Adresse kann als dauerhafter Kommunikationsendpunkt richtig und als Quelle an einem bestimmten Netzeingang falsch sein.

Das ursprüngliche Versprechen der Mobilität

RFC 2002 beschrieb im Oktober 1996 IPv4-Mobilität zwischen Subnetzen. Der mobile Knoten behält seine Heimatadresse. Ein Heimatagent leitet eingehende Pakete zu einer Care-of-Adresse weiter, die den aktuellen Ankunftspunkt angibt. Der Kommunikationspartner muss deshalb nicht bei jedem Ortswechsel eine völlig andere Endpunktadresse verwenden.

Eine Care-of-Adresse kann einem fremden Agenten gehören, der mehrere mobile Knoten versorgt. Er beendet dann den Tunnel und übernimmt die lokale Zustellung. Alternativ kann der mobile Knoten selbst eine eigene Care-of-Adresse erhalten und den Tunnel beenden. Die beiden Betriebsarten sind zu unterscheiden: Im Agentenmodell braucht nicht jeder Besucher eine exklusive lokale IPv4-Adresse.

Für eingehende Pakete war der Umweg über den Heimatagenten bereits Teil des Modells. Ausgehende Pakete mussten ihn dagegen nicht zwingend nehmen. Der Entwurf ging davon aus, dass Router nach dem Ziel und nicht nach der Quelle entscheiden. Der mobile Knoten konnte seine Heimatadresse als Quelle behalten und vom Besuchsnetz aus zum Kommunikationspartner senden.

Ein Netzbetreiber kann allerdings noch eine andere Frage stellen, bevor er ein Paket weiterleitet: Passt diese Quelle überhaupt zu der Verbindung, über die das Paket eintrifft?

Der Filter prüft den Ort, nicht das Eigentum

RFC 2827, im Mai 2000 als BCP 38 veröffentlicht, empfahl die Beschränkung zulässiger Quellpräfixe an Eingängen aus nachgelagerten Netzen. Damit lässt sich der Raum für gefälschte Quelladressen verkleinern. Eine Route zum Ziel allein ist dann kein ausreichender Grund, jede Quelle zu akzeptieren.

Die Heimatadresse des mobilen Knotens kann echt sein und trotzdem außerhalb der Präfixe liegen, die am Anschluss des Besuchsnetzes erwartet werden. Der Filter muss dem Teilnehmer keinen Adressdiebstahl unterstellen. Er erkennt eine topologisch unpassende Quelle.

RFC 2827 nennt die Schwierigkeit für Mobile IP ausdrücklich und verweist auf den Rückwärtstunnel. Es geht also nicht darum, Mobilität gegen jede Kontrolle auszuspielen. Eine stabile innere Adresse und eine für den aktuellen Ausgang geeignete äußere Adresse können unterschiedliche Aufgaben übernehmen.

Auch die Aussagekraft des Filters bleibt begrenzt. Wer eine andere Adresse innerhalb eines erlaubten Präfixes vortäuscht, wird durch die Präfixprüfung allein nicht identifiziert. Topologische Plausibilität ist keine vollständige Teilnehmerauthentifizierung. Diese Unterscheidung kehrt am anderen Ende des Tunnels wieder.

Die äußere Adresse erledigt eine andere Arbeit

Der Rückwärtstunnel wurde in RFC 2344 vom Mai 1998 definiert und im Januar 2001 durch RFC 3024 überarbeitet. Rückwärts bezeichnet die Richtung im Verhältnis zum üblichen Tunnel vom Heimatagenten zum mobilen Knoten. Nun können auch die ausgehenden Daten zunächst zum Heimatagenten gelangen und von dort zum eigentlichen Partner weiterlaufen.

Die dafür verwendete Trennung erklärt RFC 2003: Das innere IP-Paket enthält die ursprünglichen Kommunikationsendpunkte, der zusätzliche äußere Header die Endpunkte des Tunnelabschnitts. Auf dem Weg vom fremden Agenten zum Heimatagenten steht außen die Care-of-Adresse als Quelle. Innen bleibt die Heimatadresse des mobilen Knotens erhalten.

Das Besuchsnetz sieht auf diesem Abschnitt also eine Quelle, die zum Ausgangsort passt. Die innere Identität wird nicht durch eine andere Endpunktadresse ersetzt. Stattdessen beschreiben zwei Header zwei verschiedene Beziehungen.

Dabei darf die Verpackungsmetapher nicht zu viel versprechen. Kapselung verschlüsselt den Inhalt nicht. Auch bleiben nicht zwangsläufig sämtliche inneren Bits unverändert, weil beim Weiterleiten beispielsweise der TTL-Wert beeinflusst wird. Entsprechende Tunnelendpunkte in beiden Richtungen bedeuten außerdem nicht, dass die Pakete über identische physische Wege laufen.

Wer zuerst kapselt, entscheidet mit

RFC 3024 unterscheidet zwei Übergabeverfahren. Bei der direkten Übergabe nutzt der mobile Knoten den fremden Agenten als Standardrouter und sendet ein zunächst ungekapseltes Paket. Der Agent übernimmt die Kapselung zum Heimatagenten. Das unterstützt Unicast, bietet aber keine selektive Wahl des Rückwärtstunnels.

Bei der gekapselten Übergabe richtet der mobile Knoten zunächst einen eigenen äußeren Header an den fremden Agenten. Dieser entfernt die erste Kapselung und legt die für den Heimatagenten bestimmte zweite an. Auf dem ersten, lokalen Abschnitt bleibt die äußere Quelle die Heimatadresse des mobilen Knotens. Erst auf dem zweiten Abschnitt wird die Care-of-Adresse des fremden Agenten zur äußeren Quelle.

Diese Reihenfolge ist wichtig. Der mobile Knoten verwendet nicht einfach die Adresse des fremden Agenten als seine eigene. Die beiden äußeren Header entstehen bei unterschiedlichen Absendern für unterschiedliche Empfänger.

Mit dem gekapselten Verfahren kann der Knoten auswählen. Nach entsprechender Registrierung dürfen seine ungekapselten Pakete nicht ebenfalls in den Rückwärtstunnel gesteckt werden. Sie werden normal weitergeleitet. So kann beispielsweise der Versuch, einen lokal erreichbaren Drucker anzusprechen, im Besuchsnetz bleiben, soweit dessen Routing und Zugriffsregeln das zulassen.

Der fremde Agent darf diese Entscheidung nicht durch pauschales Rücksenden aufheben. Gekapselte Übergabe ist zudem für Broadcast und Multicast über den Rückwärtstunnel mit fremdem Agenten erforderlich. Die Verfahren unterscheiden sich deshalb in ihrem Dienstumfang, nicht nur im Aufwand für einen zusätzlichen Header.

Eine ausgehandelte Beziehung mit engen Grenzen

Ein T-Bit in der Agentenankündigung bietet den Rückwärtstunnel an. Das T-Bit im Registrierungsantrag verlangt ihn. Beides ist von der Annahme des konkreten Antrags zu unterscheiden. Und selbst dessen Annahme belegt noch keinen funktionierenden Datenweg zum Kommunikationspartner.

Die gekapselte Übergabe wird mit einer Erweiterung vom Typ 130 und der Länge null angefordert. Fehlt sie, ist direkte Übergabe gemeint. Bei nicht gesetztem T darf diese Erweiterung nicht enthalten sein. Ihre Position zwischen Authentifizierungserweiterungen ist festgelegt; der fremde Agent verarbeitet sie und gibt sie nicht unverändert an den Heimatagenten weiter.

Auch die Anforderungen an die Agenten änderten sich. RFC 2344 verlangte beide Verfahren von einem Agenten, der Rückwärtstunnel anbot. RFC 3024 machte die direkte Übergabe weiterhin verpflichtend, die gekapselte dagegen zur Empfehlung. Der Fehlercode 79 kann fehlende Unterstützung für das verlangte Übergabeverfahren ausdrücken.

Das aktuelle Mobile-IP-Register von IANA bestätigt diese Zuordnung. Eine ältere Bemerkung innerhalb von RFC 3024 nennt 79 noch unzugewiesen. Die Zuweisungssektion und der Änderungsanhang desselben Dokuments enthalten jedoch bereits die Vergabe. Die isolierte Bemerkung ist daher kein belastbarer Beleg für den heutigen Registerstand.

Die Zuordnung muss zur inneren und äußeren Quelle passen

Ein Heimatagent soll nicht jedes Paket weiterreichen, das er technisch entkapseln kann. RFC 3024 verlangt die Implementierung einer Bindungsprüfung und empfiehlt deren standardmäßige Aktivierung. Die äußere Quelle muss zur registrierten Care-of-Adresse passen, die innere zur registrierten Heimatadresse und die Kapselung zum ausgehandelten Verfahren.

Fehlt die zugehörige Bindung oder stimmt das Verfahren nicht, ist Verwerfen vorgesehen. Das begrenzt den Transitdienst auf eine bestimmte Beziehung. Es ist aber noch kein kryptographischer Nachweis für den Inhalt jedes einzelnen Datenpakets.

Auch bei der Einrichtung der Beziehung gibt es eine räumliche Schranke. Der Registrierungsantrag muss mit TTL 255 gesendet werden; der fremde Agent prüft, ob dieser Wert unverändert ankommt. Ein durchlaufener IP-Router verringert ihn. Das erschwert bestimmte Angriffe von außerhalb des Links, authentifiziert aber keinen Angreifer, der bereits auf demselben Link sitzt.

Die genaue Richtung der Registrierungsnachricht ist ebenfalls relevant. Ein verifiziertes technisches Erratum zu RFC 3024 ersetzt im Satz über die Aktualisierung der Bindung die Registrierungsantwort durch den Registrierungsantrag. Wer nur die ursprüngliche Zeile übernimmt, beschreibt den Auslöser des Zustandswechsels falsch.

Ein erfolgreicher Antrag kann die falsche Funktion verlieren

Wird ein Antrag mit Rückwärtstunnel abgelehnt, kann der mobile Knoten T entfernen und erneut anfragen. Die Registrierung mag dann gelingen. Falls das Besuchsnetz den passenden äußeren Quellheader des Tunnels benötigt, bleiben die Daten dennoch unbrauchbar. RFC 3024 warnt ausdrücklich vor diesem Ergebnis.

Der erfolgreiche Zustand ist nicht erfunden; er besagt nur weniger als der Beobachter möglicherweise annimmt. Eine reduzierte Vereinbarung wurde akzeptiert. Ob sie zum realen Netzpfad passt, ist eine weitere Frage. Ein Fallback kann so einen präzisen Ablehnungsgrund durch ein späteres, schwerer zuzuordnendes Schweigen ersetzen.

Im November 2010 verwies RFC 5944 beim Thema Eingangsfilter weiterhin auf den Rückwärtstunnel. Daraus lässt sich die Fortdauer des Architekturproblems ablesen, nicht eine bestimmte Verbreitung im Betrieb.

Die Hauptgrenze blieb bestehen: RFC 3024 verspricht keine allgemeine Firewall-Durchquerung. Ebenso wenig macht seine Erweiterung für unterschiedliche Adressräume private Adressen global eindeutig. Der Tunnel funktioniert, indem er Kontext mitführt und an definierten Stellen prüft. Er ist kein Ersatz dafür, zu wissen, wer in welchem Raum mit welcher Quelle senden darf.