Résumé

  • RFC 5191 permet au PANA Authentication Agent et à l’Enforcement Point d’être des nœuds distincts. La réussite de l’échange avec le PAA ne constitue donc pas une lecture des filtres effectivement installés sur l’EP.
  • Le protocole PAA–EP, la création des filtres et la protection du trafic de données se trouvent hors de la spécification PANA. Une exploitation honnête conserve séparément décision, projection, installation, passage et résultat applicatif.

L’incident semblait impossible parce que deux consoles affichaient des vérités différentes. Le PAA montrait une session autorisée, une durée valide et un échange final protégé. L’EP montrait encore le filtre qui bloquait le client. Il n’y avait pas deux réalités concurrentes. Il y avait deux surfaces de contrôle et un reçu manquant entre elles.

RFC 5191 présente PANA comme une couche inférieure d’EAP sur UDP. Le PaC porte les justificatifs du client ; le PAA vérifie l’authentification et décide, directement ou avec une infrastructure AAA, de l’autorisation d’accès. L’EP applique les politiques paquet par paquet. Le PAA et l’EP peuvent être colocalisés, mais le texte n’en fait pas une obligation.

Cette possibilité architecturale interdit un raccourci courant : « autorisé » ne signifie pas encore « filtre installé partout ». La décision appartient au PAA. Le comportement des paquets appartient à l’EP. Entre les deux, la projection de politique est une transaction à part entière.

Une autorisation n’est pas son installation

La phase d’authentification et d’autorisation se termine par un échange PANA-Auth marqué Complete. En cas de succès, le PAA fournit aussi la durée de session. Si la méthode EAP produit un MSK, le Key-Id et l’AVP AUTH protègent l’échange final et les messages suivants.

Ce reçu est fort sur son périmètre. Il relie un PaC, un PAA, une session, une décision et du matériel cryptographique. Il ne contient pas une photographie de chaque EP. RFC 5191 place explicitement le protocole PAA–EP et la création des filtres hors de sa propre portée.

Le standard demande que l’échange PAA–EP soit protégé contre l’usurpation, la modification et le rejeu. Cette exigence ne prouve pas qu’un déploiement donné a envoyé la politique, reçu un acquittement ou vérifié l’installation. Elle dit comment protéger la commande, non comment constater son effet.

Le dossier d’exploitation doit donc nommer tous les EP visés. Pour chacun : version de politique, identité du PaC, interface, sens du filtre, transaction de projection, acquittement, empreinte de la règle installée et instant de lecture. Avec quatre EP, « trois conformes et un inconnu » vaut mieux qu’un succès global inventé.

EAP Success peut encore finir en refus

La séparation commence avant même l’EP. RFC 5191 décrit le cas où EAP produit Success, mais où l’autorisation réseau est rejetée par le serveur AAA ou localement par le PAA. Le dernier message porte alors PANA_AUTHORIZATION_REJECTED et la session se termine.

Une méthode d’authentification atteste un résultat d’identité selon ses propres règles. Elle ne fixe pas à elle seule les droits commerciaux, la posture du terminal, la fenêtre temporelle ou le service demandé. Copier EAP Success dans une colonne « accès accordé » efface la décision qui possède réellement cette autorité.

Le reçu minimal doit conserver le résultat EAP, la méthode, l’identité observée, la disponibilité éventuelle d’un MSK, le résultat d’autorisation, sa source et le sort de la session. La présence d’une clé ne transforme pas un refus en permission.

Cette précision évite aussi une erreur organisationnelle. Une équipe identité ne doit pas réparer des justificatifs qui ont fonctionné lorsque la politique a refusé le service. Inversement, une équipe réseau ne doit pas ouvrir manuellement un filtre pour masquer un échec d’authentification.

Le changement d’adresse appartient encore à une autre étape

Après une authentification et une autorisation réussies, le PaC peut devoir reconfigurer son adresse IP avant de disposer d’une adresse utilisable à travers l’EP. Le PAA l’annonce avec le bit IP Reconfiguration ; la méthode de reconfiguration reste hors du document.

Le client peut donc avoir une session PANA valide tout en utilisant encore l’adresse de la phase pré-authentification. Un test lancé contre cette ancienne adresse ne mesure pas le service autorisé. Une règle attachée au mauvais tuple peut également donner l’apparence d’une projection réussie sans laisser passer le trafic attendu.

Il faut conserver une chronologie : adresse et interface utilisées pour PANA, instruction de reconfiguration, nouvelle adresse et provenance du bail, voisinage et route, projection EP mise à jour, puis premier paquet observé. Remplacer l’ancienne adresse par la nouvelle détruit l’histoire qui explique la transition.

La fin du contrôle n’est pas encore la disponibilité du chemin. Elle autorise le passage vers la prochaine surface de preuve.

AUTH protège la signalisation, pas automatiquement les données

