Sécurité du routage : RPKI, MANRS
Déployer la validation d'origine RPKI et appliquer les normes MANRS pour réduire les risques de détournement de routes.
À retenir
- RPKI permet de signer cryptographiquement l'autorisation d'origine d'un préfixe via un ROA.
- L'Origin Validation classe les routes en Valid, Invalid ou NotFound selon les ROA publiés.
- MANRS formalise quatre actions : filtrage, anti-usurpation, coordination, validation globale.
- Un ROA trop restrictif peut invalider par erreur ses propres annonces légitimes.
Le problème que BGP ne résout pas nativement
BGP a été conçu sans mécanisme d'authentification de l'origine d'une route : n'importe quel AS peut, par erreur ou intentionnellement, annoncer un préfixe qui ne lui appartient pas (route hijack). Les incidents documentés (détournements affectant des préfixes de grands opérateurs) ont poussé la communauté à développer RPKI.
RPKI : ROA et validation d'origine
Le Resource Public Key Infrastructure (RPKI, RFC 6480) permet à un titulaire de ressources IP de signer cryptographiquement un ROA (Route Origin Authorization), déclarant quel AS est autorisé à annoncer un préfixe donné, avec une longueur maximale.
| État de validation | Signification | Action recommandée |
|---|---|---|
| Valid | ROA correspondant trouvé | Accepter |
| Invalid | ROA existant mais AS ou longueur non conforme | Rejeter |
| NotFound | Aucun ROA publié | Accepter avec prudence (dépend de la politique) |
Point clé
un routeur configuré en Origin Validation avec Local Preference réduite pour les routes "Invalid" (plutôt qu'un rejet strict immédiat) permet une transition progressive sans casser la connectivité en cas de faux positif de configuration ROA.
Mise en œuvre technique
La validation s'appuie sur un cache RPKI-to-Router (protocole RTR, RFC 8210) qui synchronise les données validées depuis les RIR (RIPE NCC, ARIN, APNIC, LACNIC, AFRINIC) vers les routeurs de bordure. Les opérateurs peuvent héberger leur propre validateur (Routinator, RPKI-client, OctoRPKI) ou utiliser un service managé.
Attention
un ROA mal configuré (longueur maximale trop restrictive) peut rendre "Invalid" ses propres annonces légitimes de préfixes plus spécifiques ; toujours tester en environnement de pré-production avant publication.
MANRS : quatre actions concrètes
Le programme MANRS (Mutually Agreed Norms for Routing Security) définit des actions mesurables pour les opérateurs réseau :
- Filtrage : empêcher la propagation d'annonces incorrectes vérifiées par préfixe et origine.
- Anti-usurpation : empêcher le trafic à adresse IP source usurpée de quitter le réseau (BCP38 / uRPF).
- Coordination : maintenir des informations de contact à jour (IRR, RPKI, PeeringDB).
- Validation globale : publier des informations permettant à des tiers de valider les annonces (ROA, IRR objects).
Sur le terrain
rejoindre MANRS impose un audit initial des pratiques de filtrage existantes ; c'est souvent l'occasion de découvrir des sessions BGP historiques sans aucun filtre de prefix-list appliqué, héritées de configurations jamais nettoyées.
Astuce
publiez vos ROA avec une longueur maximale égale à la longueur réellement annoncée (pas plus large) pour limiter la fenêtre d'exploitation en cas de détournement de sous-préfixe.
Conclusion
RPKI et MANRS ne remplacent pas une bonne hygiène de filtrage : ils la complètent en apportant une preuve cryptographique et un cadre de responsabilité partagée entre opérateurs.