Zusammenfassung

  • RFC 5191 erlaubt die Trennung von PANA Authentication Agent und Enforcement Point. Eine positive Entscheidung am PAA ist deshalb kein Sammelbeleg für die Filterzustände aller EPs.
  • PAA-zu-EP-Protokoll und Filtererzeugung liegen außerhalb des PANA-Protokolls. Bei mehreren EPs braucht der Betreiber eine explizite Zielmenge, Policy-Versionen, Einzelquittungen und Readbacks statt eines globalen Erfolgsbits.

Der Fehler war kein klassischer Totalausfall. Der Client funktionierte über drei Wege und scheiterte über den vierten. Gerade diese Teilfunktion machte den Bericht glaubwürdig: Authentisierung und Autorisierung waren wirklich erfolgreich. Nur die Schlussfolgerung, damit sei die Policy überall wirksam, war falsch.

PANA trägt EAP über UDP zwischen PaC und PAA. Der PAA prüft Anmeldeinformationen und autorisiert, gegebenenfalls mit einem AAA-Backend, den Netzzugang. Der Enforcement Point wendet Filter auf eingehenden und ausgehenden Verkehr eines Access Device an. Beide Rollen dürfen auf demselben Knoten liegen, müssen es aber nicht.

Sobald sie getrennt sind, wird aus einer Entscheidung eine verteilte Projektion. Jeder EP besitzt eine eigene ausführende Oberfläche. Ein grüner PAA-Zustand ist dann der Anfang der Konvergenz, nicht ihr Nachweis.

Erfolg ist bei mehreren EPs ein Vektor

Die letzte PANA-Auth-Sequenz mit Complete-Bit beendet die Authentisierungs- und Autorisierungsphase. Bei PANA_SUCCESS enthält sie die Session-Lifetime; bei einem schlüsselerzeugenden EAP-Verfahren können Key-Id und AUTH die abschließenden Nachrichten schützen.

Dieses Receipt beschreibt PaC, PAA, Session und Entscheidung. RFC 5191 nennt das PAA-zu-EP-Protokoll und die Erstellung der Access-Control-Filter ausdrücklich als Bestandteile einer vollständigen Lösung, die außerhalb der PANA-Protokollspezifikation liegen.

Die Kommunikation zur Bereitstellung autorisierter PaC-Informationen am EP muss gegen Fälschung, Änderung und Replay geschützt werden. Das ist eine Sicherheitsanforderung an den Auftrag. Sie beweist nicht, dass ein bestimmter Auftrag an alle erforderlichen EPs gesendet, angenommen und installiert wurde.

Bei vier Ziel-EPs ist der Status eine vierteilige Menge. Für jeden Eintrag gehören Policy-Version, PaC- und Interface-Bindung, Adressen, Filterrichtung, Transaktions-ID, Acknowledgement, installierter Fingerprint und Lesezeit in das Evidence Object. „Drei von vier auf Version 42, EP-D unbekannt“ ist handlungsfähig. „PANA erfolgreich“ ist für diese Frage ohne Aussagekraft.

Das Quorum muss der Topologie folgen

Ein beliebiger Ack ist selten ein sinnvolles Quorum. Wenn der Client je nach Routing einen von vier Pfaden nimmt, können alle vier erforderlich sein. Wenn zwei EPs aktiv und zwei nur Standby sind, kann die Bereitschaft des Standby trotzdem Teil des Failover-Vertrags sein. Der Dienst muss festlegen, welche Zielmenge für welchen Zustand notwendig ist.

Auch Richtung zählt. Ein Ingress-Filter kann installiert sein, während der Egress-Filter fehlt. Eine Policy kann am ersten Hop wirksam sein, aber hinter einem Relay nicht. Ein einziges Boolean verliert diese Asymmetrie.

Die Projektionskennung sollte die autorisierte Entscheidung referenzieren und monoton oder anderweitig eindeutig versioniert sein. Sonst kann eine verspätete Nachricht der alten Session die neue Regel überschreiben oder ein altes Delete die aktuelle Freigabe entfernen.

Konvergenz ist nicht die Anzahl empfangener Bestätigungen. Sie ist die belegte Übereinstimmung der notwendigen Ausführungsflächen mit der beabsichtigten Version.

EAP Success kann vor der Autorisierung enden

