Summary

  • La RFC 1108 définissait le type 133 comme un conteneur répétable de labels supplémentaires, chaque code de format relevant d’une spécification propre.
  • Toute option étendue exigeait la présence de l’option de sécurité de base; retirer l’extension pouvait provoquer un rejet ou attribuer aux données une sensibilité erronée.

Une enveloppe stable, des significations déléguées

L’Extended Security Option (ESO), option IPv4 de type 133, avait une longueur variable d’au moins trois octets et comportait un code de format des informations de sécurité supplémentaires. Le reste du champ suivait la syntaxe désignée par ce code et pouvait même être vide si la définition correspondante le permettait.

La délégation n’était pas un blanc-seing. Pour chaque code enregistré, une RFC devait fournir une syntaxe et une procédure algorithmique d’acceptation ou de rejet assez précises pour permettre des implémentations interopérables. Seule la correspondance avec des libellés humains pouvait rester non publiée si sa diffusion devait être restreinte.

L’ESO pouvait apparaître plusieurs fois, sous la limite générale de taille de l’en-tête IPv4, et devait être copiée dans les fragments. Pourtant, elle ne pouvait jamais voyager seule : la présence de la Basic Security Option (BSO) était obligatoire. Une ESO sans BSO, un code non enregistré, une longueur incohérente ou un contenu contraire à sa RFC constituaient des erreurs, pour lesquelles RFC 1108 prévoyait le traitement ICMP Parameter Problem.

La prise en charge pouvait être sélective. Un système pouvait comprendre la BSO sans aucune ESO, ou seulement certains codes étendus. Les bits d’autorité de protection de la BSO n’avaient d’ailleurs aucun rapport numérique avec les codes de format ESO. Deux espaces de contrôle voisins devaient être coordonnés sans être confondus.

Enfin, le routage fondé sur ces labels réclamait que les protocoles de routage transportent eux aussi les informations nécessaires. Le paquet exprimait une exigence; les paramètres des ports, la liste des formats reconnus et l’état des routes décidaient si le réseau pouvait y répondre.

Pourquoi retirer l’option n’était pas neutre

La RFC 7126 a relevé un usage dans certains réseaux privés de haute sécurité. Elle a surtout décrit le coût d’une suppression : le destinataire pouvait rejeter un paquet devenu mal étiqueté, ou lui associer un niveau de sensibilité incorrect, vers le haut comme vers le bas.

Comme un équipement ne sait pas d’avance dans quel environnement il sera installé, la recommandation par défaut était de ne pas retirer l’ESO et de ne pas rejeter un paquet pour sa seule présence. Un opérateur sachant que son domaine ne l’utilise pas pouvait néanmoins configurer le filtrage, avec une capacité de journalisation.

Les sources ne donnent ni part de déploiement actuelle, ni inventaire contemporain des codes, ni comportement universel des produits. Elles montrent plutôt qu’un point d’extension transforme la coordination : il la déplace vers un registre, des RFC spécialisées et une configuration durable.

Sources