RPKI et ROA : ce que les acheteurs et les locataires doivent vraiment faire

Pourquoi ce n'est plus facultatif

Pendant des années, le RPKI était une chose dont les opérateurs convenaient qu'elle était une bonne idée, sans jamais s'y mettre. Cela a changé quand les grands réseaux ont commencé à l'appliquer réellement. Les grands opérateurs de transit, les grandes plateformes cloud et plusieurs grands réseaux de contenu pratiquent désormais la validation de l'origine des routes (Route Origin Validation) et rejettent les routes qui ressortent invalides.

La conséquence pratique est brutale. Un préfixe avec un ROA erroné n'est pas seulement non protégé, il est injoignable depuis une part croissante d'Internet. Et la panne est partielle et déroutante : certains utilisateurs vous atteignent, d'autres non, et les traceroutes semblent normaux depuis l'endroit où vous testez.

Si vous achetez ou louez des adresses, c'est le détail de configuration le plus susceptible de vous coûter une journée.

Ce qu'est réellement un ROA

Le RPKI est un système d'attestations cryptographiques liées au registre des adresses. L'objet qui compte au quotidien est la Route Origin Authorization, ou ROA, et il contient exactement trois choses :

• Le préfixe. Par exemple 192.0.2.0/24.
• L'AS d'origine. Le numéro de système autonome autorisé à l'annoncer.
• Une longueur maximale. Le préfixe le plus long qui peut être annoncé dans ce bloc.

C'est tout l'objet. C'est une déclaration signée du titulaire des adresses qui dit « cet AS est autorisé à être l'origine de cet espace, jusqu'à cette taille précise ». Les routeurs ne le lisent pas directement. Des validateurs récupèrent et vérifient les données RPKI, et transmettent le résultat aux routeurs, qui classent alors chaque route comme valide, invalide ou non trouvée.

Chaque route ressort dans l'un de trois états. Valid : un ROA couvre le préfixe et l'annonce lui correspond. NotFound, que beaucoup d'outils affichent comme Unknown : aucun ROA ne couvre le préfixe. Invalid : un ROA couvre le préfixe, mais l'annonce le contredit, soit depuis le mauvais AS, soit avec un préfixe plus long que ne le permet la longueur maximale.

L'ordre de ces états compte plus qu'on ne le pense. Une route sans ROA est encore acceptée presque partout : elle n'est pas protégée, mais elle passe. Une route qui ressort Invalid est rejetée par chaque réseau qui applique la validation. Aucun ROA vaut mieux qu'un ROA faux. L'objectif est un ROA correct mais, si les détails ne sont pas arrêtés le jour où vous annoncez, annoncer sans ROA et l'ajouter une fois qu'ils le sont est bien plus sûr que de publier un ROA qui contredit ce que vous envoyez.

Qui le crée dépend de la façon dont vous avez obtenu les adresses

Ce point piège constamment, il vaut donc la peine d'être explicite.

Si vous avez acheté le bloc, il est enregistré à votre nom et vous créez le ROA vous-même dans le portail de votre registre, ou demandez à votre LIR parrain de le créer s'il entretient pour vous la relation avec le registre. Faites-le après la fin du transfert, pas avant, car l'objet doit être créé sous le nouveau titulaire. Un espace legacy acheté dans la région du RIPE NCC a besoin d'un contrat avec le RIPE NCC ou un LIR parrain avant de pouvoir avoir un ROA (le RIPE NCC).

Si vous louez, le bloc n'est pas enregistré à votre nom et vous ne pouvez pas créer le ROA. Le titulaire le fait, pour votre ASN. Vous devez donc lui indiquer deux choses dès le départ : l'ASN depuis lequel vous annoncerez, et si vous comptez annoncer quelque chose de plus spécifique que le bloc entier. Une location dont le ROA n'a pas été créé pour votre ASN ressortira invalide dès que vous l'annoncerez.

Si vous annoncez via un fournisseur cloud en BYOIP, le ROA doit en général indiquer l'ASN du fournisseur plutôt que le vôtre, car c'est son réseau qui est l'origine de la route : AS16509 et AS14618 chez AWS, AS8075 chez Azure, AS396982 chez Google Cloud sur son niveau Premium. Certains fournisseurs vous permettent d'être l'origine depuis votre propre ASN, soit par une session BGP à vous (Vultr, Cherry Servers), soit avec une option « bring your own ASN » en plus du BYOIP (AWS, Oracle Cloud, OVHcloud, IONOS Cloud, Gcore). Un ROA indique alors votre ASN, et AWS et Oracle Cloud en veulent aussi un indiquant le leur. La plupart des fournisseurs documentent l'ASN que doit indiquer le ROA, et quelques-uns, dont Gcore, ne le donnent que sur demande : vérifiez donc avant de créer quoi que ce soit ; nos guides par fournisseur les listent.

