Résumé

  • L’uRPF strict peut bloquer un trafic asymétrique légitime, tandis que l’uRPF lâche perd la directionnalité ; la RFC 8704 définit des listes de chemins plausibles propres à chaque interface.
  • La méthode dépend de la qualité des routes BGP, des filtres de préfixes et des relations commerciales. Elle n’authentifie ni un contrat client ni un déploiement réel.

Analyse

La validation d’adresse source pose une question simple en apparence : ce paquet pouvait-il légitimement entrer par cette interface ? Sur un accès unique, la table de transfert donne souvent une réponse nette. Avec plusieurs fournisseurs, le chemin choisi au retour peut différer du chemin d’arrivée. La direction reste une preuve, mais le meilleur chemin ne constitue pas toute l’autorisation.

Le BCP 38 a établi l’objectif du filtrage entrant : arrêter près de l’origine les paquets portant une adresse source usurpée et rendre les abus plus traçables. La RFC 3704 décrit plusieurs moyens. L’uRPF strict consulte la FIB et exige que l’interface d’arrivée soit aussi celle du chemin retour sélectionné. Le mécanisme est fort lorsque les chemins sont symétriques, mais peut supprimer du trafic valide quand le multihoming ou la politique crée une asymétrie.

L’uRPF lâche évite ces faux positifs en vérifiant seulement l’existence d’une route vers la source. Il abandonne alors l’essentiel de la directionnalité : une source joignable quelque part dans la table peut rester invraisemblable sur l’interface observée.

La RFC 8704 modifie ce compromis. Elle définit pour chaque interface une liste RPF de préfixes source admissibles. L’algorithme A étend cette liste au-delà du seul meilleur chemin sans l’ouvrir à toute la table. Si le routeur reçoit sur une interface une route issue d’un AS d’origine, d’autres préfixes convenablement contrôlés de cet AS peuvent devenir plausibles sur la même interface.

Cette extension reste conditionnelle. La RFC suppose que les routes ont déjà subi un filtrage de préfixes et, le cas échéant, une validation d’origine. Une route reçue de la mauvaise partie ne devient pas fiable parce qu’un algorithme peut l’inscrire dans une liste RPF. La solidité de l’ensemble dépend donc des entrées de routage et de l’interprétation de l’adjacence.

Pour des topologies client-fournisseur difficiles, l’algorithme B peut étendre l’admission à un cône client identifié. Il couvre davantage de sources légitimes, mais dépend plus fortement d’une connaissance exacte des relations. Un cône obsolète ou un pair mal classé élargit la frontière au-delà du contrat.

Les ROA et les données IRR peuvent compléter les listes. Elles améliorent l’association entre préfixe et origine, sans prouver à elles seules qu’une interface précise est autorisée. L’autorisation d’origine et l’autorisation d’interface sont deux affirmations distinctes.

Le coût opérationnel est tangible : état RPF plus volumineux, mises à jour pendant les transitions BGP, observation des rejets et gestion des exceptions. Aucune source de ce dossier ne prouve une prise en charge universelle, un déploiement nommé ou une réduction mesurée des faux positifs.

Le groupe SAVNET de l’IETF confirme que le problème reste ouvert : les mécanismes actuels peuvent admettre du trafic usurpé ou bloquer du trafic valide. Sa charte décrit des travaux futurs, pas une solution déjà déployée.

Sources