Zusammenfassung

  • RFC 2356 schlug vor, einen mobilen Knoten anhand eines stabilen NSID/MKID-Schlüsselselektors zu beurteilen, während seine äußere Care-of-Adresse wechselte.
  • Die erste authentisierte Nachricht konnte ohne vorgelagerten Sitzungsaufbau weitergeleitet werden; vertrauenswürdige öffentliche Komponenten, Nomadic-ACL, aktuelle Bindung und richtiger Traversal-Pfad blieben dennoch Voraussetzung.

Mobilität machte eine lange bequeme Annahme unbrauchbar: Wer dieselbe Maschine ist, sendet nicht zwingend von derselben Adresse. Für das Routing war dieser Wechsel vorgesehen. Für eine Firewall, deren Regeln eine Quelladresse mit einer Identität verknüpften, sah korrektes Verhalten wie ein Identitätsbruch aus.

RFC 2002 hatte Mobile IP in zwei Adressrollen gegliedert. Die Home-Adresse blieb bestehen. Eine Care-of-Adresse bezeichnete den gegenwärtigen Anschlusspunkt. Der Home Agent fing Verkehr an die Home-Adresse ab und tunnelte ihn zur aktuellen Adresse. Lag die Heimat in einem privaten Netz, konnte die innere Adresse jedoch nicht einfach als öffentlich routbares Ziel oder als glaubhafte äußere Quelle dienen.

Der im Juni 1998 als Informational veröffentlichte RFC 2356 von G. Montenegro und V. Gupta beschrieb dafür einen Entwurf von Sun Microsystems. Er war kein Internetstandard. Sein Geltungsbereich war enger: ein Knoten aus einem geschützten privaten Netz, der sich mit einer eigenen Care-of-Adresse direkt am öffentlichen Internet befand. Den Fall, dass der mobile Knoten selbst hinter einem anderen privaten Netz saß, deckte die Lösung nicht ab.

Das Dokument verglich SOCKS-5-Anwendungsweiterleitung mit einem IP-Verfahren auf Basis von SKIP. SKIP wurde als sitzungslose Schlüsselverwaltung beschrieben. Authentisierungsinformationen konnten in jedem Paket mitgeführt werden. Deshalb durfte die Firewall bereits das erste authentisierte Paket weiterleiten, ohne vorher einen eigenen Sitzungsaufbau abzuwarten.

„Ohne zusätzlichen Roundtrip“ bedeutete keineswegs „ohne vorbereitetes Vertrauen“. Mobile Node, Firewall und Home Agent benötigten authentisierte öffentliche Diffie-Hellman-Komponenten. Sie mussten vorkonfiguriert oder über Zertifikatsverzeichnis und Discovery beschafft werden. Die Datenebene sparte einen Austausch; Namensbindung, Schlüsselverteilung und lokale Politik verschwanden nicht.

Der entscheidende Schritt war eine alternative Schlüsselsuche. Ein SKIP-Header konnte mit NSID den Namensraum und mit MKID die Identität darin bestimmen. Bei NSID 1 durfte das MKID die stabile Home-Adresse des Knotens sein, während der äußere Quellheader eine wechselnde Care-of-Adresse zeigte. Für NSID 8 beschrieb der RFC eine Kennung aus einer unsignierten Diffie-Hellman-Komponente. Ohne Zertifizierungsstelle mussten die Namen der Beteiligten trotzdem sicher übermittelt werden.

Darauf baute ein nomadic-Eintrag der Zugriffsliste. Er erlaubte nicht beliebige Quellen. Er wies die Firewall an, Pakete wechselnder Quelladressen unter einer bestimmten Schlüsselidentität zu prüfen. AH oder eine entsprechend authentisierende ESP-Variante musste das Paket bestätigen. Danach entschied die ACL über Ziel und Dienst. Die Identität wählte eine Regel aus; sie ersetzte die Regel nicht.

Weil der mobile Knoten die Verbindung begann, konnte die Firewall die beobachtete Care-of-Adresse mit Schlüsselidentität und Home-Adresse dynamisch verbinden. Diese Bindung gab die Rückrichtung vor. Sie war absichtlich begrenzt: Der jüngste Registration Request ersetzte die vorherige Adresse. Gleichzeitige Mobile-IP-Bindungen funktionierten im einfachen Modell nicht, sofern die Firewall Registrierungsnachrichten nicht genauer verstand.

