Résumé
- Avec le RPF strict, un paquet légitime peut être rejeté si l’interface d’arrivée n’est pas celle que la meilleure route de retour vers son adresse source emprunterait.
- Le RPF faisable accepte des itinéraires alternatifs connus, sous réserve qu’ils soient propagés de façon cohérente ; le RPF lâche tolère l’asymétrie, mais abandonne une grande partie de la preuve directionnelle.
Le routeur a jugé le chemin du retour
Un site est connecté à deux fournisseurs. Un paquet part par le second, avec une adresse source que le site est autorisé à utiliser. Plus loin, un routeur le reçoit sur l’interface de ce fournisseur. Il consulte sa table et voit que le meilleur chemin de retour vers cette adresse passe par le premier fournisseur. Le RPF strict le rejette. Le routeur n’a pas identifié l’émetteur : il a comparé l’interface d’arrivée à sa propre vue du routage.
La RFC 3704, publiée en mars 2004 comme BCP 84, actualise la recommandation BCP 38 de la RFC 2827. Elle maintient l’objectif du filtrage à l’entrée — limiter l’usurpation d’adresses — tout en prenant au sérieux les réseaux multiraccordés et les chemins asymétriques. Le chemin réellement emprunté dans un sens n’est pas forcément celui que le routeur choisirait dans l’autre.
Le document distingue plusieurs méthodes. Une liste de préfixes par interface est déterministe, mais une liste maintenue à la main peut devenir obsolète après un changement de fournisseur ou d’adressage. Le RPF strict rend le contrôle dynamique : l’adresse source est recherchée dans la FIB et le paquet passe seulement si l’interface d’arrivée correspond à l’interface de la meilleure route. Simple à déployer sur un bord symétrique, cette règle peut aussi écarter un trafic légitime si la route est asymétrique, manquante ou filtrée par la politique d’un opérateur.
Accepter plus de chemins ne les rend pas tous plausibles
Le RPF faisable ajoute au test des chemins alternatifs conservés dans une table de routage ou une table dédiée. Il peut ainsi éviter qu’un paquet valide soit rejeté uniquement parce qu’un autre itinéraire est momentanément préféré. Mais cette liste n’est pas universelle : la RFC 3704 exige une diffusion cohérente des annonces pertinentes vers tous les routeurs qui contrôlent les paquets. Si une politique ou une route-map écarte un préfixe chez un fournisseur, le filtre peut écarter le paquet correspondant.
Le RPF lâche pousse le compromis dans l’autre sens. Il demande s’il existe une route vers la source, non si elle pointe vers l’interface d’arrivée. Un paquet dont l’adresse a été usurpée mais demeure routable peut donc satisfaire le test. Une route par défaut rend le critère encore moins exigeant si l’implémentation ne la traite pas explicitement. La RFC déconseille d’en faire le filtre principal entre un client et son fournisseur ; elle lui voit plutôt un rôle contre les préfixes non routés en amont ou comme vérification d’un engagement de filtrage par un autre réseau.
Les autres solutions font apparaître le travail de coordination : s’assurer que chaque fournisseur connaît les préfixes du client, parfois au moyen d’adresses indépendantes du fournisseur et de BGP ; diriger les préfixes attribués par un fournisseur uniquement vers celui-ci ; ou générer des listes à partir des bases de données clients. Le choix déplace le travail entre routeurs, opérateurs et clients. Il ne transforme pas une route en preuve d’identité.
La RFC 3704 rappelle enfin que la vérification la plus précise se fait près de la source. Plus loin dans le réseau, un routeur peut seulement établir qu’une adresse pourrait appartenir à un préfixe joignable. Le filtrage en plusieurs points améliore la traçabilité, sans prouver l’identité d’un attaquant ni la couverture réelle de tout l’Internet. La RFC 8704, publiée en 2020, met à jour la RFC 3704 avec un RPF faisable renforcé ; son existence signale que le compromis restait à travailler, pas que chaque réseau l’a déployé.
La leçon durable n’est donc pas de choisir partout le mode « strict » ou « lâche ». Il faut demander ce que chaque contrôle sait réellement : la meilleure route de retour, un ensemble d’alternatives ou seulement l’existence d’une route. Le verdict dépend aussi de la table consultée et du point où le paquet entre. RFC 3704 fait de la complétude des routes une responsabilité partagée.
Sources
- RFC 3704 : Ingress Filtering for Multihomed Networks
- Notice RFC 3704 — RFC Editor
- RFC 3704 — IETF Datatracker
- Historique RFC 3704 — IETF Datatracker
- RFC 2827 : Network Ingress Filtering
- Notice RFC 2827 — RFC Editor
- RFC 8704 : Enhanced Feasible-Path uRPF
- Notice RFC 8704 — RFC Editor
- RFC 2260 : Multi-homing multi-fournisseur
- RFC 8028 : sélection du routeur de premier saut
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
