ROA maxLength trop permissif : vos préfixes sont « valides »… et attaquables (RFC 9319)

Avoir des ROA et afficher « RPKI valid » partout ne suffit pas. Si vos ROA autorisent une maxLength plus longue que ce que vous annoncez réellement, vous avez signé un chèque en blanc à n'importe quel attaquant capable d'usurper votre numéro d'AS. Explication, vérification et correction en 30 minutes.

Le piège : « valid » ne veut pas dire « protégé »

Un ROA (Route Origin Authorization) déclare : « l'AS X est autorisé à annoncer le préfixe P, jusqu'à la longueur maxLength ». La validation d'origine (ROV) rejette les annonces dont l'origine ne correspond pas. Jusque-là, tout va bien.

Le problème naît quand la maxLength dépasse la longueur réellement annoncée :

C'est le forged-origin sub-prefix hijack. La validation d'origine seule ne peut pas le bloquer (elle ne vérifie pas le chemin, seulement l'origine déclarée). La seule défense côté titulaire de ressources : ne pas laisser d'espace annonçable entre ce que vous annoncez et ce que votre ROA autorise.

Ce que dit la RFC 9319 (BCP 185)

La RFC 9319, « The Use of maxLength in the RPKI », est une Best Current Practice co-signée notamment par des chercheurs à l'origine des mesures sur ce vecteur d'attaque. Ses recommandations tiennent en trois points :

1. ROA minimaux : la maxLength doit être égale à la longueur du préfixe effectivement annoncé (ou omise, ce qui revient au même).
2. Un ROA ne devrait couvrir que des préfixes réellement annoncés : un ROA sur un préfixe non annoncé est lui aussi exploitable en forged-origin.
3. Les exceptions (ingénierie de trafic, protection DDoS avec annonce de sous-préfixes à la demande, agrégation) doivent être délibérées et documentées, pas un réglage par défaut.

Vérifier vos ROA en 1 minute

Notre vérificateur gratuit analyse l'ensemble des préfixes annoncés par votre ASN et signale, préfixe par préfixe, ceux qui sont couverts par un ROA dont la maxLength dépasse la longueur annoncée — en plus de la couverture RPKI globale, de la visibilité BGP et des objets IRR.

Corriger : ~30 minutes dans le portail de votre RIR

Pour les ressources RIPE NCC (le cas le plus courant en Europe) :

1. Listez vos annonces réelles (votre vérification ci-dessus vous donne la liste exacte).
2. Dans my.ripe.net → Resources → RPKI Dashboard, créez un ROA par préfixe réellement annoncé, maxLength = longueur annoncée.
3. Vérifiez que toutes vos annonces existantes sont couvertes « valid » par les nouveaux ROA avant de supprimer les anciens : aucune coupure possible dans cet ordre.
4. Si vous utilisez des sous-préfixes pour l'ingénierie de trafic ou l'anti-DDoS, créez des ROA explicites pour ces sous-préfixes précis plutôt qu'une maxLength large.

FAQ

Une maxLength large, c'est parfois légitime ?
Oui : annonce de sous-préfixes à la demande (scrubbing DDoS), ingénierie de trafic. La RFC 9319 ne l'interdit pas, elle demande que ce soit un choix délibéré, limité aux préfixes concernés, et de préférence couvert par des ROA explicites par sous-préfixe.

Mon ROA couvre un préfixe que je n'annonce pas, c'est grave ?
C'est le même vecteur : un attaquant peut annoncer ce préfixe (ou ses sous-préfixes selon la maxLength) en forgeant votre origine, et l'annonce sera « valid ». La RFC 9319 recommande de ne créer des ROA que pour ce qui est annoncé.

ASPA ou BGPsec règlent-ils le problème ?
À terme, la validation de chemin (BGPsec) et ASPA compliquent sérieusement le forged-origin. En attendant leur déploiement large, les ROA minimaux restent la défense concrète, disponible aujourd'hui, et c'est ce que mesure notre vérificateur.