Résumé

  • Dans RFC 791, l’option de type 130 occupait onze octets et réunissait quatre dimensions de contrôle ; RFC 1038 puis RFC 1108 ont conservé le numéro tout en remplaçant le format.
  • RFC 1108 faisait de la classification et des autorités de protection les entrées d’une politique appliquée par interface, avec des étiquettes explicites ou implicites selon le réseau.
  • RFC 7126 constatait que ces paquets n’avaient normalement pas leur place sur l’Internet public, mais déconseillait pourtant aux équipements génériques de les supprimer par défaut : dans un réseau MLS fermé, le retrait pouvait provoquer un mauvais classement.

Le paquet sans étiquette n’est pas un paquet neutre

Le paradoxe apparaît clairement dans RFC 7126. Une option de sécurité inconnue semble être une surface inutile ; la supprimer paraît donc prudent. Mais si le destinataire exige le Basic Security Option, il rejettera le paquet devenu incomplet. S’il autorise une étiquette implicite, il peut au contraire accepter les données sous le niveau affecté à l’interface. Le contenu n’a pas changé, mais la décision de sécurité, elle, a changé.

Cette erreur n’a pas une direction unique. Une élévation indue peut bloquer des usages légitimes et introduire des données dans un environnement plus restreint. Un abaissement indu peut les exposer à des personnes ou à des systèmes non autorisés. Le pare-feu n’a donc pas simplement retiré une décoration : il a substitué, sans le connaître, le contexte local du récepteur à une indication explicite du paquet.

Le type 130 n’est ni un chiffrement, ni une authentification, ni une preuve d’habilitation. Il fournit une donnée à des composants de confiance. Sa valeur de sécurité vient de la chaîne complète — attribution, configuration, protection des hôtes et contrôle des interfaces — et non de quelques bits isolés.

En 1981, quatre contrôles tenaient dans onze octets

RFC 791 fixait la longueur de l’option Security à onze octets. Après le type et la longueur venaient un champ Security de seize bits, un champ Compartments de seize bits, un champ Handling Restrictions de seize bits et un Transmission Control Code de vingt-quatre bits.

Le premier champ exprimait un niveau nommé. Les compartiments distinguaient des catégories contrôlées. Les restrictions de traitement renvoyaient aux règles de contrôle et de diffusion, tandis que le TCC désignait des communautés d’intérêt. Le modèle ne se réduisait donc pas à une échelle « secret / non secret » : il essayait d’inscrire dans l’en-tête plusieurs axes d’un régime de maîtrise de l’information.

Le bit de copie était activé. Lors d’une fragmentation, chaque fragment devait conserver l’option ; elle ne pouvait apparaître qu’une fois dans le datagramme. La fragmentation IPv4 ne devait pas devenir une échappatoire qui sépare les octets du contenu de leur contexte de sécurité.

RFC 791 distinguait aussi l’emploi et l’implémentation des options. Une option pouvait être absente d’un datagramme particulier, mais les modules IP étaient censés savoir la traiter. Le texte ajoutait que certains environnements pouvaient exiger l’option Security dans chaque datagramme. Le format universel du paquet réservait ainsi une place à une politique dont la nécessité dépendait du domaine.

Rien dans ce mécanisme ne garantissait l’intégrité cryptographique de l’étiquette. Un champ recopié sur tous les fragments peut toujours être faux. Il faut des sources fiables, des chemins protégés et des règles locales pour qu’il ait une portée contraignante.

Le même numéro a masqué deux ruptures de format

En 1988, RFC 1038 a transformé le type 130 en Basic Security Option de longueur variable. Les compartiments, restrictions et TCC du format fixe ont cédé la place à un niveau de classification et à des indicateurs d’autorité de protection. La continuité du numéro n’impliquait donc aucune continuité de disposition interne.

Cette nuance est décisive pour un analyseur. Reconnaître la valeur 130 ne suffit pas : la longueur et la spécification applicable déterminent le sens des octets suivants. Une capture interprétée avec le mauvais plan peut sembler plausible tout en attribuant aux bits des fonctions qu’ils n’ont jamais eues ensemble.

RFC 1038 présentait l’étiquette comme un moyen, pour des composants de confiance, de vérifier que la source pouvait transmettre les données, que la route et la destination avaient une protection suffisante et que plusieurs modèles de contrôle disposaient d’un langage commun. Ces capacités présupposaient cependant une infrastructure accréditée ; l’option seule ne créait aucune confiance.

RFC 1108 a ensuite rendu RFC 1038 obsolète et défini les options Basic et Extended. Le type 130 est resté celui du Basic Security Option, mais sa longueur minimale pouvait tomber à trois octets lorsque le champ Protection Authority était absent. L’identifiant stable couvre donc une histoire de remplacements, pas un format immuable.

Une classification conçue pour résister aux petites erreurs

Dans RFC 1108, le niveau de classification occupe un octet, mais ses valeurs valides sont dispersées. Des motifs précis correspondent à Top Secret, Secret, Confidential et Unclassified ; d’autres motifs de la table restent réservés. L’ordre numérique de ces octets n’est pas l’ordre de sensibilité.

