Résumé

  • Pour draft-ietf-spring-srv6-security-16, un domaine de confiance est un domaine SR où l’hypothèse de filtrage aux frontières est effectivement appliquée. Il s’agit d’une construction logique et opérationnelle, non physique.
  • Plusieurs instances SR peuvent dépendre de la même entité administrative tout en restant distinctes. Propriété commune, colocalisation et marque unique ne prouvent donc pas une confiance commune.
  • L’application peut échouer en mode ouvert à cause d’une modification erronée ou des limites matérielles. La seule présence d’un SRH ne suffit pas à définir le bon filtre.
  • Un manifeste de frontière et reçu d’application devrait relier membres, plages, clés, règles voulues et installées, capacité et essais négatifs. C’est une proposition de Daniel Kade, pas une obligation IETF.

La fusion juridique n’efface pas le filtre

Deux infrastructures SRv6 ont été conçues séparément. Elles possèdent des plans de SID différents, deux autorités de contrôle, des clés propres et des pratiques d’exploitation qui ne coïncident pas. Puis leur propriétaire change. Sur la carte destinée à la direction, un grand rectangle remplace les deux anciens. La semaine suivante, le passage filtré entre les infrastructures est rebaptisé « liaison interne ».

Ce changement de vocabulaire peut précéder de très loin le changement de sécurité. Un nœud admis dans le premier ensemble n’a pas nécessairement le droit d’imposer un chemin dans le second. Les plages d’adresses peuvent se recouvrir ou être filtrées selon des hypothèses différentes. Une politique annoncée peut ne pas tenir dans les ressources du matériel. Le fait que la même société paie les factures ne répond à aucune de ces questions.

La révision 16 de Segment Routing IPv6 Security Considerations établit une distinction utile. Elle reprend de RFC 8402 l’hypothèse d’un fonctionnement dans un domaine de confiance avec filtrage à la frontière. Mais elle précise que ce domaine est logique et opérationnel. Des serveurs branchés au même réseau physique n’en font pas partie tant qu’ils n’ont pas été explicitement soumis à ses contrôles.

Le texte vise aussi le cas institutionnel : plusieurs instances SR sous une même entité administrative peuvent demeurer distinctes sur le plan logique ou opérationnel. Pour son modèle de menace, un trafic venant d’un autre domaine de confiance est externe. Ainsi, « même propriétaire » ne constitue pas un justificatif technique de confiance.

Un document en Last Call ne certifie aucun réseau

L’IESG a ouvert le Last Call de la révision 16 le 3 septembre 2026, avec une date limite de commentaires au 17 septembre. Au point d’arrêt de cette recherche, le 9 septembre, Datatracker indiquait encore un Internet-Draft actif du groupe SPRING, destiné au statut Informational. Aucun téléchat n’était fixé, et l’état du groupe signalait qu’une nouvelle révision restait nécessaire à la suite d’un point soulevé pendant le dernier appel du groupe.

Ces détails empêchent de transformer un texte de travail en verdict. La date du 17 septembre n’est pas une approbation future déjà acquise. La révision 16 n’est ni un RFC ni une attestation de conformité. Elle affirme d’ailleurs ne définir aucun nouveau protocole ou prolongement de sécurité.

RFC 8402 fournit la règle de fond : Segment Routing opère par défaut dans un domaine de confiance et le trafic doit être filtré aux limites. Il suppose aussi qu’un nœud ajoutant une pile de segments ou un SRH est autorisé à le faire. Cette délégation est puissante. Elle ne reste raisonnable que si la liste des nœuds admis et les contrôles des frontières correspondent à la réalité.

Une restructuration peut transférer le budget et les contrats sans modifier cette réalité. À l’inverse, deux équipes peuvent harmoniser leurs contrôles avant toute fusion juridique. L’événement qui compte est l’unification vérifiée de l’autorité et de l’application, pas la date d’un communiqué.

Le mot « confiance » désigne un travail permanent

La révision 16 reconnaît que le modèle est difficile à faire vivre. Des filtres parfaitement construits doivent rester corrects sur chaque bord. Une règle supprimée ou ajustée par erreur peut laisser passer un trafic entrant ou exposer des informations en sortie. Certains équipements manquent de capacité, de complexité de correspondance ou de prise en charge protocolaire pour exprimer la politique prévue.

Le domaine peut alors échouer en mode ouvert. Une attaque que le modèle réservait à un acteur déjà présent à l’intérieur peut devenir accessible depuis l’extérieur, non parce que l’architecture a changé sur le papier, mais parce qu’un composant n’applique plus le filtre qui définissait la frontière.

Il faut donc conserver trois preuves. La première décrit les membres autorisés : nœuds, sources, contrôleurs et rôles. La deuxième décrit l’intention : points d’entrée et de sortie, plages de SID, sources admises, exceptions. La troisième constate l’exécution : règles installées, capacité restante, compteurs et résultats d’essais.

