Zusammenfassung

  • Der in RFC 5164 beschriebene gemeinsame Transport sollte Discovery, Sicherheit und Übertragung für Information, Event und Command bereitstellen, ohne die Dienstnutzlast zu prüfen.
  • Frühe Abwehr gegen Fälschung und Last gehört in die gemeinsame Schicht; die Vollmacht für einen opaken Befehl kann nur die ihn verstehende Dienstgrenze prüfen.

Ein Netzwerkknoten kann einen Angreifer abwehren und trotzdem den falschen legitimen Partner zu viel tun lassen. Genau dort endet die Aussagekraft einer gültigen Sicherheitsassoziation.

RFC 5164 ist eine informative Problemstellung von 2008. Ausgangspunkt war IEEE 802.21: Ein mobiles Gerät sollte über heterogene Zugänge Informationen, Ereignisse und Befehle austauschen können. Statt für jeden Dienst Transport, Discovery und Sicherheit neu zu erfinden, skizzierte das Dokument eine Mobility Service Transport Layer über IP.

Oberhalb liegen dienstspezifische Protokolle. Unterhalb steht ein gemeinsamer Container. Nach seinem Header folgt eine opake Nutzlast, die MSTP nicht inspiziert. Das erhält die Zuständigkeit anderer Standards und ermöglicht neue Dienste. Es verbietet zugleich, Transporterfolg als semantische Freigabe zu verbuchen.

Abwehr hat drei Kostenstellen

RFC 5164 nennt Denial-of-Service nicht nur als Paketproblem. Netzwerkknoten können durch mobile Geräte belastet werden, besonders wenn Dienstprotokolle teure Berechnung auslösen. Der Entwurf muss entscheiden, an welcher Stelle Abwehr greift: bei Discovery, beim Aufbau des Transports oder im dienstspezifischen Austausch.

Diese drei Stellen sehen unterschiedliche Fakten. Discovery kann Anfrageraten, Quellplausibilität und Gültigkeit eines Verzeichniseintrags prüfen. Der Transport kann kryptographische Kosten, Zustandsaufbau, Integrität und Replay kontrollieren. Erst der Dienst kennt Befehlsart, Ziel, Berechtigung und erwartete Wirkung.

Alles früh zu entscheiden würde Semantik in die gemeinsame Schicht ziehen. Alles spät zu entscheiden ließe einen Angreifer teure Assoziationen und Parser auslösen. Ein belastbarer Entwurf staffelt daher Kosten: billige, allgemeine Zurückweisung zuerst; teure semantische Prüfung nur nach begrenzter Zulassung; Wirkung erst nach Dienstvollmacht.

Discovery findet einen Knoten, nicht seine Zuständigkeit

Ein Knoten kann fest im Gerät hinterlegt, über DHCP oder Router Discovery mitgeliefert oder dynamisch gesucht werden. Da sein Ort offen bleibt, muss Discovery Verwaltungsgrenzen überschreiten. Geschwindigkeit, Spoofing-Schutz, Zeitpunkt und Lebensdauer der Information gehören zur Anforderung.

Ein Treffer hat daher Ablaufdatum und Herkunft. Festkonfiguration kann veralten. Ein Zugangsnetz kann einen erreichbaren Dienst melden, ohne für dessen Befehlsrechte einzustehen. Dynamische Suche kann einen Typ finden, ohne dessen genaue Fähigkeit oder Autorität zu beschreiben.

Das Dokument empfiehlt, bestehende AAA- oder SEND-Vertrauensbeziehungen zu nutzen. Zusätzlich sollen netzseitige Dienstinstanzen ihre Befugnis gegenüber besuchenden Geräten belegen. Wer einen Schlüssel besitzt, ist identifiziert; was er in einem bestimmten Dienst tun darf, bleibt eine zweite Entscheidung.

Ein Durchschnitt verdeckt drei Betriebsverträge

Event- und Command-Nachrichten wurden im Bereich einiger hundert Millisekunden erwartet. Information Service konnte erst beim Besuch eines neuen Netzes, nach Stunden oder Tagen, gebraucht werden. Typische Events und Commands lagen bei 50 bis 100 Byte; Informationsantworten konnten 64 KB überschreiten.

Eine kurzfristig aufgebaute zuverlässige Verbindung kostet Handshake-Zeit. Eine dauerhafte Verbindung kostet Zustand und setzt stabile Beziehungen voraus. Verbindungsloser Betrieb spart Aufbau, kollidiert aber mit Zuverlässigkeit. Große Antworten verlangen Fragmentierung und Staukontrolle, während kurze Befehle durch Wiederholung doppelte Wirkung entfalten können.

Der RFC lässt offen, ob Zuverlässigkeit im Transport oder durch Bestätigung des Mobilitätsdienstes entsteht. In beiden Fällen endet der Beweis bei der jeweiligen Schicht. Transportbestätigung ist keine Ausführungsbestätigung; Dienstannahme ist kein Beleg für erfolgreichen Handover.

Ein Linkwechsel darf die Transaktion nicht umbenennen

Eine Anfrage kann über den alten und die Antwort über den neuen Link laufen. Der Transport soll mehrere Links empfangen; der MSTP-Nutzer führt Nachrichten derselben Sitzung oder Transaktion zusammen. IP-Mobilität liefert bei Bedarf Sitzungskontinuität.

Damit sind Interface und Adresse keine Transaktionsidentität. Erforderlich sind ein begrenzter Transaktionsschlüssel, Dienstklasse, Vertrauenskontext, Hin- und Rücklink, Zeitfenster, Autorisierungsentscheidung und Ergebnis. Fehlt ein Element, kann ein legitimer Pfadwechsel wie ein Angriff aussehen – oder fremde Daten können sich hinter einem vertrauten Pfad verstecken.

Vertraulichkeit verhindert nicht automatisch Tracking

Mobilitätsnachrichten können Zellwechsel offenlegen oder künftige Bewegung vorhersagbar machen. RFC 5164 fordert verfügbare Vertraulichkeit und Integrität sowie möglichst Identitätsschutz beim Aufbau der Sicherheitsassoziation. Ein Nutzer soll für lokale Dienste nicht mehr Identität preisgeben als bereits für die Authentisierung nötig war.

Ein universeller Transport-Identifier erleichtert Korrelation und wird dadurch selbst zum Risiko. Eine zeitlich begrenzte Berechtigungs- und Transaktionskennung genügt oft. Ihre Aufbewahrung gehört in denselben Beschluss wie ihre Einführung.

Eine RFC-Nummer ist kein Laufzeitstatus

RFC 5164 entschied ausdrücklich nicht zwischen Anpassung eines bestehenden Protokolls und Neuentwicklung. Es verlangte realistische Leistungsziele aus machbaren Szenarien. Die Veröffentlichung beweist eine strukturierte Problemstellung, keine Implementierung oder Adoption.

Die gemeinsame Ebene sollte deshalb nur lokal prüfbare Transport- und Sicherheitsfakten besitzen. Bedeutung, Vollmacht und Wirkung bleiben bei dem Dienst, der die Folge trägt.

Quellen