Un programme ne peut donc pas décider qu’une valeur située arithmétiquement entre Confidential et Secret représente un niveau intermédiaire. Il doit comparer le motif à la table puis appliquer l’ordre défini par la spécification. Une plage numérique accepterait des codes non affectés et fabriquerait une sémantique inexistante.

Les valeurs valides ont été choisies avec une distance de Hamming minimale de quatre. Quelques inversions de bits ont ainsi moins de chances de transformer directement un niveau valide en un autre niveau valide. Il s’agit d’une propriété de détection d’erreur, pas d’une signature. Un expéditeur malveillant peut encore écrire intentionnellement un code valide.

Le choix révèle un principe : l’ordre politique réside dans un vocabulaire géré, non dans la grandeur d’un entier. Le logiciel doit connaître le référentiel ; il ne peut reconstruire l’autorité à partir de l’arithmétique.

Les autorités indiquaient des règles, pas des titres de confiance

Après la classification, RFC 1108 autorisait un champ Protection Authority de longueur variable. Les sept premiers bits de chaque octet étaient des indicateurs ; le bit de poids faible annonçait la présence d’un octet supplémentaire. Plusieurs autorités pouvaient donc s’appliquer au même datagramme, et une implémentation minimale devait savoir traiter au moins deux octets d’indicateurs.

Ces bits sélectionnaient les programmes dont les règles de protection concernaient l’information. La spécification soulignait qu’il ne s’agissait pas d’autorités d’accréditation. Le champ ne certifiait ni l’hôte ni l’utilisateur et ne conférait aucune habilitation.

L’encodage devait être minimal : un octet final entièrement nul n’avait pas sa place dans l’extension. La longueur annoncée devait aussi correspondre à la longueur réelle de l’option. Une chaîne incohérente était une erreur de protocole, pas une collection tolérable de badges inconnus.

La possibilité d’étendre les indicateurs renvoyait enfin à une gouvernance extérieure au paquet. Il fallait approuver et publier les affectations. Le datagramme transportait des références vers ces règles ; il ne pouvait ni les définir ni démontrer qu’elles avaient été appliquées.

L’interface, et non le seul hôte, fixait la frontière

RFC 1108 décrivait des paramètres généraux et des paramètres « per-port ». Ici, port désigne l’attachement réseau ou l’interface, pas un numéro TCP ou UDP. Une interface pouvait exiger BSO à l’émission, à la réception, dans les deux sens ou dans aucun.

Un système traitant des données classifiées devait en général produire une option explicite. Une exception existait pour les réseaux dédiés ou system-high : tous les paquets y recevaient le niveau implicite configuré sur l’interface. Lorsque la politique locale acceptait un paquet sans option, ce contexte remplaçait l’étiquette absente.

C’est précisément pourquoi l’effacement est dangereux. L’absence peut signifier trafic ordinaire sur une interface et trafic implicitement classifié sur une autre. Enlever l’indication explicite ne donne pas la valeur zéro ; cela active une autre source de classement.

À l’entrée, le système vérifiait d’abord que le code de classification était affecté. Il comparait ensuite le niveau avec le maximum de l’interface et contrôlait que les autorités étaient admises. À la sortie, le niveau devait se situer entre le minimum et le maximum configurés, et les indicateurs d’autorité rester dans l’ensemble autorisé.

Le paquet proposait un label. L’interface fournissait l’espace des labels acceptables. La décision naissait de cette rencontre, ce qui rend toute capture incomplète lorsqu’elle est détachée de la configuration de l’interface.

Même l’erreur dépendait du niveau de sécurité

Lorsqu’une interface exigeait BSO et recevait un paquet dépourvu de l’option, RFC 1108 prévoyait ICMP Parameter Problem avec le Code 1, réservé à l’option obligatoire manquante. Les étiquettes mal formées relevaient du message ordinaire ; un niveau hors plage pouvait mener à Destination Unreachable, administratively prohibited.

Ces réponses n’étaient que le comportement le moins restrictif autorisé. Une politique pouvait imposer un journal, avertir un responsable de sécurité ou interdire toute réponse. La classification de l’interface de sortie devait elle-même être respectée lors de l’envoi d’un diagnostic.

Il ne faut pas généraliser ce cas à toutes les options IPv4. Il décrit un système d’admission où répondre, garder le silence et étiqueter la réponse sont déjà des décisions de sécurité. Le code ICMP prouve ici que l’option participait à une obligation locale ; il n’est pas le sujet central de ce récit.

« Obsolète » pour l’ancien format, encore recommandé pour le routeur MLS

RFC 1122 qualifiait d’obsolètes les options de sécurité de RFC 791 et RFC 1038. Cela ne signifiait pas que tous les réseaux étiquetés avaient disparu. Pour les usages DoD, le texte dirigeait les implémenteurs vers la révision devenue RFC 1108.