Les deux erreurs qui causent des pannes

Presque toutes les pannes RPKI réelles tiennent à la longueur maximale.

La régler trop permissive. Un ROA pour 192.0.2.0/24 avec une longueur maximale de /32 signifie que toute annonce de toute taille dans ce bloc est valide. Cela annule une bonne partie de l'intérêt : un auteur de détournement qui annonce une route plus spécifique depuis votre numéro d'AS ressort toujours valide, et les routes plus spécifiques l'emportent en BGP. Le réglage sûr par défaut est de fixer la longueur maximale égale à la longueur du préfixe, sauf raison concrète de faire autrement.

La régler trop stricte. Si vous annoncez un /24 couvert par un ROA, puis devez plus tard le désagréger en deux /25 pour l'ingénierie de trafic, ces /25 deviennent instantanément invalides et disparaissent d'une grande partie d'Internet. Si vous prévoyez d'annoncer des préfixes plus spécifiques, le ROA doit le permettre avant que vous ne commenciez.

La règle qui évite les deux : faites décrire au ROA exactement ce que vous annoncez réellement, et mettez-le à jour dans la même fenêtre de changement que toute modification de routage, pas après.

ASPA : la couche suivante

Un ROA protège le premier maillon d'une route : qui peut en être l'origine. Il ne dit rien du chemin ensuite, là où se produisent les fuites de routes, quand un réseau transmet des routes qu'il aurait dû garder pour lui. ASPA, Autonomous System Provider Authorization, couvre une partie de cette lacune.

Un objet ASPA est signé par le titulaire d'un numéro d'AS et liste les AS qui sont ses fournisseurs de transit. Les réseaux qui le valident peuvent rejeter un chemin dans lequel votre AS semble atteindre Internet par quelqu'un qui n'est pas votre fournisseur. C'est un standard IETF émergent. Le RIPE NCC le décrit comme prêt à l'emploi pour la signature, et l'ARIN et l'APNIC permettent aussi aux titulaires de signer des ASPA (les registres comparés).

• Si vous avez votre propre ASN, publiez un ASPA listant chaque opérateur de transit qui porte vos routes vers Internet. Laissez de côté les pairs et vos propres clients.
• Tenez-le à jour. Un fournisseur absent de l'objet peut faire rejeter vos routes passant par lui par les réseaux qui appliquent ASPA : ajoutez donc un nouveau transit avant de l'activer et retirez un ancien après l'avoir coupé.
• Vous apportez votre propre ASN à un cloud ? AWS recommande un ASPA qui liste AS16509 et AS14618 comme fournisseurs de votre ASN ; sans eux, les routes qu'il réannonce pour vous échouent à la validation ASPA.
• Vous louez ? L'ASPA appartient à votre ASN, pas au préfixe : c'est donc à vous de le publier, pas à nous.

La liste de contrôle

Avant que les adresses ne portent du trafic de production :

• Le ROA existe pour le bon préfixe et le bon AS d'origine.
• La longueur maximale correspond à votre plan d'annonce réel.
• Les objets route IRR sont aussi en place. Le RPKI ne les a pas remplacés. Beaucoup d'opérateurs de transit construisent encore leurs filtres de préfixes à partir des données IRR : un ROA valide sans objet route correspondant vous fait donc encore filtrer.
• L'ASPA liste chaque opérateur de transit, si vous en publiez un, et aucun pair ni client.
• Validez depuis l'extérieur. Vérifiez depuis un looking glass externe ou un validateur RPKI, pas depuis votre propre réseau, qui acceptera volontiers vos propres routes.
• Faites le ménage en partant. Quand une location prend fin ou que vous cessez d'annoncer un bloc, le ROA doit être retiré ou mis à jour. Un ROA périmé pointant vers un ASN qui n'annonce plus les adresses pose problème à celui qui les reçoit ensuite.

La place de RTM Networks

Nous créons et tenons à jour les ROA dans le cadre de la location comme du parrainage, et non en option (louer de l'IPv4, parrainage PI et ASN). Pour une location, indiquez-nous l'ASN depuis lequel vous annoncerez, ou le fournisseur cloud auquel vous apportez les adresses, et si vous avez besoin de préfixes plus spécifiques, et le ROA est configuré avant la remise. Pour les ressources parrainées, nous gérons la configuration RPKI avec les autres objets du registre.

Si vous reprenez des adresses venant d'ailleurs, qui met en place le RPKI dépend de la voie : un acheteur le fait pour le bloc lui-même, et pour une location c'est le loueur. Nous pouvons vérifier si un ROA existe pour le bloc et, le cas échéant, s'il est valide.