R. Bush (Internet Initiative Japan)January20142014-01-15
Le mécanisme de sécurisation des annonces de route pour
BGP, connu sous le nom de RPKI+ROA, est normalisé
depuis un an et il existe désormais un peu d'expérience
opérationnelle. Que nous enseigne-t-elle ? Peut-on commencer à définir
des « bonnes pratiques » de déploiement et de fonctionnement de la
RPKI ?
Outre la publication des normes sur RPKI+ROA, comme le , il existe plusieurs logiciels permettant de mettre en
œuvre ces normes. On trouve encore peu de comptes-rendus d'expérience
concrète avec la RPKI. En français, je vous recommande fortement
l'excellent mémoire de master de Guillaume Lucas. Il
faut dire qu'on en est encore aux débuts (ce qui explique la faible
taille de ce nouveau RFC). Par exemple, il n'existe
toujours pas de point de départ (trust anchor)
unique pour la validation, chaque RIR ayant son
propre certificat, chacun étant une racine pour la validation. Le
RFC estime qu'une racine unique finira par
apparaître, ce dont je doute fort, en raison des nombreux conflits
de gouvernance à ce sujet.
Notre nouveau RFC, ce , a une vision très
optimiste : il affirme même que, déployée intelligemment et prudemment, RPKI+ROA
entraînera peu de perturbations du système de
routage de
l'Internet. L'expérience récente de
DNSSEC semble pourtant indiquer le contraire, à
savoir qu'il n'est pas trivial de déployer de la sécurité
cryptographique et qu'on casse parfois quelque chose en le faisant. À
moins que les gens de BGP soient bien plus compétents que ceux du
DNS ?
Bon, assez de généralités, place aux recommandations
concrètes. N'oubliez pas d'abord de lire les RFC RPKI+ROA. Puis,
attaquons la section 3, le cœur de ce nouveau RFC. La
RPKI est la base de données répartie () stockant
les autorisations de routage (les ROA, ), les certificats (), les
révocations, les enregistrements Ghostbuster (), etc. Elle a été conçue pour être distribuée de
manière hiérarchique, des dépôts mondiaux nourrissant des dépôts
plus locaux qui à leur tout nourriraient des dépôts très locaux. En
pratique, cela ne semble pas encore très fréquent : l'architecture la
plus courante semble être encore à deux étages, le dépôt du RIR et
celui de l'opérateur. Notez qu'on peut parfaitement utiliser des
dépôts et des caches validateurs situés dans un autre réseau que le
sien, par exemple chez son transitaire : si on
lui fait confiance pour router les paquets, on peut bien lui faire
confiance pour gérer la RPKI, et s'appuyer sur son travail.
Le cache validateur, dans le réseau de
l'opérateur, collecte toutes les données de la RPKI (en utilisant
rsync) et les valide en utilisant un logiciel
comme rcynic ou le validateur du
RIPE-NCC. Les routeurs
qui font confiance à ce cache
iront alors chercher ces informations sur la validité des routes
(typiquement en utilisant le protocole RTR du ), sans avoir à faire de crypto eux-mêmes. Cela impose
que les routeurs soient configurés uniquement avec des adresses de
caches validateurs de confiance. Et que la connexion entre le routeur
et le cache soit bien sécurisée, par exemple par
SSH, particulièrement si le cache validateur
est dans un AS différent. Pour des raisons de résilience, le cache
doit être joignable sans avoir besoin de ressources extérieures, comme
le DNS ou comme la RPKI elle-même (si le
routeur devait valider la route vers le cache, on aurait un beau
problème de bootstrap). Il
vaut sans doute mieux que les routes entre le routeur et le cache
validateur ne dépendent pas du tout de BGP. Et, toujours pour la
résilience, un routeur devrait utiliser plusieurs caches (comme une
machine a plusieurs résolveurs DNS).
La validation dans la RPKI est arborescente : on part d'un
certificat d'une autorité de confiance, le TAL (Trust Anchor
Locator, cf. et, oui, je
simplifie parce que le TAL est en fait un pointeur vers le
certificat), et on valide récursivement les
certificats des titulaires de ressources (adresses IP, par exemple) à
partir de ces TAL. Si le gérant d'un cache validateur met n'importe
quoi comme TAL (des certificats mal ou pas gérés), toute la
confiance s'écroule. Il faut donc bien choisir ses TAL ! Voici un
contre-exemple, une installation de rcynic où ont été installées toutes
les TAL possibles, test et production mêlées :
% ls etc/trust-anchors
afrinic.tal lacnic.tal testbed-apnicrpki.tal
apnic.tal ripe-ncc-root.tal testbed-arin.tal
bbn-testbed.tal testbed-apnic.tal testbed-ripe.tal
% cat etc/trust-anchors/ripe-ncc-root.tal
rsync://rpki.ripe.net/ta/ripe-ncc-ta.cer
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0URYSGqUz2m
yBsOzeW1jQ6NsxNvlLMyhWknvnl8NiBCs/T/S2XuNKQNZ+wBZxIgPPV
...
Le RFC insiste ensuite sur un des points les plus faibles de la
RPKI : les délais de mise à jour ne sont spécifiés nulle part (voir
aussi la section 6 du RFC, qui revient sur ce problème). Un
cache validateur pourrait, par exemple, ne charger les données avec
rsync que deux fois par semaine et travailler ainsi avec des données
relativement anciennes, sans violer aucune norme technique. (La
section 6 du RFC prétend que c'est la même chose avec le
DNS, qui n'est que « synchrone à terme ». Mais
c'est tout à fait faux : dans le DNS, les délais sont parfaitement
connus et standards, le principal étant le TTL.) À
l'intérieur de son réseau, un opérateur qui a plusieurs caches peut
décider de les synchroniser très fréquemment : ce sont ses machines,
il décide. Mais, à l'extérieur, même si ce RFC n'en parle pas, il
n'est pas du tout sûr que les serveurs rsync
des RIR résistent en cas de synchronisation
trop agressive.
Après ces questions d'architecture de la validation, la section 3
de notre RFC continue avec la création des ROA (Route Origin
Authorizations, les objets signés qui authentifient la
prétention d'un AS à être à l'origine de
l'annonce BGP d'un préfixe). D'abord, bien se rappeler
qu'IP est arborescent : un ROA pour
192.0.2.0/24 peut concerner aussi
192.0.2.128/26. Avant d'émettre un ROA couvrant
un gros préfixe, il faut donc être sûr que tous les préfixes
inférieurs qui auront besoin d'être routés ont déjà des ROA
corrects. Sinon, toutes leurs annonces deviendront subitement
invalides.
Les ROA disposent d'un attribut maxLength qui
permet d'être un peu laxiste en cas d'annonce d'un sous-préfixe. Si le
ROA concerne le préfixe 192.0.2.0/24-26 (avec 24
= longueur du préfixe, et 26 = longueur maximale des annonces), une
annonce 192.0.2.128/26 sera acceptée (alors que
192.0.2.128/27 serait refusée). Mais c'est
dangereux car une annonce plus spécifique (préfixe plus long) créera
une entrée prioritaire dans la table de routage (IP donnant la
priorité au préfixe le plus long), facilitant le
détournement que RPKI+ROA avait pour mission d'empêcher. Le RFC
conseille donc, d'abord que les logiciels de gestion de la RPKI
mettent, par défaut, une longueur maximale égale à la longueur du
préfixe (aucun sous-préfixe autorisé) et ensuite que
maxLength soit utilisé avec précaution. Si on a
juste trois sous-préfixes, il vaut sans doute mieux générer trois ROA
pour eux, plutôt que d'affaiblir la sécurité en ayant une longueur
maximale supérieure à la longueur du préfixe. (Ou un seul ROA
contenant trois préfixes s'ils ont tous le même AS d'origine.)
On l'oublie souvent, mais un préfixe peut être « multi-origine »,
c'est-à-dire être annoncé par plusieurs
AS. C'est même recommandé dans certains cas,
par le . Dans ce cas, il faut faire
autant de ROA qu'il y a d'AS d'origine possibles (un ROA peut contenir
plusieurs préfixes mais pas plusieurs AS).
Enfin (il y a aussi plein d'autres recommandations que je n'ai pas
reprises ici), le RFC recommande d'utiliser des outils automatiques
pour superviser ses objets RPKI et, par exemple, avertir lors de
l'expiration proche d'un certificat (comme on devrait le faire pour tous les certificats).
Au fait, à quel endroit du réseau doit-on installer les routeurs
qui utiliseront la validation ? La section 4 se penche sur cette
question. A priori, seuls les routeurs de bord, ceux situés au contact
d'un autre AS, seront dans ce cas. Les autres routeurs font confiance
aux routes distribuées en interne. On peut même déployer cette
utilisation de la validation de manière incrémentale, un routeur après
l'autre. Mais attention à la répartition du trafic : les premiers
routeurs qui utiliseront la validation pourront refuser certaines routes,
que les autres accepteront, menant à des déplacements de trafic d'un
lien vers un autre.
J'ai dit que les routeurs qui utilisent la validation pourraient
refuser certaines routes. Justement, que doit faire un routeur qui se
connecte à un cache validateur lorsque ledit cache a marqué une route
comme invalide (cf. pour les
différents résultats de validation) ? La section 5 du RFC décrit les
politiques possibles. Le principe cardinal est « chaque opérateur
décide ». Ce n'est pas le RFC qui décide de ce que doit faire le
routeur.
L'approche radicale serait évidemment que le routeur rejette les
routes invalides. Mais, si on se fie au déploiement d'autres
techniques de sécurité comme DNSSEC, au début,
il y aura plein d'erreurs par les opérateurs et bien des routes seront
marquées à tort comme invalides. Rejeter ces routes dès le début
serait sans doute une erreur. Il vaudrait sans doute mieux commencer
par une approche moins violente, se contentant d'attribuer une
priorité plus basse aux routes invalides.
Le problème est que cela permet des attaques avec des préfixes plus
spécifiques, comme dans l'exemple plus haut. Soit un ROA
192.0.2.0/24-24 (le 24-24 indiquant que la
longueur du préfixe et la longueur maximale admise sont la même, 24
bits). Un méchant annonce
192.0.2.128/26. Cette annonce sera marquée comme
invalide par le système RPKI+ROA. Mais si elle est quand même
acceptée, même avec la priorité la plus basse, elle s'installera dans
les tables de routage et, étant plus spécifique que
192.0.2.0/24, elle gagnera, et les paquets IP seront
envoyés à l'endroit désigné par l'annonce du méchant. Bref, pas de
solution idéale à ce dilemme, le RFC suggère néanmoins de ne pas
accepter les routes invalides sans une bonne raison.
Et si le résultat de la validation est qu'aucun ROA couvrant cette
annonce n'a été trouvé (le cas le plus fréquent aujourd'hui, où seule
une minorité de préfixes sont signés) ? Le RFC recommande évidemment
d'accepter ces routes. Ce n'est pas demain la veille qu'on pourra dire
« quasiment tout le monde a des ROA, arrêtons de router les autres ».
Enfin, la section 6 couvre quelques recommandations diverses :
avoir des mécanismes spéciaux pour les préfixes « importants », par
exemple ceux des serveurs racine du DNS, afin
d'être prévenu si la RPKI veut tout à coup les invalider, gérer les AS
sur quatre octets du , et avoir des
horloges à l'heure, puisque certificats et ROA peuvent expirer.
Le but de RPKI+ROA est d'améliorer la sécurité du routage
Internet, notamment face à des détournements comme celui de YouTube par Pakistan
Telecom. Cet objectif est-il atteint ? La section 7 de notre
RFC appelle à la prudence : les ROA, comme leur nom l'indique, ne
protègent que l'origine d'une annonce (l'AS le plus à droite dans un
chemin d'AS). Dans quasiment tous les détournements accidentels (comme
celui de Pakistan Telecom cité plus tôt), l'origine est changée et
RPKI+ROA le détecterait donc. Mais, si le détournement n'est pas un
accident mais une attaque délibérée, on peut penser que le méchant va
soigner ses annonces BGP. Il mettra probablement la vraie origine et
ne bricolera que la suite du chemin. Pour l'instant, la RPKI n'a pas
de mécanisme pour faire face à cela. De même, toute manipulation du
chemin faite après l'émission par l'AS d'origine ne sera pas détectée,
tant que l'origine est respectée.
Ah, et une autre limite de ce système : BGP ne fait que transmettre
des annonces de route, que les routeurs ne respectent pas forcément (« les
données ne suivent pas forcément le contrôle »). Donc, même si BGP est
parfaitement sécurisé, des routeurs défaillants ou piratés peuvent
encore faire échouer la sécurité.
Une bonne lecture concrète en français sur le
système RPKI+ROA ? « Sécuriser
le routage sur Internet » de Guillaume Lucas. Sinon, il existe une liste de diffusion
des opérateurs RPKI mais avec très peu de trafic.
Merci à Guillaume Lucas pour sa relecture très attentive, mais cela
ne veut pas dire qu'il est d'accord avec tout.