Gelerntes Zustandswissen band die Antwort an den tatsächlichen Weg. Hatte eine Firewall die Bindung aus dem Request erzeugt, musste die Registration Reply gewöhnlich über dieselbe Firewall hinauslaufen. Bei mehreren Grenzgeräten konnte asymmetrisches Routing die Antwort zu einem Gerät ohne Zustand führen. Eine Mobile-IP-bewusste Firewall konnte relevante Identität aus der Antwort zurückgewinnen, übernahm damit aber mehr Protokollinterpretation im Netzinneren.

Vor dem Traversal stand eine weitere Entscheidung: befand sich der Knoten innen oder außen? Adressbereiche halfen, waren aber laut RFC in realen Installationen nicht immer eindeutig. Sogar direkte Benutzereingabe konnte sinnvoll sein, weil der Mensch wusste, dass der aktuelle Anschluss extern war. Diese Angabe war eine operative Klassifikation, kein Beweis des physischen Standorts.

Der Home Agent benötigte ebenfalls Hinweise. Die Traversal Extension in Registration Requests und Replies nannte Durchgangspunkte in beiden Richtungen und konnte mehrere Firewalls abbilden. Werte aus der Gegenrichtung durften als Hinweise interpretiert werden. Eine genannte Traversal-Adresse bewies weder erfolgreiche Authentisierung noch Kapselung oder Weiterleitung.

Vier Kanalanordnungen machten die Kontrollfrage sichtbar. Nur der öffentliche Abschnitt konnte verschlüsselt sein. Verschlüsselung konnte Ende zu Ende reichen und die Firewall zum Relay machen, während der Home Agent authentisierte. Eine Zwischen-Authentisierung erhielt die Ende-zu-Ende-Verschlüsselung, verlangte aber die Offenlegung eines langfristigen paarweisen Diffie-Hellman-Geheimnisses an den Zwischenknoten. Zwei getrennte verschlüsselte Kanäle konnten an der Firewall enden; dann konnte sie Inhalte prüfen. Ein zusätzlicher Tunnel stellte Vertraulichkeit gegenüber ihr wieder her.

Verschlüsselung allein sagte daher nicht, wer sehen oder entscheiden durfte. IP-in-IP nach RFC 2003 löste Transport zwischen Adressräumen. AH authentisierte. ESP schützte Vertraulichkeit und konnte authentisieren. Ein korrekt gekapseltes Paket konnte unerlaubt sein; ein authentisiertes Paket konnte falsch geroutet werden; ein weitergeleitetes Paket musste vom Zielprogramm noch lange nicht verarbeitet sein.

Auf dem Rückweg fing der Home Agent Verkehr zur Home-Adresse ab, kapselte ihn zur Care-of-Adresse und leitete ihn über die Firewall. Diese nutzte die dynamische Bindung zum Schutz der öffentlichen Strecke. Eine erfolgreiche Registration Reply, eine vorhandene Bindung und ein Relay-Eintrag belegten jeweils einen Schritt. Sie belegten nicht die Verarbeitung beim Korrespondenten oder das Ergebnis für den Benutzer.

Der Sicherheitsabschnitt erklärte den mobilen Rechner schließlich zum erweiterten Teil des privaten Perimeters. Weil er für DHCP, Abrechnung oder andere öffentliche Zwecke unverschlüsselten Verkehr führen konnte, brauchte er eigene Filter. Wurde er kompromittiert, konnte seine gültige Identität einen Zugang nach innen eröffnen. Beständige Wiedererkennung verringerte Fehlablehnungen und vergrößerte zugleich den Schaden übermäßiger Berechtigung.

Der bleibende Wert von RFC 2356 liegt in dieser Belegkette: beobachtete äußere Adresse, behauptete Home-Adresse, NSID/MKID, Herkunft der öffentlichen Komponente, AH/ESP-Ergebnis, ACL-Entscheidung, Erzeugung und Ablösung der Bindung, Innen/Außen-Klassifikation, Traversal-Richtung, Registrierung, Relay, Zustellung und Anwendungsergebnis. Kein früher Beleg füllt den nächsten automatisch aus.