Début novembre, tous les membres actifs et revendeurs ont été invités à donner leur avis sur la politique de filtrage des serveurs de route (RS – Route Server) qu’ils souhaiteraient voir adoptée par France-IX.

Début décembre, nous vous avions communiqué les résultats des votes ainsi que les prochaines étapes du projet. Nous sommes maintenant arrivés à une étape clé avec l’application de ce filtrage basée sur les entrées IRR et RPKI/ROA au niveau des RS durant le mois de février aussi bien à Paris qu’à Marseille.

Rappel sur le filtrage des routes sur Internet

Depuis longtemps, tous les opérateurs Tier1 sérieux appliquent un filtrage qui repose sur des bases de données appelées IRR (Internet Routing Registry). Ces bases sont gérées par les RIRs (Registre Internet Régionaux) et contiennent les ressources allouées sur Internet, notamment les adresses IP ainsi que les numéros d’AS (ASN). D’autres entités viennent compléter ou agréger ces bases pour avoir une vision exhaustive des ressources Internet.

Plus récemment, une infrastructure RPKI permet aux réseaux IP de vérifier l’origine des annonces BGP grâce aux ROAs (Route Origin Autorisation). Le fonctionnement des ROA est détaillé sur  la page de certification de ressources du RIPE. L’infrastructure RPKI étant plus récente, l’adoption d’un filtrage reposant sur les ROA n’est pas encore systématique chez les opérateurs.

Le filtrage au niveau des IXP 

Bien qu’au début, les RS étaient considérés comme de simples relais de routes entre les différents acteurs connectés sur le point d’échange, sans intelligence, ils ont progressivement évolué pour apporter des fonctions de filtrage. Ces dernières visent principalement à simplifier la gestion du peering pour les membres connectés à l’IXP et à augmenter la sécurité entre les membres.

