Résumé

  • Le RFC 5324 donne des tables modifiables aux Policy Objects non actifs, une commande distincte pour les activer, un état de résultat et des objets actifs en lecture seule qui décrivent ce que la Fabric applique maintenant.
  • Une paire SA active reste une preuve plus étroite que le trafic protégé : il faut encore le sélecteur ordonné, la direction, le SPI, le transform négocié, le compteur et le résultat de couche supérieure.

Le stockage durable ne donne aucune autorité immédiate

Une équipe peut préparer une politique complète : membres autorisés, hôtes de gestion, restrictions de connectivité et attributs. Le MIB peut déclarer ses lignes non volatiles ou permanentes. Rien de cela ne signifie que les points d’application l’utilisent.

Le modèle FC-SP maintient les Policy Objects non actifs comme espace de travail. Le gestionnaire les édite, compose un nouveau Policy Summary, puis invoque une activation. Cette opération possède son propre résultat et peut échouer. Seuls les Policy Objects actifs, exposés en lecture seule, spécifient la politique actuellement appliquée.

Le reçu doit donc garder quatre faits : objet préparé, activation demandée, transition acceptée, ensemble actif relu. Les fusionner dans un drapeau « configuré » fait disparaître l’étape où l’autorité change réellement.

Le résumé relie les objets par leur empreinte

Le Policy Summary contient un pointeur vers chaque autre objet actif et associe ce pointeur à une empreinte cryptographique. L’ensemble comprend les listes de membres Switch et Node, la liste des hôtes IP autorisés à gérer la Fabric, puis les objets de connectivité et d’attributs.

Une empreinte cohérente lie le résumé à une valeur précise. Elle ne prouve pas que tous les Switches ont reçu cette valeur, qu’ils l’ont appliquée au même instant ou qu’un objectif métier a été atteint. Le nom administratif de la Fabric se trouve d’ailleurs dans la Switch Membership List, pas dans le résumé. Copier le nom depuis le mauvais objet change le sens sans changer les octets.

Permanent ne veut pas dire modifiable

StorageType décrit la réalisation mémoire. Le RFC précise que même avec permanent(4), aucune information de la ligne correspondante n’est nécessairement modifiable. La persistance répond à « survivra-t-elle ? »; l’écriture à « puis-je la changer ici ? »; l’activation à « est-elle appliquée ? ».

Les objets actifs et non actifs survivent à la fin d’une session du Security Policy Server. En revanche, la cohérence d’une lecture n’est garantie qu’à l’intérieur d’une session. Une collecte faite ligne par ligne hors verrou peut être authentique mais mélanger plusieurs époques.

Une authentification peut fournir une clé, pas un résultat applicatif

FC-SP accepte des infrastructures fondées sur secret, certificat ou mot de passe. DH-CHAP, FCAP et FCPAP peuvent effectuer une authentification mutuelle et produire une clé partagée. Cette clé peut ensuite servir à établir des Security Associations.

« Peut servir » n’est pas « a servi ». Une méthode configurée ne prouve pas une transaction. Une authentification ne prouve pas une SA. Une SA ne prouve pas qu’un cadre particulier l’a utilisée. Le MIB indique aussi un protocole éventuel vers un serveur externe; si ce serveur est inaccessible, une information locale peut être utilisée. Le chemin configuré n’est donc pas le chemin observé.

Le protocole SA Fibre Channel n’est pas IPsec

Le document qualifie le protocole de gestion SA de sous-ensemble d’IKEv2 adapté à Fibre Channel et précise qu’il ne s’agit pas d’IPsec. ESP_Header protège des cadres FC-2; CT_Authentication protège des CT_IU. Réutiliser des concepts ne transforme pas leur identité de protocole.

Chaque SA active possède une entrée SADB avec SPI, compteur de séquence et transforms. Les SA sont unidirectionnelles mais apparaissent par paires de même type, une dans chaque sens. t11FcSpSaPairTable possède donc une ligne par paire bidirectionnelle active.

Cette ligne prouve l’état de la paire chez l’entité observée. Elle ne dit pas que les deux sens ont transporté des données ni qu’une opération supérieure a réussi.

Le sélecteur donne sa portée à la SA

Les Traffic Selectors sont ordonnés. Certains prescrivent bypass ou discard; d’autres protect ou verify et pointent vers la SA correspondante. L’ordre de recherche décide de la première correspondance.

Une SA active dans la même Fabric ne suffit donc pas à qualifier un cadre de protégé. Il faut la direction, le sélecteur qui a gagné, son action, le SPI et le transform. Les tables de propositions ajoutent une autre frontière : ce qu’un initiateur offre et ce qu’un répondant accepte ne sont pas encore ce qui a été négocié.

Une durée par défaut n’est pas une durée restante

La durée SA par défaut peut être temporelle ou mesurée en octets. Elle ne s’applique que si la SA ne possède pas de valeur explicite. À expiration, la SA doit être terminée et éventuellement remplacée.

Reporter la valeur par défaut dans chaque ligne active fabrique une mesure. Le reçu conserve l’origine de la durée, l’unité, la valeur initiale, le restant observé, l’époque de création et l’identité du remplacement.

Le silence des notifications est volontaire

Une erreur d’authentification de cadre entrant pourrait produire une notification pour chaque cadre. Pour éviter l’inondation, t11FcSpSaNotifyAuthFailure est limitée. Après le premier échec d’une SA, les suivants sont supprimés durant une fenêtre. Même la première notification d’une autre SA peut être supprimée après qu’un nombre configuré de SA a déjà signalé dans cette fenêtre.

Les échecs doivent néanmoins être détectés et comptés. L’absence de trap peut donc signifier suppression locale, plafond à l’échelle de la Fabric, notification désactivée, perte du collecteur, redémarrage de l’agent ou absence réelle d’événement. Elle ne choisit pas entre ces branches.

L’historique jette ses plus anciennes preuves

La table des rejets AUTH contient au maximum une valeur configurée entre zéro et 1000 lignes. Lorsqu’elle est pleine, le rejet le plus ancien est remplacé. Après redémarrage elle peut être partielle; si la fonction n’est pas prise en charge, la capacité reste zéro.

Une table vide ne prouve donc pas « aucun rejet ». Le dernier type de notification est lui aussi borné depuis le dernier redémarrage du système de gestion. Un champ de raison vide peut signifier contenu indisponible, pas succès.

Chaque compteur a un propriétaire

Les index distinguent instance de gestion, Fabric, entité et interface. InterfaceIndexOrZero peut désigner une interface précise ou l’ensemble des interfaces de cette instance vers la Fabric. Certains compteurs agrègent des compteurs transitoires par SA et survivent à la disparition des lignes actives.

Une valeur sans tuple d’index n’a pas de propriétaire fiable. Un delta sans sysUpTime, gestion du redémarrage et largeur Counter32 n’a pas d’intervalle fiable. Le rapprochement temporel seul ne suffit pas.

Le reçu de décision

Pour une politique : session verrouillée, instance, Fabric, noms et empreintes non actifs, résumé proposé, source de la demande, résultat, raison et résumé actif relu. Pour une SA : entité, interface, pair, directions, SPI, transforms négociés, ordre des sélecteurs, durée et compteurs. Pour un échec : activation des notifications, fenêtre, plafond, suppression, capacité de table, éviction, redémarrage et livraison du collecteur.

Ce n’est qu’après ces étapes qu’une observation de cadre et un résultat de couche supérieure peuvent soutenir une affirmation de protection ou de livraison.

Sources