RFC 1812 conservait cette distinction. Il répétait l’obsolescence des deux anciens formats, mais indiquait que les routeurs devraient mettre en œuvre la version révisée de RFC 1108. Les routeurs destinés à plusieurs niveaux de sécurité devaient pouvoir filtrer les labels IPSO.

Le modèle attribuait à chaque interface une borne inférieure et une borne supérieure. Un paquet en dehors de la plage devait être supprimé silencieusement, avec incrément d’un compteur. Ce n’était ni une liste de route ni une option de source routing : chaque frontière appliquait son propre test d’admissibilité.

Les statuts se superposent donc mal à une chronologie binaire. Un format ancien devient obsolète, son successeur reste une fonction conditionnelle de routeur, le document de ce successeur devient ensuite Historic, et le besoin opérationnel peut subsister dans une enceinte spécialisée.

Historic ne mesure pas le trafic réel

RFC 7126 estime que ces options ne devraient normalement pas apparaître sur l’Internet public mondial. Mais le même document signale leur usage dans des réseaux privés MLS, sur des systèmes commerciaux comme ouverts. Il juge même possible que le déploiement MLS — et donc IPSO — ait augmenté depuis le retrait de la voie Standards Track.

Une technologie peut donc reculer dans l’espace public tout en restant active, voire se développer, dans une enclave. Historic décrit le statut d’un RFC ; ce n’est ni un relevé de paquets, ni une certitude d’absence, ni une instruction de supprimer son numéro.

La difficulté pour le fabricant est que le même pare-feu peut être installé à la frontière d’Internet ou au milieu d’un réseau fermé. Le produit ne sait pas, avant configuration, si le type 130 est un résidu inutile ou une étiquette obligatoire. Le défaut doit laisser la décision à l’administrateur qui connaît le domaine.

Préserver par défaut ne veut pas dire faire confiance

RFC 7126 formule une recommandation conditionnelle : puisque supprimer ou bloquer BSO peut casser un réseau qui l’exige, alors que transporter l’option n’ajoute pas de dommage spécifique dans un réseau qui ne l’utilise pas, un équipement générique ne devrait pas la retirer ni rejeter un paquet pour sa seule présence.

Dans un environnement dont l’administrateur sait qu’il n’utilise pas IPSO, un rejet configuré reste possible. L’équipement devrait compter les paquets BSO par interface et permettre un filtrage tant sur la présence que sur les valeurs. La règle n’impose pas à l’Internet public de comprendre les classifications ; elle empêche une boîte intermédiaire de réécrire silencieusement leur sémantique.

Transmettre sans interpréter n’est pas valider. La confiance reste l’affaire de l’application de politique, tandis que la conservation évite de détruire une donnée dont un autre domaine peut légitimement dépendre.

Le TCP moderne a conservé la note de bas de page

RFC 9293 reflète cet héritage inconfortable. Les anciennes règles TCP pouvaient faire entrer les informations de sécurité et de compartiment IP dans le traitement d’une connexion. En 2022, RFC 1108 était Historic, mais RFC 791 n’avait pas été révisé pour retirer l’option Security.

La spécification moderne range donc le sujet dans ses notes d’implémentation. Les références au compartiment peuvent encore compter pour un système MLS et être ignorées dans une implémentation qui ne traite pas de MLS. Cette bifurcation vaut mieux qu’un comportement prétendument universel.

Le texte rappelle aussi que la réinitialisation d’une connexion lors d’un désaccord de compartiment ou de precedence a été reconnue comme vecteur d’attaque. Une donnée conçue pour renforcer l’admission peut devenir un levier d’interruption si une ancienne règle inter-couches s’exécute mécaniquement hors de son modèle de confiance.

Ce qu’une capture permet réellement d’affirmer

Voir le type 130 permet d’établir la présence d’octets dans un emplacement historiquement attribué. La longueur et l’organisation peuvent indiquer à quelle version le paquet semble se conformer. Un code RFC 1108 affecté et une extension d’autorité bien formée établissent une conformité structurelle.

Ils ne démontrent ni l’habilitation de l’émetteur, ni la véracité du label, ni la confidentialité de la charge utile, ni la protection du chemin, ni l’acceptation par l’interface suivante. Ces conclusions réclament des preuves sur la configuration, les attributions et les composants réels.

À l’inverse, l’absence n’établit pas toujours Unclassified : une interface à étiquette implicite peut attribuer localement un autre niveau. Sans la politique de cette interface, l’analyste ne peut reconstituer la décision complète.

La leçon durable du type 130 tient donc dans un verbe : retirer. Quand une métadonnée participe au contrôle d’accès obligatoire, son retrait est une transformation sémantique. Préserver une option inconnue peut être plus sûr que fabriquer, par effacement, une absence trompeuse.

Sources et limites de preuve

Le corpus fermé comprend RFC 791, RFC 1038, RFC 1108, RFC 1122, RFC 1812, RFC 7126 et RFC 9293. Ces textes établissent les formats, les traitements, les statuts et les conseils conditionnels. Ils ne révèlent pas les déploiements classifiés, ne mesurent pas le trafic actuel, ne vérifient aucun constructeur et ne prouvent la sincérité d’une étiquette observée.