Une validation de configuration ne réunit pas forcément les trois. Elle peut confirmer la syntaxe d’une demande sans montrer que chaque équipement l’a acceptée, qu’une table n’était pas pleine, que la règle a survécu au redémarrage et qu’un paquet extérieur a bien été rejeté.

L’intégration de deux parcs augmente les écarts possibles. L’un réserve une plage claire pour ses SID; l’autre utilise une allocation plus difficile à filtrer. L’un encapsule à l’entrée; l’autre traite davantage de champs reçus. L’un dispose d’une marge matérielle; l’autre partage ses tables de contrôle avec de nombreuses fonctions. Un logo commun ne normalise aucune de ces propriétés.

Le SRH ne fournit pas un test universel

Il serait tentant de résumer la frontière à une règle : détecter un SRH. Le projet explique pourquoi cela ne suffit pas. Le traitement d’un SID peut se produire sans SRH. À l’inverse, un paquet muni d’un SRH peut seulement traverser le domaine sans lui être destiné. Un blocage général manquerait certains cas et casserait un transit légitime.

La relation entre destination, source et domaine est plus importante. À l’entrée, le texte décrit le rejet d’un trafic extérieur destiné à un SID interne. Sur chaque nœud SRv6, un paquet visant un SID local et provenant d’une source située hors du domaine doit aussi être rejeté. La perte simultanée de ces deux niveaux crée précisément le risque d’ouverture.

Ces règles supposent un inventaire fiable des plages d’infrastructure. RFC 9602 rend disponible un préfixe consacré aux SID SRv6; la révision 16 souligne que des choix différents peuvent compliquer le filtrage et accroître le risque d’erreur ou de fuite de route. Lors d’une fusion, conserver deux plans de SID peut être parfaitement légitime. Il faut alors conserver aussi deux limites intelligibles.

L’encapsulation constitue une mesure distincte. Le nœud d’entrée peut créer une nouvelle enveloppe IPv6 et un SRH, évitant que les décisions internes reposent sur des champs fournis par une source non fiable. Mais cette protection complète le filtrage; elle ne l’abolit pas. Un trafic capable de satisfaire les critères de frontière demeure à examiner.

Une machine peut héberger deux domaines de clés

Le HMAC ne transforme pas davantage la propriété en confiance. Le TLV HMAC de RFC 8754 est facultatif et protège certains éléments du SRH. La révision 16 avertit que la configuration manuelle de clés prépartagées favorise parfois leur réutilisation. Elle demande surtout de ne pas employer la même clé dans deux domaines de confiance différents, y compris lorsque ces domaines existent sur le même nœud.

Cette précision contredit directement une vision physique du périmètre. Un châssis unique peut servir deux instances dont les autorités demeurent séparées. La clé doit refléter cette séparation.

La vérification d’un HMAC a aussi une portée limitée. Un nœud légitime compromis et détenteur de la clé reste un attaquant interne selon le modèle. Un acteur interne privé de la clé peut rejouer pendant sa durée de validité un SRH et un HMAC capturés. La cryptographie fournit une propriété précise; elle ne décide pas à elle seule qui devrait pouvoir imposer quelle instruction de routage.

Réutiliser une clé à l’échelle du groupe produit un résultat trompeur : les paquets se vérifient, donc l’intégration paraît réussie, alors que l’autorité s’est étendue sans décision traçable. La séparation ultérieure devient aussi plus coûteuse.

Donner une identité vérifiable à chaque frontière

Un opérateur devrait maintenir un manifeste de frontière de domaine de confiance, accompagné d’un reçu d’application à chaque changement. Ce mécanisme n’a pas besoin de modifier SRv6. Il sert à empêcher qu’un seul indicateur « interne » remplace plusieurs faits indépendants.

Le manifeste attribue un identifiant versionné au domaine. Il énumère les nœuds et rôles admis, les points d’entrée et de sortie, les plages de SID et de sources, les autorités de contrôle, les points d’encapsulation et les identifiants de domaines de clés — jamais les secrets eux-mêmes. Chaque passage vers un autre domaine possède un responsable, un motif et une échéance.

Le reçu relie ensuite l’intention approuvée aux règles annoncées comme installées sur chaque équipement. Il conserve la capacité disponible, les compteurs pertinents, un essai négatif depuis l’extérieur, un essai autorisé depuis l’intérieur et toute exception. Un changement de topologie, de logiciel, de matériel, de plage ou de clé rend le reçu ancien ou impose son renouvellement.

Ce registre ne promet pas une sécurité absolue. Il produit une affirmation plus honnête que « tout appartient au même opérateur » : telle révision de domaine a été testée à telles frontières, avec telles plages, sur tels équipements, à telle date, et voici ce qui reste imparfait.

The Policy Mirror invite à chercher où la règle produit réellement ses effets. Ici, elle est répartie entre membres, adresses, filtres, enveloppes et clés. Running-Code Primacy exige de constater cette exécution. Reality, Not Advocacy borne la conclusion : le projet IETF ne dénonce aucun opérateur et ne règle pas l’interdomaine. Il montre pourquoi la propriété commune ne suffit pas à fabriquer une confiance commune.

Sources