Résumé

  • La RFC 10078 distingue la joignabilité d’un préfixe de l’autorisation donnée à un client d’émettre avec ses adresses.
  • uRPF strict peut jeter du trafic légitime lorsque le chemin est asymétrique ou que le préfixe est invisible dans le routage interne. uRPF loose évite le contrôle d’interface, mais peut laisser passer une source usurpée présente dans la table locale.

Un client envoie un paquet depuis une adresse qu’il est autorisé à utiliser. Le routeur consulte sa table de transfert : le préfixe pointe ailleurs, ou n’y figure pas. Le paquet est supprimé. Le routeur a répondu à une vraie question. Ce n’était pas la bonne.

C’est le décalage décrit par la RFC 10078, publiée par l’IETF en octobre 2026 à titre informatif. Le texte traite de la validation des adresses source (SAV) à l’intérieur d’un système autonome, sur les interfaces externes tournées vers des hôtes ou des réseaux clients qui ne sont pas des AS voisins. Le client peut ne pas avoir d’ASN. Il peut utiliser des préfixes attribués par l’opérateur ou apporter les siens.

La forme stricte de l’Unicast Reverse Path Forwarding (uRPF) vérifie deux choses dans la base d’information de transfert (FIB) : un préfixe couvre-t-il l’adresse source, et la route correspondante repart-elle par l’interface d’arrivée ? Ce test suppose que les chemins aller et retour se ressemblent. Un client multiraccordé peut envoyer par le routeur 1 alors que le réseau de l’opérateur prévoit le retour par le routeur 2. uRPF strict transforme cette différence en motif de rejet. Dans l’exemple de la RFC, le trafic légitime du client disparaît.

La variante loose supprime le contrôle de l’interface. La présence d’un préfixe couvrant dans la FIB suffit. Certains flux asymétriques passent alors, mais une source usurpée peut aussi passer dès que son préfixe figure dans la table. Le mode strict confond le chemin de retour avec un droit d’usage ; le mode loose confond la joignabilité générale avec ce droit.

Les préfixes cachés compliquent encore le filtre. Un hôte ou un client peut émettre légitimement depuis une adresse que le protocole de routage interne de l’opérateur ne connaît pas. La RFC cite le Direct Server Return (DSR) : une requête arrive sur un site de service anycast, puis un autre serveur en périphérie répond directement en utilisant l’adresse du service comme source. Un espace client non annoncé dans le réseau interne produit le même décalage. Quand le préfixe manque à la FIB, les deux variantes d’uRPF peuvent jeter le paquet.

Une liste de contrôle d’accès peut nommer les préfixes autorisés, à condition que quelqu’un suive les changements d’autorisation et mette les règles à jour.

La RFC donne cinq critères aux futurs mécanismes : améliorer la précision ; recueillir et actualiser automatiquement les informations SAV ; permettre un déploiement progressif sur une partie des interfaces concernées ; préserver la convergence et le fast reroute si ces informations sont distribuées par protocole ; enfin, utiliser des informations authentifiées ou fiables. Le registre manquant n’est donc pas une route de plus, mais une autorisation d’usage de source que le routeur peut vérifier et tenir à jour. La FIB décrit la joignabilité.

Lui demander de jouer aussi le rôle de registre des droits du client est commode jusqu’au premier désaccord.

La RFC 10078 ne définit ni ce registre, ni le protocole de diffusion, ni une solution achevée. Elle expose un problème et des exigences. Le test opérationnel est à portée de main : envoyer du trafic légitime par un chemin asymétrique et depuis un préfixe caché, puis essayer des sources usurpées présentes ou absentes de la FIB. Pour chaque décision, relever la règle, l’autorité qui a fourni l’information, sa propagation jusqu’au bord et son comportement lors d’un changement de route.

Sources