D’accord le titre de l’article est volontairement racoleur, mais si j’avais mis d’emblée BGP, RPKI, SIDR, ROA, SIA et d’autres acronymes du genre auriez-vous essayé de lire l’article?
Contexte
Commençons par comprendre le problème: l’internet est créé pas l’interconnexion de réseaux qui échangent leurs routes. Imaginons 2 opérateurs A et B qui décident de s’interconnecter et permettre ainsi aux flux entre les clients de ces opérateurs d’être acheminés par une liaison directe. A annonce à B les routes de ses clients et B fait pareil. Le protocole de routage utilisé par A et par B est BGP (Border Gateway Protocol).
Mais voila, au niveau de BGP, rien n’empêche A d’annoncer à B une route qui ne lui appartient pas, ou pire encore d’envoyer des préfixes plus spécifiques de manière à être certain d’attirer tout le trafic vers lui. C’est exactement ce qui s’était passé en 2008 quand le Pakistan, qui souhaitait alors filtrer Youtube avait annoncé sur l’internet les préfixes de celui-ci en plus spécifiques, provoquant ainsi une panne du célèbre fournisseur de contenu vidéo pendant environ 2H30 (le temps que tous les opérateurs ajustent leurs filtres)
Les opérateurs mettent en place des filtres plus ou moins précis au niveau de leurs peerings Internet, qui peuvent se baser sur les registres de routage internet (IRR). Je tente de décire cela dans ce draft IETF. L’information contenue dans ces registres n’est pas fiable dans la mesure où les enregistrements ne sont pas contrôlés. Du coup un groupe de travail IETF nommé SIDR (Secure Inter Domain Routing) a travaillé sur le sujet et propose des solutions. Voici une petite vidéo qui explique tout ça très bien:
Comme expliqué dans la vidéo chaque opérateur va donc être capable de créer des ROA (Route Origin Authorizations) décrivant pour chaque préfixe qui lui appartient le numéro d’AS qui origine le préfixe et la désaggrégation autorisée (même si l’on déclare un /21, on peut estimer que les préfixes entre /21 et /23 sont valides et suivront les mêmes règles). Le RIPE NCC pour ce qui nous concerne a mis en place un portail d’une grande simplicité pour cela. L’opération peut être faite en 10 minutes pour un opérateur qui n’aurait que peu de préfixes à signer. Une fois le ROA (Route Origin Authorization) créé, il est signé avec la clé privée récupérée par l’opérateur. Si en théorie il peut être stocké n’importe où, le RIPE NCC propose également de stocker les ROA et les clés… C’est bien pratique car si le ROA n’est pas récupérable, cela peut ne pas être sans conséquences…
Voilà pour la partie théorique et la déclaration des préfixes. Maintenant essayons de voir comment utiliser l’information contenue dans cette RPKI. Des “validateurs” peuvent être déployés et ils vont reconstruire une table de routage théorique (liste des préfixes et leur AS théorique d’origine) à partir de la RPKI. Ils sont configurés avec les clés publiques des “ancres” de confiance (par exemple celles des registres régionaux RIPE NCC, ARIN, APNIC…) et peuvent par récursion récupérer toutes les informations signées. Chacun peut déployer son validateur: le RIPE NCC aussi nous fourni un code de validateur pas trop difficile à installer que j’ai utilisé pour mes tests.
Maintenant nous arrivons à la partie la plus intéressante. Vous pensez que ceci est très théorique? Et bien ce n’est plus le cas! On peut sur certains de nos routeurs récupérer les informations du “validateur” via un protocole nommé “rtr”. Cette architecture permet de déporter tout le mécanisme de gestion de clé (chiffrement…) ailleurs que sur le routeur qui a généralement autre chose à faire. Une fois que le routeur connaît le contenu de la base théorique on peut établir des règles directement dérivées de la RPKI via l’usage de simple route-maps! Là encore Stephane Boertmeyer décrit tout cela très bien sur son site.
La suite de l’article va montrer tout cela de façon très simple. Si la techno RPKI est (comme tout ce qui contient “PKI”) assez imbuvable pour le commun des mortels, nous verrons que finalement il n’est pas bien compliqué de signer ses préfixes et de valider les signatures des tiers. Reste à avoir les bons routeurs 🙂
Matériel et images
- ASR1001 en 3.5.1S (asr1001-universalk9.03.05.01.S.152-1.S1.bin) et une licence advanced IP services.
- Validateur du RIPE NCC – rpki-validator-app-2.0.3-bin
J’ai fait tous ces tests avec Simon Muyal du GIP RENATER que je tiens particulièrement à remercier (c’est lui qui a pratiquement tout fait!) J’ai bien sûr modifié certaines adresses et ASN dans les configurations. Ne soyez pas surpris de voir des peers Internet en AS privés!
Vérification de l’enregistrement des préfixes dans la RPKI
Nous avons faits les tests avec les préfixes PA du GIP RENATER. Des ROA ont été créés et signés via le portail du RIPE NCC et stockés également là-bas. Je commence par vérifier que les enregistrements faits sont corrects en utilisant des commandes whois vers un serveur bien connu whois.bgpmon.net qui est capable de répondre aux requêtes sur les ROA. Ci-dessous je vérifie si le préfixe IPv6 2001:660::/32 est bien originé depuis l’AS 2200. Le serveur whois commence par me répondre que c’est un enregistrement valide et il me donne également les détails de tout ce que contient le ROA (tous les préfixes que l’on a groupé dans le même numéro d’AS)
Jerome$ whois -h whois.bgpmon.net " --roa 2200 2001:660::/32"
0 - Valid
------------------------
ROA Details
------------------------
Origin ASN: AS2200
Not valid Before: 2012-02-01 00:00:00
Not valid After: 2012-06-30 00:00:00
Trust Anchor: rpki.ripe.net
Prefixes: 194.214.0.0/16
195.83.0.0/16
193.52.0.0/16
194.199.0.0/16
194.57.0.0/16
195.98.224.0/19
193.54.0.0/15
194.254.0.0/16
195.220.0.0/15 (max length /16)
193.48.0.0/14
81.194.0.0/16
194.167.0.0/16
2001:660::/32
Maintenant je fais un second test pour le préfixe IPv4 194.167.0.0/18 qui n’est pas dans la liste (même si le préfixe 194.167.0.0/16 moins spécifique est bien dans le ROA!)
Jerome$ whois -h whois.bgpmon.net " --roa 2200 194.167.0.0/18" 2 - Not Valid: Invalid Prefix-Length
Déclaration du validateur sur le routeur
Il suffit de déclarer sur le routeur le validateur. Ici nous déclarons qu’il est joignable en IPv6:
router bgp 65500 bgp router-id 10.11.12.13 bgp asnotation dot bgp log-neighbor-changes no bgp default ipv4-unicast bgp rpki server tcp 2001:db8:1000:2000::f00d port 8282 refresh 180 ...
Bien évidemment cela suppose que le validateur a bien été configuré pour accepter les connexions sur port 8282 et qu’il n’y a pas de firewall… Une fois que c’est fait, on peut vérifier sur le routeur que l’on reçoit bien la table théorique reçue du validateur.
ASR-1000-TEST-RPKI#sh bgp ipv4 unicast rpki table 1466 BGP sovc network entries using 234560 bytes of memory 1577 BGP sovc record entries using 50464 bytes of memory Network Maxlen Origin-AS Source Neighbor 10.0.1.0/24 24 1 0 2001:DB8:1000:2000::F00D/8282 10.4.0.0/16 16 21 0 2001:DB8:1000:2000::F00D/8282 10.4.0.0/16 16 234 0 2001:DB8:1000:2000::F00D/8282 10.5.0.0/16 16 1234 0 2001:DB8:1000:2000::F00D/8282 10.6.0.0/16 16 12345 0 2001:DB8:1000:2000::F00D/8282 ... ASR-1000-TEST-RPKI#sh bgp ipv6 unicast rpki table 326 BGP sovc network entries using 59984 bytes of memory 347 BGP sovc record entries using 11104 bytes of memory Network Maxlen Origin-AS Source Neighbor 2001:468::/32 48 11537 0 2001:DB8:1000:2000::F00D/8282 2001:470::/32 48 6939 0 2001:DB8:1000:2000::F00D/8282 2001:608::/32 32 5539 0 2001:DB8:1000:2000::F00D/8282 2001:608:6::/48 48 8763 0 2001:DB8:1000:2000::F00D/8282 2001:610::/32 48 1103 0 2001:DB8:1000:2000::F00D/8282 ...
Utilisation de la table RPKI pour le filtrage de préfixe
La simplicité est d’avoir juste intégré la possibilité de faire la comparaison avec la table théorique reçue des validateurs dans les route-maps. Ainsi on a toute la latitude pour appliquer la politique localement souhaitée, sans changer trop nos habitudes opérationnelles. Par exemple dans l’exemple suivant je drop les préfixes invalides (j’ai toujours été joueur), et j’augmente la local-pref pour les préfixes qui sont dans la base RPKI.
route-map test-rpki permit 10 match rpki invalid set local-preference 50 ! route-map test-rpki permit 20 match rpki unknown set local-preference 200 ! route-map test-rpki permit 30 match rpki valid set local-preference 300 ! router bgp 65500 neighbor 10.20.30.1 remote-as 65600 ! address-family ipv4 neighbor 10.20.30.1 activate neighbor 10.20.30.1 route-map test-rpki in exit-address-family ...
Conclusion
Sans trop de difficultés on a pu signer nos préfixes, mettre en place un validateur, et configurer le routeur pour s’appuyer sur la RPKI pour la gestion de son routage. Si l’on ajoute à cela que l’ASR1000 est le route-reflector BGP par excellence, et que l’on a même maintenant un code de route-server BGP, ça ouvre pas mal de perspectives à la fois pour nos réseaux mais aussi pour les points d’échange internet. Je rappelle que quelques minutes suffisent pour un petit LIR pour signer ses préfixes… et si on organisait une “signing party” au prochain FRNOG?
Rappelons tout de même que valider les ROA ne permet que de s’assurer que l’annonce correspond à ce qui est déclaré mais rien n’empêche quelqu’un de faire l’annonce “bidon” avec le bon AS d’origine… Pour cela l’implémentation de BGPsec sera nécessaire. Les annonces seront signées par tous les peers sur le path et chacun pourra donc valider que chaque AS sur le chemin est bien le bon. Mais pour cette partie là il va falloir attendre encore un tout petit peu avant d’avoir du code.
Authors
6 commentaires
Hi all, My apologies for commenting in English.
I would like to know if it will be possible to use RPKI feature on NPE-G1 with classic IOS 15.2(1) or exist hardware constraints, and if you plan to include RPKI features also in 12.4.
Thanks
Nous avons commencé les EFT “Early Field Trial” pour cette functionalitée pour les platformes suivantes: ASR9000, CRS1, CRS3 et c12K (IOS-XR). Si quelqu’un est intérèsé, il peux me contacter : bduvivie at cisco dot com.
Bertrand
IOS classic, IOS XE, IOS XR and NX-OS BGP product manager.
Alex,
The RPKI feature is now officialy supported on few platforms: ASR1000, 7600, ASR903, ASR901. First Customer Shipment was done in November 2011. Releases are 15.2(1)S or XE 3.5.
We now planning to support on more platforms moving forward, we planning to run it on more platform like ASR9K, c12K, CRS.
I’ll contact you directly and ask my engineering team to build a special image for RIPE NCC 🙂
Bertrand
IOS classic, IOS XE, IOS XR and NX-OS BGP product manager.
My apologies for commenting in English, my French writing leaves a lot to be desired. I would like to commend you on writing such a clear and practical article.
It’s correct that using the RIPE NCC hosted RPKI system, you can create ROAs very easily and you never have to worry about any of the crypto involved. So far almost 1000 LIRs have done this, proving that the entry barrier is very low. To get started, an LIR just has to follow these steps: http://ripe.net/certification/enable.html The user interface will show you which BGP announcements you do with your prefixes. All you have to do is create matching ROAs.
To respond to Stéphane: It is true that most operators only update IRR data when there is a problem. We are working very hard to ensure ROA data quality is excellent, and we have taken major steps in the last six months to ensure that. Because the hosted system is proving to be so popular, it also gives the RIPE NCC a big responsibility with regards to Certificate Authority operation, to make sure the keys do not get lost or compromised. We have auditing and even CA accreditation planned.
My question to Jerome: The most frequest question I get asked it “When can I get an IOS image with RPKI support for my Cisco router?”. I still don’t have a good reply, do you have any more information?
Mouais, c’est quand même un peu optimiste. L’argument « regardez comme c’est convivial, je signe en cinq minutes » ne me convainc pas. Si je me fie à l’expérience d’autres technologies avec crypto (PGP, DNSSEC), je dirais que l’étape initiale est en effet triviale mais c’est sur le long terme qu’on juge si la technique est gérable ou pas (clés privées perdus ou volées, logiciels qui réagissent bizarrement lorsque les données sont signées, etc).
Pour la RPKI, le plus gros problème de pas mal d’opérateurs va être simplement de retrouver la liste de tous leurs préfixes. Quand des opérateurs ne maintiennent même pas à jour l’IRR du RIPE, comment espérer qu’ils puissent faire de la RPKI ?
J’ai toujours été optimiste 🙂 Beaucoup de LIR n’ont qu’un ou 2 préfixes et un ASN, la certification sur l’outil du RIPE est presque plus simple que la gestion de l’IRR. A ce niveau là il n’y a pas d’obstacle: juste une nouvelle techno et des nouvelles méthodes à appréhender. Tu as raison sur le maintien des objets qui va demander une certaine rigueur. Je pense qu’on aura des surprises. Pour les gros opérateurs ca peut prendre du temps… A l’heure où nous bâtissons un nouvel internet, n’est-ce pas pour IPv6 que nous devrions “sécuriser” le routage en laissant derrière nous une jungle en IPv4?