Noch vor der Projektion gibt es eine zweite Grenze. RFC 5191 beschreibt den Fall, dass EAP Success erzeugt, die Netzwerkzugangsautorisierung aber durch AAA oder lokal am PAA abgelehnt wird. Dann sendet der PAA PANA_AUTHORIZATION_REJECTED und beendet die Session.

Ein gültiger Identitätsnachweis ist keine Berechtigung. Selbst wenn ein MSK entstanden ist und der letzte Austausch durch AUTH geschützt wird, bleibt die geschützte Aussage eine Ablehnung.

Das Protokollobjekt muss EAP-Verfahren, Peer, Ergebnis und exportiertes Schlüsselmaterial getrennt von Autorisierungsentscheidung, Entscheider, Dienst, Laufzeit und Begründung speichern. Wer EAP Success direkt in „zugelassen“ übersetzt, erzeugt einen Zustand, den weder AAA noch PAA ausgesprochen hat.

Diese Trennung verhindert falsch adressierte Reparatur: Ein Policy-Reject ist kein kaputtes Zertifikat, und ein Authentisierungsfehler darf nicht durch einen manuell geöffneten EP-Filter kaschiert werden.

Ein erfolgreicher Austausch kann eine neue Adresse verlangen

Nach erfolgreicher Authentisierung und Autorisierung kann der PaC seine IP-Adresse neu konfigurieren müssen. Der PAA signalisiert dies mit dem IP-Reconfiguration-Bit, weil die für PANA verwendete Adresse nicht zwingend für Datenverkehr durch den EP geeignet ist. Das Verfahren der Neukonfiguration liegt außerhalb von RFC 5191.

Damit ändert sich möglicherweise auch der Schlüssel, unter dem der EP eine Regel führt. Der Betreiber muss Pre-Auth-Adresse, Interface, Reconfiguration-Anweisung, neue Lease-Herkunft, Neighbor- und Route-Zustand, Policy-Update und erstes beobachtetes Paket als Sequenz speichern.

Wird nur die aktuelle Adresse behalten, verlieren PANA-Log und Daten-Capture ihre Verbindung. Ein EP kann noch den alten Tuple erlauben, während der Client den neuen benutzt. Die Autorisierung bleibt korrekt, doch die Projektion ist praktisch nutzlos.

Mehrere EPs verschärfen die Lage: Manche können bereits die neue Bindung haben, andere noch die alte. Das ist eine weitere Dimension des Konvergenzvektors.

Die PANA SA schützt Signalverkehr

Wenn EAP einen MSK erzeugt, entsteht eine PANA Security Association. Der abgeleitete PANA_AUTH_KEY schützt Header und Payload der PANA-Nachrichten einschließlich des transportierten EAP-Inhalts. Die PANA SA liefert Authentisierung und Integrität für den Kontrollkanal PaC–PAA.

Per-Packet-Ciphering ist eine andere Oberfläche. Wo die untere Schicht nicht schützt, kann Material abgeleitet und mit einer Link-Layer- oder IPsec-artigen Secure Association verwendet werden. Erzeugung und Einsatz dieser Daten-SAs liegen außerhalb des Dokuments.

Ein AUTH-verifizierter PAA-Auftrag beweist daher weder Datenverschlüsselung noch die Installation der entsprechenden SA auf allen Pfaden. PANA SA und Data SA brauchen getrennte Objekte: hier Session ID, Key-Id, Lifetime und Message Verification; dort Endpunkte, Selektoren, Algorithmen, Replay Window, Installationszustand und Counter.

Eine Derivationskante verbindet sie. Sie macht sie nicht identisch.

PANA Ping fragt nur den Peer

In der Access-Phase können Notification Request und Answer mit Ping-Bit die Liveness des PANA-Peers testen. Eine gültige Antwort auf eine jüngste Anfrage ist ein enger, brauchbarer Beleg: Der Peer antwortete.

Sie fragt keinen separaten EP nach dessen Filter und durchläuft nicht den Anwendungspfad. Ein PAA kann antworten, während EP-D die Policy verloren hat. Umgekehrt kann ein periodischer Keepalive durch Congestion scheitern und einen Fehlalarm erzeugen, obwohl Daten weiterlaufen; vor diesem Einsatz warnt RFC 5191.