Des bonnes pratiques ont rapidement vu le jour sur les RS afin de filtrer les préfixes non désirés tel que les bogons (https://www.team-cymru.org/bogon-reference-http.html) ou encore les routes contenant dans leur chemin un AS privé.

Par ailleurs, certains points d’échange ont pris l’initiative de « marquer » les routes avec des communautés BGP afin que leurs membres puissent identifier facilement celles qui ne sont pas présentes dans les bases IRR ou celles qui ont un ROA « INVALID ». Ainsi, chaque membre peut définir sa propre politique de filtrage en fonction des communautés BGP. France-IX propose ce mode depuis le printemps 2017.

Les RS évoluent avec le temps et la plupart des membres désirent aujourd’hui que ce filtrage IRR et ROA soit fait par défaut par l’IXP. Certains IXP envisagent aujourd’hui d’appliquer ce filtrage strict, d’autres le font déjà. Un filtrage strict par défaut garantit une sécurité accrue, l’adoption étant forte dès le début. Evidemment, les membres souhaitant continuer à recevoir les routes marquées pour appliquer eux-mêmes le filtrage pourront en faire la demande.

Calendrier pour l’application du filtrage strict sur les RS France-IX 

Pour répondre au besoin exprimé par les membres lors du vote de novembre 2017, France-IX a préparé les différentes actions permettant de mener à bien l’application du filtrage strict au niveau des RS :

• Décembre 2017/janvier 2018 : Un looking-glass a été mis en place pour permettre aux membres d’analyser comment les RS interprèteront leurs annonces de routes. Les commandes utiles sont listées ci-dessous, tandis que d’autres commandes sont disponibles sur https://lg.franceix.net/ :
• Routes with “ROA invalid” status for an origin ASN (no ROA invalid route originated by AS57734 in this example) : https://lg.franceix.net/roa_invalid/RS1+RS2/ipv4?q=57734
• Routes with “IRR not found” status for an origin ASN (i.e transit networks of $ASN with IRR records possibly not up-to-date) : https://lg.franceix.net/irr_notfound_for/RS1+RS2/ipv4?q=57734
• Routes with “IRR not found” status which are announced by ASN (this ASN has a peering with the RS) : https://lg.franceix.net/irr_notfound_from/RS1+RS2/ipv4?q=57734
• All routes with “ROA Invalid” state : https://lg.franceix.net/all_roa_invalid/RS1+RS2/ipv4
• All routes with “IRR not found” state : https://lg.franceix.net/all_irr_notfound/RS1+RS2/ipv4
• Décembre 2017/Janvier 2018 : Un environnement de test a été mis en place pour valider l’application du filtrage strict et valider qu’il n’y a pas d’effet de bord.
• 8 février 2018 : Maintenance pour l’application du filtrage strict sur RS-MRS-1 (Marseille) et RS-PAR-1 (Paris). Après cette maintenance, les membres pourront observer pendant une semaine la différence de routes reçus entre RS1 (filtrage strict) et RS2 (filtrage non strict avec marquage des communautés).
• 15 février 2018 : Maintenance pour l’application du filtrage strict sur RS-MRS-2 (Marseille) et RS-PAR-2 (Paris). Après cette maintenance, par défaut, les membres ne recevront plus les routes identifiées comme « IRR not found » ou « ROA invalid »

Comment une route est identifiée « IRR NOT FOUND » ou « ROA INVALID » par les RS de France-IX ?

« IRR NOT FOUND »: pour tout membre connecté à France-IX, un algorithme recherche l’objet AS-SET associé à l’ASN du membre. L’AS-SET est recherché premièrement dans le champ « IRR Record » de PeeringDB. Si ce champ est vide, l’algorithme va tenter de trouver un AS-SET dans l’objet « AUT-NUM » à travers les lignes « export » (syntaxe RPSL). Il est donc primordial que le champ « IRR Record » de PeeringDB soit bien renseigné avec l’AS-SET s’il existe ou l’AUT-NUM à défaut.

Une fois l’objet AS-SET trouvé (ou AUT-NUM), l’algorithme recherche et établit la liste des objets ROUTE définis pour les AUT-NUM présents dans cet AS-SET (ou AUT-NUM). L’outil bgpq3 est utilisé pour faire cette recherche récursive avec comme paramètres la base IRR de NTT (rr.ntt.net) et les sources suivantes : RIPE, APNIC, AFRINIC, ARIN, LACNIC, NTTCOM, ALTDB, BBOI, BELL, GT, JPIRR, LEVEL3, RADB, RGNET, SAVVIS et TC.

Cette liste d’entrées IRR est stockée dans notre système d’information puis répliquée en local sur le RS. Lors d’une annonce de route, le RS va rechercher si la route se trouve dans cette liste « IRR FOUND » pour l’AS qui annonce le préfixe (first-AS). Si c’est le cas, alors elle sera marquée par le RS avec la communauté BGP « 51706:65011 ». Sinon la communauté BGP « 51706:65021 » sera ajoutée à la route puis elle sera rejetée par défaut.

« ROA INVALID »: une instance du RPKI validator du RIPE est installée dans l’infrastructure France-IX. Cette instance permet d’avoir une copie des entrées ROA et de générer ainsi une liste stockée sur notre système d’information puis répliqué en local sur le RS, de la même façon que pour les entrées IRR. Lors d’une annonce de route, le RS va rechercher l’état de la route pour l’AS d’origine. Si l’état ROA est « VALID » ou « UNKNOWN » la route sera marquée avec les communautés respectives « « 51706:65012 » ou « 51706:65023 » puis acceptée. Si l’état ROA de la route est « INVALID » la communauté « 51706:65022 » sera ajoutée puis elle sera rejetée par défaut. Il est donc essentiel que les déclarations ROA auprès des RIR soient réalisées correctement (https://www.ripe.net/manage-ips-and-asns/resource-management/certification/resource-certification-roa-management)