C’est à Lyon que débute une nouvelle étape dans la sécurisation de BGP avec la mise en place de validation des routes BGP basée sur RPKI (Routing PKI) sur les route-serveurs du point d’échange internet local: LYONIX. Decryptage…
LyonIX est un point d’échange internet, une infrastructure réseau permettant aux entités s’y connectant (fournisseurs de services/contenus, entreprises…) de s’échanger librement du trafic internet. Les membres LyonIX établissent donc librement, directement entre eux, des peerings BGP (selon leur politique de peering). Si LyonIX reste neutre et n’intervient pas dans les mises en place de peering, il met en place comme la quasi totalité des points d’échange internet des route-servers BGP pour ses membres. Un route-server BGP est en quelque sorte pour eBGP l’équivalent d’un route-reflector pour iBGP. Un membre LyonIX peut, au lieu d’établir des peerings eBGP avec tous les autres membres, établir un seul peering BGP avec chacun des route-servers qui redistribuera les routes vers les autres membres, sans modifier l’AS-Path ni changer le next-hop.
Pour protéger ses membres de routes BGP “erronées” qui pourraient être annoncées par l’un d’entre eux, LyonIX a mis en oeuvre la validation de l’AS d’origine basée sur la RPKI (Routing PKI) sur les route-servers. Les membres (et éventuellement leurs clients) sont invités à créer et signer des ROA (Route Object Authorization), des objets décrivant les routes et leur numéro d’AS d’origine théorique attendu. LyonIX a développé des “validateurs” qui vont régulièrement rechercher tous les ROA enregistrés dans la RPKI et recréer une table BGP théorique. Le route-serveur BGP, un routeur Cisco ASR 1000, va récupérer du validateur cette table théorique et ainsi être capable de la comparer aux routes BGP échangées sur LyonIX. Les routes non conformes à la table théorique sont rejetées; les routes conformes et celles n’y sont pas présentes (quand les ROA n’ont pas été créés) sont marquées avec des communautés BGP ad-hoc permettant à chaque membre de disposer de l’information quant au statut de la validation.
Arnaud Fenioux (@afenioux), Responsable Technique de Rezopole (entité qui gère LyonIX) affirme: “Avant d’utiliser la méthode RPKI + ROA, nous filtrions uniquement avec les objets ROUTE de la base RIPE. Grâce à ces deux moyens combinés, nous pouvons assurer une vérification plus efficace des routes annoncées à nos membres sur le Route Serveur principal Cisco.”
Précurseur sur la validation des AS d’origine, LyonIX montre l’exemple et sera suivi sans doutes par d’autres qui inciteront les LIR (Local Internet Registries) à créer et signer leurs ROA, opération simple et indolore (à condition de ne pas oublier de renouveler l’opération à expiration du certificat). Les statistiques actuelles sur RPKI montrent que seules environ 6,6% des routes internet de la zone RIPE sont valides, la grande majorité restant inconnues (les ROA n’étant pas créés). On notera d’ailleurs qu’environ 1% des routes sont invalides (c’est-à-dire environ 13% des ROAs signées) et peuvent donc être rejetées quand des contrôles d’origines d’AS sont effectués en se basant sur RPKI. Il convient bien de rappeler qu’il est réellement indispensable de bien réfléchir à créer correctement les ROA et bien adapter les process de gestion du routage ou ajoutant RPKI.
Adoption RPKI au 29 avril 2014
Un grand bravo à l’équipe LyonIX: Arnaud Fenioux (@afenioux), Samuel Triolet (@striolet) et les autres! J’espère une présentation de cette belle réalisation lors du prochain meeting FRNOG et une accélération de l’adoption de cette technologie sur les autres points d’échange et chez les différents opérateurs.
A propos du LYONIX
LyonIX est le nœud d’échange de trafic Internet (GIX – Global Internet eXchange) de Lyon. Il est géré par Rezopole, association loi 1901. Les acteurs interconnectés sur le GIX de Lyon peuvent améliorer la qualité de leur débit Internet et faire baisser leurs coûts de bande passante Internet. Le GIX contribue ainsi au développement du Très Haut Débit à Lyon. LyonIX est également un NAP (Network Access Point), c’est à dire une place de marché pour vendre et acheter du transit Internet et/ou tous types de services livrables en IP ou en niveau 2. Le GIX NAP de Lyon est ouvert à tous les acteurs qui souhaitent se connecter (opérateurs, FAI, sociétés de services, grands comptes, collectivités locales…).
Références
- Page web RPKI Lyonix
- Page web Lyonix
- Post reseauxblog sur RPKI
- Article RPKI sur le blog de Stephane Bortzmeyer
- Best practices de sécurisation BGP (draft IETF)
- Statistiques RPKI
- Exemple équivalent en Equateur sous l’impulsion de LACNIC
- Configuration de BGP route-server sur ASR 1000
- Configuration de Origin-AS validation sur ASR 1000
@JeromeDurand
Authors
2 commentaires
Petite correction : bien que la définition du route-serveur donnée ci-dessus soit correcte, la fonction décrite ne correspond pas à ce que font, souvent, les “route-serveurs” du Lyonix. En effet ceux-ci se comportent souvent, et notamment dans les interconnexions avec d’autres points d’échange, comme des routeurs (le next-hop est donc modifié, et probablement aussi l’AS-PATH). La conséquence est que le trafic est, dans ce cas, pris en charge par l’équipement, ce qui n’est pas le cas sur un route-serveur.
Bravo au Lyonix pour ce pas en avant. Espérons qu’ils pourront nous faire des retours sur la mise en oeuvre de cette sécurité, sans doute laborieuse puisqu’il faut convaincre les membres et leurs clients de faire les formalités de signature nécessaires.
D’ou l’intérêt de l’ASR 1000 qui sait faire les 2 fonctions demandées: RS + routage 🙂
J’aimerais qu’on arrive a faire à un futur Frnog, en coopération avec le RIPE NCC, ce qu’a été fait par le LACNIC en équateur (voir référence dans mon article). Présentations théoriques (nous en avons déjà eu une très bien mais un rappel serait bienvenu), quelques retours terrain, une analyse de la situation vu du RIPE NCC, les avancées côté standardisation (on ne résout pas tout en s’assurant que l’origin-AS est bonne, loin de la) et peut être un rappel des best practices de sécurisation BGP (présentation de mon ID qui deviendra j’espere un RFC bientot) et peut etre intervention des personnes de l’ANSSI qui ont rédigé un excellent document de recommandations. Je pensais aussi que des personnes du RIPE-NCC pouvaient être présentes à des bureaux pour aider les personnes à signer leurs préfixes en live. Que ceux que ca intéresse le fassent savoir 🙂