La PANA Security Association protège la signalisation bidirectionnelle entre PaC et PAA. La clé dérivée permet à l’AVP AUTH de couvrir en-tête, contenu PANA et message EAP transporté. Injection, modification et rejeu deviennent alors détectables dans ce canal.

RFC 5191 traite séparément le chiffrement paquet par paquet. Un réseau qui n’a pas déjà protégé la couche inférieure peut dériver des clés et les utiliser avec une association sécurisée de liaison ou IPsec. La génération et l’emploi de ces clés par ce protocole supplémentaire se trouvent hors de la spécification.

Un échange PANA entièrement authentifié ne prouve donc ni l’algorithme appliqué aux données, ni les sélecteurs d’une SA IPsec, ni son installation, ni ses compteurs. Il prouve la protection de la conversation de contrôle.

L’inventaire doit créer deux objets : la PANA SA avec Session ID, Key-Id, durée et vérification AUTH ; l’association de protection des données avec pairs, sélecteurs, algorithmes, état, compteurs et échéance. Une relation de dérivation peut les relier sans les confondre.

Le ping répond à une question étroite

Dans la phase d’accès, une requête et une réponse PANA Notification portant le bit Ping peuvent vérifier que le pair PANA est vivant. Un message de réponse valide à une requête récente est une preuve de liveness du pair.

Ce n’est pas une transaction applicative. Le PAA peut répondre tandis qu’un EP séparé a perdu sa règle. Le chemin de contrôle peut vivre pendant que le routage, la résolution de voisinage, le chiffrement des données ou le serveur distant échoue.

La formulation correcte garde la cible : « le PAA a répondu à un ping PANA protégé à T ». Pour dire « service disponible », il faut mesurer le chemin et le service. RFC 5191 avertit en outre qu’un keepalive périodique mal utilisé peut créer de la congestion et de fausses alarmes.

Une métrique bon marché ne doit pas obtenir par commodité l’autorité d’un test qu’elle n’a jamais exécuté.

Durée de session et continuité de service

La durée PANA est bornée par la durée de l’autorisation. Une réauthentification peut l’étendre. À défaut, l’expiration participe au nettoyage de la session et de l’accès.

Cette durée décrit une permission et la conservation d’un état de contrôle. Elle ne promet pas que le filtre restera correct, que l’adresse restera routée ou que l’application répondra pendant tout l’intervalle. Les indications de couche inférieure peuvent accélérer la détection d’une déconnexion, mais leur fiabilité dépend de la topologie ; le texte les traite comme des indices à vérifier.

Conserver séparément la durée d’autorisation, la durée de la PANA SA, l’échéance des règles EP, les tentatives de réauthentification et la fenêtre de service observée transforme un « timeout » générique en diagnostic.

La terminaison doit atteindre tous les EP

PaC ou PAA peut demander une terminaison anticipée. Le modèle prévoit la suppression de l’état PANA, la fin de la comptabilité et le retrait de l’état par client sur les EP. En cas de séparation PAA–EP, une terminaison authentique reste une commande dont la convergence doit être observée.

Une règle d’autorisation résiduelle crée une exposition ; une règle de refus résiduelle bloque une reconnexion légitime. Dans les deux cas, lire uniquement la session PAA masque le problème. Il faut enregistrer cause, message protégé, fermeture comptable, liste des EP, acquittements de suppression et lecture postérieure des tables.

La disparition de l’objet de contrôle au PAA ne prouve pas la disparition de toutes ses projections.

Un objet de preuve pour l’accès

Le dossier commence par le PaC, son interface, la source de découverte du PAA et le service demandé. Les options DHCP de RFC 5192 ou un relais de RFC 6345 donnent une destination ; elles ne remplacent pas l’authentification ultérieure.

Chaque message PANA conserve Session ID, séquence, retransmission et résultat de validation. Le résultat EAP reste distinct de l’autorisation. Le dernier échange stocke Result-Code, Complete, Key-Id, AUTH et durée.

Puis viennent les preuves externes à PANA : transition d’adresse, transactions vers chaque EP, règles réellement installées, association de protection des données si nécessaire, observation de paquets, reçu distant et résultat applicatif.

Ce modèle accepte qu’une étape soit verte et la suivante rouge. C’est précisément ce qui lui permet de localiser le contrôle. La clarté ne consiste pas à réduire neuf étapes à un voyant. Elle consiste à ne faire dire à chaque reçu que ce qu’il a effectivement observé.

Sources

  1. RFC 5191 HTML
  2. RFC 5191 texte
  3. Notice RFC 5191
  4. Datatracker RFC 5191
  5. Historique RFC 5191
  6. Références RFC 5191
  7. Errata RFC 5191
  8. RFC 5192
  9. Notice RFC 5192
  10. RFC 5193
  11. Notice RFC 5193
  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