Résumé

  • Le 3 septembre 2026, l’IESG a ouvert le Last Call sur la version 16 de Segment Routing IPv6 Security Considerations, avec des commentaires attendus avant le 17 septembre. Le texte vise un RFC informatif ; il n’est ni approuvé ni publié.
  • La présence d’un SRH ne définit pas l’entrée dans SRv6. Un SID peut être traité sans SRH, tandis qu’un SRH peut simplement traverser le domaine. La confiance dépend d’un contrat d’adresses et de contrôles effectivement appliqués.

Le mot « domaine » invite à dessiner une enceinte. La version 16 refuse cette facilité. Son domaine de confiance est logique et opérationnel : une machine branchée au même réseau physique n’y appartient pas sans être soumise aux contrôles. Deux instances SR administrées par la même entreprise peuvent rester étrangères l’une à l’autre.

Cette distinction devient concrète au bord. La recherche d’un SRH semble naturelle parce que cet en-tête porte une liste de segments. Mais le traitement d’un SID n’exige pas toujours cet en-tête ; une adresse IPv6 de destination peut, seule, sélectionner le segment. À l’inverse, un paquet muni d’un SRH peut être un transit légitime qui ne termine pas dans ce domaine. Bloquer le signe visible produit donc à la fois des angles morts et des ruptures d’interopérabilité.

Le projet recentre le contrôle sur deux ensembles : les destinations réservées aux SID et les sources autorisées comme internes. À l’entrée, tout paquet externe destiné à un SID du domaine doit être rejeté. Sur chaque nœud SRv6, un second contrôle rejette les paquets vers un SID local dont la source n’appartient pas au domaine. La redondance n’est pas décorative. Elle permet au contrôle du nœud de contenir une erreur du bord.

Si les deux étages manquent, le système échoue en mode ouvert. Des attaques que le modèle limitait à un acteur interne peuvent alors devenir accessibles depuis l’extérieur. Une règle écrite ne suffit donc pas : il faut connaître la version réellement chargée, les interfaces auxquelles elle s’applique et le comportement lorsque la plateforme ne peut pas l’exprimer.

L’adressage simplifie ou complique cette preuve. Le bloc dédié par RFC 9602 rend les SID plus faciles à reconnaître et à filtrer. Il n’est pas une barrière magique et son emploi n’est pas universel. Des préfixes dispersés restent possibles, mais ils allongent les listes, rendent les fuites moins visibles et augmentent la probabilité d’une erreur humaine.

L’encapsulation à l’entrée apporte un reçu de provenance : l’en-tête externe et le SRH éventuel sont imposés par un nœud de confiance, plutôt que repris d’une interface hostile. Elle ne remplace pourtant pas le filtrage. Une classification erronée au bord peut encore donner à une source externe les formes attendues par le domaine.

Le HMAC du SRH possède une portée différente. Il protège plusieurs champs et la liste des segments à l’aide d’une clé partagée, mais il reste optionnel. La distribution manuelle favorise parfois la réutilisation des clés ; une trame valide peut être rejouée durant leur vie ; Segments Left n’est pas couvert. Un HMAC valide atteste certains octets, pas l’autorisation d’entrer, la fraîcheur ni l’innocuité du résultat.

Les équipements intermédiaires doivent ensuite comprendre le mouvement de l’adresse active. Un pare-feu ignorant SRv6 peut prendre l’adresse du segment courant pour la destination finale et séparer à tort les deux sens d’un même flux. Rejeter tous les en-têtes d’extension casserait le routage de type 4 dans le domaine, sans arrêter le paquet sans SRH destiné à un SID.

La dernière limite est matérielle. Les ACL consomment des tables TCAM parfois partagées avec les routes, VLAN et adresses MAC. Une politique complète sur papier peut dépasser la profondeur d’analyse ou la place disponible. Si l’équipement accepte ce qu’il ne peut classifier, la frontière disparaît sans modification du document de politique.

La méthode de Heng Lu impose alors quatre reçus : la norme proposée, la configuration attendue, l’état chargé dans les équipements et le paquet observé. Le Last Call ne commande aucun de ces déploiements. Il rend seulement plus précise la question que l’exploitant doit prouver.

Sources

  1. Annonce du Last Call par l’IESG
  2. Version 16 du projet SRv6
  3. Fiche Datatracker
  4. RFC 8402 : architecture Segment Routing
  5. RFC 8754 : en-tête SRH
  6. RFC 8986 : programmation SRv6
  7. RFC 9602 : bloc dédié aux SID
  8. RFC 9288 : filtrage des en-têtes d’extension
  9. RFC 7872 : mesures des pertes liées aux en-têtes
  10. RFC 8200 : IPv6
  11. RFC 9098 : sécurité des en-têtes IPv6
  12. RFC 9099 : sécurité opérationnelle IPv6
  13. RFC 9259 : OAM dans le SRH
  14. RFC 4381 : pratiques du domaine de confiance
  15. RFC 3552 : rédaction des considérations de sécurité
  16. Heng Lu : primauté du code exécuté
  17. Heng Lu : spécification initiale minimale
  18. Heng Lu : couches de réalité