Zusammenfassung

  • RFC 5193 unterscheidet einen bereits vor PANA geschützten PaC-EP-Kanal von einem Kanal, dessen Schutz erst nach PANA aufgebaut werden muss. Der konkrete Pfad bestimmt, welche Umgebung vorliegt.
  • Ein Failover, der EP, Interface, Segment oder Lower-Layer-Peer ändert, darf die alte Klassifikation nicht allein über Client- oder Sitzungsidentität erben. Der neue Pfad braucht einen eigenen Nachweis und daraus abgeleitete EAP- und Association-Entscheidungen.

Verfügbarkeitssysteme optimieren auf Kontinuität. Ein Pfad fällt aus, ein Ersatz übernimmt, die Sitzung soll möglichst wenig davon merken. Sicherheitsklassifikationen optimieren auf etwas anderes: die Gültigkeit einer Aussage innerhalb ihres nachgewiesenen Bereichs.

Beide Ziele geraten in Konflikt, wenn ein Failover nur die Zieladresse oder den EP ändert, aber den Sicherheitskontext als unveränderlichen Sitzungswert behandelt. RFC 5193 macht deutlich, warum das nicht genügt. Ob Schutz bereits vor PANA existiert, entscheidet über Methodeneigenschaften und einen späteren Secure-Association-Schritt.

Ein neuer Pfad ist deshalb nicht nur eine neue Route. Er kann eine neue Sicherheitsumgebung sein.

Die Klassifikation gehört zum Pfad

Der Nachweis für secure-before sollte Client, Interface, Zugang, Lower-Layer-Peer oder physisches Segment, EP, Mechanismus, Schutzumfang und Beobachtungszeit verbinden. Seine Reichweite endet dort, wo eines dieser Elemente wechselt.

Die Sitzungs-ID kann gleich bleiben. Der Benutzer kann gleich bleiben. Selbst die IP-Adresse kann erhalten bleiben. Keine dieser Kontinuitäten beweist, dass der Ersatzpfad denselben Schutz gegen Spoofing und Mithören bietet.

Ein Failover-Controller muss daher nicht nur new_ep melden, sondern eine neue Attachment-Version erzeugen. Die alte Entscheidung bleibt historische Erklärung des Primärpfads. Für den Ersatzpfad wird secure-before neu bewiesen oder secure-after gewählt.

RFC 5193 schreibt keine Failover-Automatik vor. Die Forderung nach einem neuen Nachweis ist eine operative Folgerung aus der Abhängigkeit, nicht erfundener Normtext.

„Gleiche Produktfamilie“ ist kein Beleg

Primär- und Ersatz-EP können dieselbe Software, Konfiguration und Fähigkeit besitzen. Trotzdem können ihre Clientpfade verschieden sein: ein physisch isolierter Anschluss hier, ein gemeinsames Segment dort; bereits authentifizierter Funk hier, offene Bootstrap-Strecke dort.

Inventarähnlichkeit beweist Implementierbarkeit. Konfigurationsgleichheit beweist Absicht. Erst der pfadgebundene Zustand beweist, ob die Voraussetzung aktuell erfüllt ist.

Auch PAA/EP-Kolokation hilft nur an der internen Schnittstelle. Wenn der Ersatz-EP im selben Gerät wie der PAA läuft, wird die Clientstrecke dadurch nicht automatisch sicher. Der kurze Weg zwischen Funktionen ist nicht der Weg des Clients.

EAP-Auswahl darf nicht hinterherlaufen

Im ungeschützten Umfeld verlangt RFC 5193 eine EAP-Methode, die den dortigen Angriffen standhält und Schlüssel für die spätere Association erzeugt. Wird der Pfad erst nach der Methodenauswahl umgeschaltet, kann die gewählte Methode auf einer inzwischen falschen Annahme beruhen.

Der Entscheidungsbeleg muss deshalb den Zeitpunkt zeigen. Welche Attachment-Version galt bei Auswahl und Ausführung? Trat der Failover davor, währenddessen oder danach ein? Wurde die Auswahl neu bewertet? Entstand die Schlüsselanforderung für den Ersatzpfad?

Eine spätere erfolgreiche PANA-Ausführung beweist nicht, dass der Bootstrap-Kanal angemessen geschützt war. Sie ist ein Ergebnis ihres Protokollbereichs und kann den zeitlich früheren Umgebungsbeleg nicht ersetzen.

Alte Jobs können am falschen EP erfolgreich sein

Wenn secure-after gilt, folgt aus der Authentisierung ein Secure-Association-Protokoll zwischen PaC und EP. Während eines Failovers können Arbeiten für den Primär-EP noch laufen. Ein später Erfolg ist real, aber für den aktuellen Pfad irrelevant.

Job, Schlüsselkontext, Peer, EP und Attachment-Version müssen übereinstimmen. Statusaggregation darf nicht einfach den jüngsten grünen Job übernehmen. Sie muss fragen, ob das Ergebnis die aktive Beziehung betrifft.

Ebenso darf ein auf dem Ersatzpfad notwendiger Job nicht als überflüssig gelten, weil der Primärpfad bereits geschützt war. Schutz ist keine übertragbare Eigenschaft der Clientakte.

Failover-Beobachtung braucht zwei Erfolgskriterien

Der erste Erfolg ist Wiederherstellung des Pfads: der Client erreicht den vorgesehenen Zugang. Der zweite ist Erfüllung der Sicherheitsanforderung dieser neuen Beziehung. Beides kann zeitlich auseinanderliegen.

Ein Dashboard darf die Zustände gemeinsam zeigen, sollte sie aber nicht verschmelzen. traffic_path_restored, environment_evidence_valid, eap_profile_valid_for_attachment, association_required und association_observed beantworten verschiedene Fragen.

Damit wird auch Unsicherheit sichtbar. Der Ersatzpfad kann funktionieren, während sein Umgebungsnachweis fehlt. Lokale Policy entscheidet, ob Verkehr eingeschränkt, der stärkere Zweig erzwungen oder eine Prüfung verlangt wird. Der RFC legt diese Reaktion nicht fest.

Mindestbeleg des Szenariowechsels

Aufzeichnen: Failover-Ursache und Zeitpunkt, alte und neue EP-Identität, Interface und Segment, Attachment-Versionen, Schutzbelege beider Pfade, Policy-Version, EAP-Entscheidung, Schlüsselresultat, Association-Anforderung, Jobziel und beobachteten Endzustand.

Nichts davon muss in einer einzigen Tabelle leben. Entscheidend ist die unveränderte Korrelation. Ein System, das den alten Datensatz überschreibt, kann später nicht erklären, ob der Ersatzpfad je bewertet wurde.

Lu Hengs Running-Code-Primat setzt hier eine klare Autoritätsgrenze. Das Failover-Profil koordiniert. Der aktive Pfad entscheidet, welche Sicherheitswirklichkeit existiert. Ein geerbtes Symbol kann die neue Strecke nicht schützen.

Sources

  1. RFC 5193 HTML
  2. RFC 5193 Text
  3. RFC-5193-Eintrag
  4. Datatracker RFC 5193
  5. RFC-5193-Historie
  6. RFC-5193-Referenzen
  7. RFC-5193-Errata
  8. RFC 5191
  9. RFC-5191-Eintrag
  10. RFC 4058
  11. RFC-4058-Eintrag
  12. RFC 4016
  13. RFC 3748
  14. RFC 4306
  15. RFC 2409
  16. RFC 2865
  17. RFC 3588
  18. Heng Lu — Realitätsschichten
  19. Heng Lu — minimale Anfangsspezifikation
  20. Heng Lu — Primat des laufenden Codes