Die Metrik muss ihr Ziel tragen. „PAA alive“ ist keine EP-Konvergenz und kein Service-Health. Für diese Aussagen braucht es Rule Readback, Packet Observation und Application Transaction.

Lifetime ist keine gemeinsame Uhr

Die PANA Session-Lifetime ist an die aktuelle Autorisierungslaufzeit gebunden. Re-Authentication kann sie verlängern; ohne Verlängerung endet Session und PANA SA.

EP-Regeln, IP-Lease, Data SA und beobachteter Dienst können andere Uhren haben. Eine Stunde Autorisierung garantiert weder eine Stunde Policy-Konvergenz noch eine Stunde Paketdurchgang. Lower-Layer-Indications dürfen einen Disconnect früher anzeigen, sind laut RFC aber topologieabhängige Hinweise.

Jede Laufzeit wird separat gespeichert. Eine Abweichung zwischen PAA-Lifetime und EP-Expiry ist kein Darstellungsproblem, sondern der Mechanismus eines späteren Fehlers.

Termination muss auf derselben Zielmenge konvergieren

PaC oder PAA kann die Session vorzeitig beenden. Das soll PANA-Zustand löschen, Accounting stoppen und den per-PaC-Zustand auf den EPs entfernen. Auch diese Entfernung ist in einer getrennten Architektur verteilt.

Ein geschütztes Termination-Message beweist einen authentischen Auftrag. Für die Wirkung braucht es Delete-Transaktion, Zielmenge, Einzel-Acks und Post-Delete-Readback. Ein verbliebenes Allow erweitert den Zugang; ein verbliebenes Deny blockiert die nächste legitime Session.

Besonders gefährlich ist das frühe Löschen des PAA-Objekts. Ohne dessen Policy-ID und EP-Liste lässt sich die verwaiste Regel später nicht mehr zuverlässig zuordnen. Das Audit-Ledger muss länger leben als die operative Session.

Discovery bleibt eine Kandidatenquelle

RFC 5192 liefert DHCP-Optionen für PAA-Adressen; RFC 6345 definiert ein Relay Element. Diese Mechanismen sagen, wohin ein erster Versuch geht. Sie authentisieren die gefundene Adresse nicht vorab.

DHCP-Server, Option, Lease, Interface und Relay werden als Herkunft gespeichert und anschließend mit der validierten PANA/EAP-Session verbunden. Falsche Discovery, unerreichbares Relay, Authentisierungsfehler, Autorisierungsreject und partielle EP-Projektion sehen für den Nutzer ähnlich aus, besitzen aber andere Kontrollpunkte.

Ein Ziel zu kennen heißt nicht, seine Autorität bewiesen zu haben.

Ein Receipt für verteilte Ausführung

Das Evidence Object beginnt mit PaC, Interface, Discovery-Herkunft und gewünschtem Dienst. Es speichert PANA Messages, Sequenzen, Retransmissions und Validierung. EAP Result und Authorization Result bleiben getrennt.

Am Ende stehen Result-Code, Complete, Key-Id, AUTH und Lifetime. Danach folgt die Address Transition. Für jeden EP werden Projektion, Version, Ack, Filter und Readback angehängt. Falls Datenverschlüsselung nötig ist, folgt die separate Data SA. Packet Capture, Remote Receipt und Application Outcome schließen die Kette.

Eine solche Darstellung kann Teilkonvergenz zeigen, ohne einen echten PANA-Erfolg abzuwerten. Der PAA hat korrekt entschieden. Drei EPs haben korrekt ausgeführt. Der vierte hat keinen Beleg geliefert. Erst diese präzise Verteilung der Autorität macht den Fehler sichtbar.

Quellen

  1. RFC 5191 HTML
  2. RFC 5191 Text
  3. RFC 5191 Datensatz
  4. Datatracker RFC 5191
  5. RFC 5191 Historie
  6. RFC 5191 Referenzen
  7. RFC 5191 Errata
  8. RFC 5192
  9. RFC 5192 Datensatz
  10. RFC 5193
  11. RFC 5193 Datensatz
  12. RFC 4058
  13. RFC 4016
  14. RFC 3748
  15. RFC 4137
  16. RFC 5247
  17. RFC 6345
  18. Heng Lu — On Reality Layers
  19. Heng Lu — Minimum Initial Specification
  20. Heng Lu — Running-Code Primacy