Fonctionnement et sécurité de BGP

(1)

Équipe d’ingénierie de l’Internet (IETF) J. Durand, Cisco Systems, Inc.

Request for Comments : 7454 I. Pepelnjak, NIL

BCP 194 G. Doering, SpaceNet

Catégorie : Bonnes pratiques actuelles février 2015

ISSN : 2070-1721 Traduction Claude Brière de L’Isle

Fonctionnement et sécurité de BGP

Résumé

Le protocole de passerelle frontière (BGP, Border Gateway Protocol) est le protocole presque exclusivement utilisé dans l'Internet pour échanger les informations d'acheminement entre les domaines du réseau. Du fait de sa nature centrale, il est important de comprendre les mesures de sécurité qui peuvent et devraient être déployées pour prévenir des perturbations accidentelles ou intentionnelles d'acheminement.

Le présent document décrit les mesures pour protéger les sessions BGP elles mêmes comme la durée de vie (TTL, Time to Live) l'option d'authentification TCP (TCP-AO, TCP Authentication Option) et le filtrage de plan de contrôle. Il décrit aussi les mesures pour mieux contrôler le flux des informations d'acheminement, en utilisant le filtrage de préfixe et l'automatisation des filtres de préfixe, le filtrage de préfixe maximum, le filtrage de chemin de système autonome (AS, système autonome) l'amortissement de fluctuations de chemin, et le nettoyage de communauté BGP.

Statut de ce mémoire

Ceci est un document des bonnes pratiques actuelles de l'Internet.

Le présent document a été produit par l’équipe d’ingénierie de l’Internet (IETF). Il représente le consensus de la communauté de l’IETF. Il a subi une révision publique et sa publication a été approuvée par le groupe de pilotage de l’ingénierie de l’Internet (IESG). Plus d’informations sur les normes de l’Internet sont disponibles à la paragraphe 2 de la [RFC5741].

Les informations sur le statut actuel du présent document, tout errata, et comment fournir des réactions sur lui peuvent être obtenues à http://www.rfc-editor.org/info/rfc7454

Notice de droits de reproduction

Le présent document est soumis au BCP 78 et aux dispositions légales de l’IETF Trust qui se rapportent aux documents de l’IETF (http://trustee.ietf.org/license-info) en vigueur à la date de publication de ce document. Prière de revoir ces documents avec attention, car ils décrivent vos droits et obligations par rapport à ce document. Les composants de code extraits du présent document doivent inclure le texte de licence simplifié de BSD comme décrit au paragraphe 4.e des dispositions légales du Trust et sont fournis sans garantie comme décrit dans la licence de BSD simplifiée.

Table des matières

1. Introduction...2

1.1 Langage des exigences...2

2. Portée du document...2

3. Définitions et acronymes...2

4. Protection du locuteur BGP...3

5. Protection des sessions BGP...3

5.1 Protection des sessions TCP utilisées par BGP...3

5.2 Sécurité de BGP par le TTL (GTSM)...3

6. Filtrage de préfixe...4

6.1 Définition des filtres de préfixe...4

6.2 Recommandations de filtrage de préfixe dans les réseaux à acheminement complet...7

6.3 Recommandations de filtrage de préfixe pour les réseaux d'extrémité...9

7. Atténuation de fluctuations de chemin BGP...9

8. Préfixes maximum sur une relation d'homologue à homologue...9

9. Filtrage de chemin d'AS...10

10. Filtrage de prochain bond...10

11. Nettoyage de communauté BGP...11

12. Considérations sur la sécurité...11

13. Références...11

(2)

13.1 Références normatives...11

13.2 Références pour information...12

Appendice A. Exemple de filtrage de préfixe de LAN IXP...13

Remerciements...13

Adresse des auteurs...13

1. Introduction

Le protocole de routeur frontière (BGP, Border Gateway Protocol) spécifié dans la [RFC4271], est le protocole utilisé dans l'Internet pour échanger des informations d'acheminement entre domaines réseau. BGP n'inclut pas directement de mécanismes qui contrôlent si les routes échangées se conforment aux diverses lignes directrices définies par la communauté de l'Internet.

L'intention du présent document est à la fois de résumer les lignes directrices communes existantes et d'aider les administrateurs de réseau à appliquer des politiques cohérentes en ce qui concerne BGP.

1.1 Langage des exigences

Les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS",

"RECOMMANDE", "PEUT", et "FACULTATIF" en majuscules dans ce document sont à interpréter comme décrit dans le BCP 14, [RFC2119].

2. Portée du document

Les lignes directrices définies dans le présent document sont destinées aux échanges Internet génériques d'homologues à homologues BGP. La nature de l'Internet est telle que les systèmes autonomes peuvent toujours s'accorder sur des exceptions à un cadre commun pour les besoins locaux pertinents, et donc configurer une session BGP d'une manière qui peut différer des recommandations fournies dans le présent document. Bien que ceci soit parfaitement acceptable, chaque exception configurée peut avoir un impact sur l'ensemble de l'environnement de l’acheminement inter domaines, et les administrateurs de réseau DEVRAIENT soupeser attentivement cet impact sur une mise en œuvre.

3. Définitions et acronymes

ACL (Access Control List) : liste de contrôle d’accès

ASN (système autonome Number) : numéro de système autonome IRR (Internet Routing Registry) : registre d'acheminement Internet IXP (Internet Exchange Point) : point de commutation Internet LIR (Local Internet Registry) : registre Internet local

PMTUD (Path MTU Discovery) : découverte de la MTU de chemin RIR (Regional Internet Registry) : registre Internet régional

fournisseur de transit Tier 1 : fournisseur de transit IP qui peut joindre tout réseau sur l'Internet sans acheter de services de transit.

uRPF (Unicast Reverse Path Forwarding) : transmission en envoi individuel sur le chemin inverse En plus de la liste ci-dessus, les termes suivants sont utilisés avec une signification spécifique :

Vers l'aval : tout réseau qui est vers l'aval ; ce peut être un réseau fournisseur ou un réseau consommateur.

Vers l'amont : tout réseau qui est vers l'amont.

4. Protection du locuteur BGP

Le locuteur BGP a besoin d'être protégé contre les tentatives de subversion de la session BGP. Cette protection DEVRAIT être réalisée par une liste de contrôle d'accès (ACL, Access Control List) qui va éliminer tous les paquets dirigés sur l'accès TCP 179 sur l'appareil local et dont la source est une adresse inconnue ou à qui il est permis de devenir un voisin BGP.

L'expérience a montré que la protection naturelle que TCP devrait offrir n'est pas toujours suffisante, car elle fonctionne parfois dans un logiciel de plan de contrôle. En l'absence d'ACL, il est possible d'attaquer un locuteur BGP en lui envoyant simplement un fort volume de demandes de connexion.

(3)

Si elle est prise en charge, une ACL spécifique du plan de contrôle du routeur DEVRAIT être utilisée (ACL en réception, régulation du plan de contrôle, etc.) pour éviter la configuration de filtres de plan de données pour les paquets qui transitent à travers le routeur (et donc qui n'atteignent pas le plan de contrôle). Si le matériel ne peut pas faire cela, des ACL d'interface peuvent être utilisées pour bloquer les paquets adressés au routeur local.

Certains routeurs programment automatiquement une telle ACL à la configuration de BGP. Sur les autres appareils, cette ACL devrait être configurée et maintenue manuellement ou en utilisant des scripts.

En plus du filtrage strict, la limitation de débit PEUT être configurée pour du trafic BGP accepté. La limitation de débit du trafic BGP consiste à ne permettre qu'une certaine quantité de bits par seconde (ou de paquets par seconde) de trafic BGP au plan de contrôle. Cela protège le plan de contrôle du routeur BGP au cas où la quantité de trafic BGP dépasserait les capacités de la plate-forme.

Le filtrage et la limitation de débit du trafic de plan de contrôle est un sujet plus large que "juste pour BGP". (Si un administrateur de réseau met par terre un routeur en le surchargeant à distance avec un des autres protocoles, BGP est aussi affecté.) Pour une recommandation plus détaillée sur la façon de protéger le plan de contrôle du routeur, voir la [RFC6192].

5. Protection des sessions BGP

Les problèmes de sécurité actuels des protocoles fondés sur TCP (donc incluant BGP) ont été documentés dans la [RFC6952].

Les paragraphes qui suivent font la liste des points majeurs soulevés dans cette RFC et donnent les meilleures pratiques relatives à la protection de la session TCP pour le fonctionnement de BGP.

5.1 Protection des sessions TCP utilisées par BGP

Les attaques contre les sessions TCP utilisées par BGP (autrement dit, les sessions BGP) par exemple, en envoyant des paquets RST TCP contrefaits, pourraient mettre à terre une relation d’échange BGP. À la suite d'une attaque réussie de contrefaçon d'ARP (ou autre attaque similaire par interposition) l'attaquant peut même être capable d'injecter des paquets dans le flux TCP (attaques d'acheminement).

Les sessions BGP peuvent être sécurisées avec divers mécanismes. La protection par MD5 de l'en-tête de session TCP, décrite dans la [RFC2385], a été le premier de ces mécanismes. Il a été rendu obsolète par l'option d'authentification TCP (TCP-AO, [RFC5925]) qui offre une plus forte protection. Alors que MD5 est encore le mécanisme le plus utilisé à cause de sa disponibilité dans les équipements des fabricants, TCP-AO DEVRAIT être préféré quand il est mis en œuvre.

IPsec pourrait aussi être utilisé pour la protection de session. Au moment de cette publication, il n'y a pas encore assez d'expérience de l'impact de l'utilisation de IPsec pour les échanges BGP, et une analyse plus approfondie est nécessaire pour définir des lignes directrices.

L'inconvénient de la protection de session TCP est une surcharge supplémentaire de configuration et de gestion pour la maintenance des informations d'authentification (par exemple, les mots de passe MD5). La protection des sessions TCP utilisée par BGP est donc NON EXIGÉE même lorsque des relations d'homologue à homologue (peerings) sont établies sur des réseaux partagés où la contrefaçon peut être effectuée (comme les IXP) mais il est RECOMMANDÉ aux opérateurs de considérer les compromis et d'appliquer la protection de session TCP lorsque c'est approprié.

De plus, les administrateurs de réseau DEVRAIENT bloquer les paquets contrefaits (paquets avec une adresse IP de source IP appartenant à leur espace d'adresses IP) à toutes les frontières de leur réseau (voir la [RFC2827] et la [RFC3704]). Cela protège la session TCP utilisée par BGP interne (IBGP) contre les attaquants extérieurs au système autonome.

5.2 Sécurité de BGP par le TTL (GTSM)

Il peut être rendu plus difficile de contrefaire les sessions BGP avec les mécanismes de sécurité du TTL généralisé (GSTM, Generalized TTL Security Mechanism) (aussi appelé sécurité TTL), définis dans la [RFC5082]. Au lieu d'envoyer des paquets TCP avec une valeur de TTL de 1, les locuteurs BGP envoient des paquets TCP avec une valeur de TTL de 255, et le receveur vérifie que la valeur de TTL est égale à 255. Comme il est impossible d'envoyer un paquet IP avec un TTL de 255 à un hôte IP qui n'est pas directement connecté, la sécurité TTL BGP empêche effectivement toutes les attaques en contrefaçon qui viennent de tiers non directement connectés au même sous réseau que les routeurs locuteurs BGP. Les administrateurs de réseau DEVRAIENT mettre en œuvre la sécurité TTL sur les échanges BGP d'homologue à homologue directement connectés.

(4)

GTSM pourrait aussi être appliqué aux échanges d'homologue à homologue BGP multi bonds. Pour réaliser cela, le TTL doit être configuré avec une valeur appropriée qui dépend de la distance entre les locuteurs BGP (en utilisant le principe décrit ci- dessus). Néanmoins, ce n'est pas aussi efficace parce que n'importe qui à l'intérieur du périmètre du TTL pourrait contrefaire le TTL.

Comme la protection MD5, la sécurité TTL doit être configurée sur les deux extrémités d'une session BGP.

6. Filtrage de préfixe

Le principal aspect de la sécurisation de BGP réside dans le contrôle des préfixes qui sont reçus et annoncés sur l'échange d'homologue à homologue BGP. Les préfixes échangés entre homologues BGP sont contrôlés avec des filtres d'entrée et de sortie qui peuvent correspondre aux préfixes IP (comme décrit dans cette section) aux chemins d'AS (comme décrit à la Section 9) ou à tous autres attributs d'un préfixe BGP (par exemple, de communautés BGP, comme décrit à la Section 11).

6.1 Définition des filtres de préfixe

Ce paragraphe fait la liste des filtres de préfixe les plus couramment utilisés. Les paragraphes qui suivent vont préciser où ces filtres devrait être appliqués.

6.1.1 Préfixes d'utilisation particulière 6.1.1.1 Préfixes IPv4 d'utilisation particulière

Le registre des adresses IPv4 d'utilisation particulière de l'IANA [IANA-SPIPv4] tient la liste des préfixes IPv4 d'utilisation particulière et de leur portée d'acheminement, et il DEVRAIT être utilisé pour la configuration des filtres de préfixes. Les préfixes avec la valeur "Faux" dans la colonne "Global" DEVRAIENT être éliminés sur les échanges Internet d'homologue à homologue BGP.

6.1.1.2 Préfixes IPv6 d'utilisation particulière

Le registre des adresses IPv6 d'utilisation particulière de l'IANA [IANA-SPIPv6] tient la liste des préfixes IPv6 d'utilisation particulière et de leur portée d'acheminement, et il DEVRAIT être utilisé pour la configuration des filtres de préfixes. Seuls les préfixes avec la valeur "Faux" dans la colonne "Global" DEVRAIENT être éliminés sur les échanges Internet d'homologue à homologue BGP.

6.1.2 Préfixes non alloués

L'IANA alloue des préfixes aux registraires régionaux de l’Internet (RIR, Regional Internet Registry) qui à leur tour allouent les préfixes aux registraires locaux (LIR, Local Internet Registry). Il est sage de ne pas accepter les préfixes de tableau d'acheminement qui ne sont pas alloués par l'IANA et/ou les RIR. Ce paragraphe détaille les options pour construire une liste des préfixes alloués à chaque niveau. Il est important de comprendre que le filtrage des préfixes non alloués exige des mises à jour constantes, car les préfixes sont continuellement alloués. Donc, l'automatisation de tels filtres de préfixes est une clé du succès de cette approche. Les administrateurs de réseau NE DEVRAIENT PAS considérer les solutions décrites dans cette section si ils ne sont pas capables de tenir à jour les filtres de préfixes : les dommages seraient probablement pires que la politique de sécurité voulue.

6.1.2.1 Filtres de préfixe alloués par l'IANA

L'IANA a alloué tout l'espace IPv4 disponible. Donc, il n'y a pas de raison pour que les administrateurs de réseau continuent de vérifier que les préfixes qu'ils reçoivent de leurs homologues BGP sont dans l'espace d'adresse IPv4 alloué par l'IANA [IANA-IPv4]. Aucun filtre spécifique n'a besoin d'être mis en place par les administrateurs qui veulent s'assurer que les préfixes IPv4 qu'ils reçoivent dans les mises à jour BGP ont été alloués par l'IANA.

Pour IPv6, étant donnée la taille de l'espace d'adresses, il peut être sage de n'accepter que les préfixes déduits de ceux alloués par l'IANA. Les administrateurs peuvent construire dynamiquement cette liste à partir de l'espace IPv6 alloué par l'IANA [IANA-IPv6]. Comme l'IANA continue d'allouer des préfixes aux RIR, la liste sus-mentionnée devrait être vérifiée régulièrement pour y voir les changements, et quand ils se produisent, des filtres de préfixes devraient être calculés et poussés sur les appareils du réseau. La liste pourrait aussi être tirée directement par les routeurs quand ils mettent en œuvre de tels mécanismes. Comme il y a un délai entre le moment où un RIR reçoit un nouveau préfixe et le moment ou il commence à en allouer des portions à ses LIR, Il n'est pas nécessaire de faire cela très rapidement et très fréquemment. Cependant, les administrateurs de réseau DEVRAIENT s'assurer que tous les filtres de préfixe IPv6 sont mis à jour dans un délai maximum d'un mois après un changement sur la liste des préfixes IPv6 alloués par l'IANA.

(5)

Si le processus en place (qu'il soit manuel ou automatique) ne peut pas garantir que la liste est mise à jour régulièrement, il vaut alors mieux ne configurer aucun filtre fondé sur les réseaux alloués. L'expérience de IPv4 a montré que de nombreux opérateurs de réseau mettent en œuvre des filtres pour des préfixes non alloués par l'IANA mais ne les mettent pas à jour de façon régulière. Cela a créé des problèmes pour les dernières allocations, et a exigé un travail supplémentaire pour les RIR qui ont eu à "dédiaboliser" les nouveaux préfixes alloués. (Voir dans [RIPE351] des informations sur la "dédiabolisation".) 6.1.2.2 Filtres de préfixe alloués par des RIR

Une vérification plus précise peut être effectuée quand on veut s’assurer que les préfixes qu'on reçoit ont bien pour origine, ou ont transité, par des systèmes autonomes (AS) en droit de le faire. Il a été observé dans le passé qu'un AS pouvait facilement annoncer le préfixe (ou des préfixes plus spécifiques) de quelqu'un d'autre et créer des trous noirs ou des menaces pour la sécurité. Pour atténuer partiellement ce risque, les administrateurs vont avoir besoin de s'assurer que les annonces de BGP correspondent aux informations contenues dans les registres existants. À ce stade, deux options peuvent être envisagées : à court terme, et à long terme. Elles sont décrites ci-après.

6.1.2.2.1 Filtres de préfixe créées à partir de registres d'acheminement Internet (IRR)

Un registre des acheminements de l'Internet (IRR, Internet Routing Registry) est une base de données qui contient les informations d'acheminement de l'Internet, décrite en utilisant les objets du langage de spécification de politique d'acheminement décrit dans la [RFC4012]]. Les administrateurs de réseau ont les privilèges de décrire les politiques d'acheminement de leurs propres réseaux dans l'IRR, et ces informations sont publiées, en général. Une majorité de registraires régionaux de l'Internet ont aussi un IRR et peuvent contrôler si les chemins enregistrés se conforment aux préfixes alloués ou directement affectés. Cependant, on devrait noter que la liste de ces préfixes n'est pas nécessairement complète, et à ce titre, une telle liste des routes dans un IRR n'est pas la même que l'ensemble des préfixes alloués par l'IRR.

Il est possible d'utiliser les information d'IRR pour construire, pour un certain AS voisin, une liste des préfixes d'origine ou de transit qu'on peut accepter. Ceci peut être fait relativement facilement en utilisant des scripts et des outils existants capables de restituer ces informations des registres. Cette approche est exactement la même pour IPv4 et IPv6.

Le macro algorithme pour le script est comme suit : pour l'homologue considéré, l'administrateur de réseau distant a fourni l'AS et peut être capable de fournir un objet AS-SET (aussi appelé AS-MACRO). Un AS-SET est un objet qui contient des numéros d'AS ou d'autres AS-SET. Un opérateur peut créer un AS-SET définissant tous les numéros d'AS de ses abonnés. Un fournisseur de transit "Tier 1" peut créer un AS-SET décrivant l'AS-SET des opérateurs connectés, qui à leur tour décrivent les numéros d'AS de leurs abonnés. En utilisant la récurrence, il est possible de restituer à partir d'un AS-SET la liste complète des numéros d'AS que l'homologue va probablement annoncer. Pour chacun de ces numéros d'AS, il est aussi facile de regarder dans l'IRR correspondant tous les préfixes associés. Avec ces deux mécanismes, un script peut être construit, pour un certain homologue, donnant la liste des préfixes permis et le numéro d'AS à partir duquel ils devraient être générés. On pourrait décider de ne pas utiliser les informations d'origine et de seulement construire des filtres monolithiques de préfixes à partir des données collectées.

Comme les préfixes, les numéros d'AS, et les AS-SET peuvent n'être pas tous sous la même autorité de RIR, il est difficile de choisir pour chaque objet l'IRR approprié à interroger. Certains IRR ont été créés et ne sont pas restreints à une certaine région ou RIR d'autorité. Cela permet aux RIR de publier les informations contenues dans leur IRR dans un lieu commun. Cela rend aussi possible à tout abonné (probablement en vertu d'un contrat) de publier aussi les informations. Quand on fait des demandes à l'intérieur d'un tel IRR, il est possible de spécifier la source de l'information afin d'avoir les données les plus fiables. On pourrait vérifier avec un IRR très populaire qui contient de nombreuses sources (comme [RADb], la base de données des biens d'acheminement) et ne choisir comme sources que certains RIR désirés et les fournisseurs d'accès Internet de confiance.

Comme les objets dans les IRR peuvent fréquemment varier au fil du temps, il est important que les filtres de préfixes calculés en utilisant ce mécanisme soient rafraîchis régulièrement. Rafraîchir les filtres quotidiennement DEVRAIT être envisagé parce que les changements d'acheminement doivent parfois être faits dans l'urgence et les registres peuvent être mis à jour au tout dernier moment. Noter que cette approche augmente significativement la complexité des configurations de routeur, car cela peut ajouter rapidement des dizaines de milliers de lignes de configuration pour certains homologues importants. Pour gérer cette complexité, les administrateurs de réseau pourraient utiliser, par exemple, l'ensemble d'outils d'IRR [IRTT], qui rend possible de simplifier la création automatique de configuration de filtres à partir de politiques mémorisées dans un IRR.

Enfin, mais pas le moins important, les administrateurs de réseau DEVRAIENT publier et tenir l'état approprié de leurs ressources dans la base de données d'IRR tenue par leur RIR, quand il est disponible.

6.1.2.2.2 Acheminement inter domaines sûr (SIDR)

(6)

Une infrastructure appelée acheminement inter domaines sûr (SIDR, Secure Inter-Domain Routing) décrite dans la [RFC6480], a été conçue pour sécuriser les annonces Internet. Au moment de la rédaction du présent document, de nombreux textes ont été publiés et un cadre avec un ensemble complet de protocoles est proposé de sorte que les annonces puissent être vérifiées par rapport à des objets d'acheminement signés dans les RIR. Il y a fondamentalement deux services offerts par le SIDR :

o La validation de l'origine, décrite dans la [RFC6811], cherche à s'assure que les attributs associés aux routes sont corrects.

(Le point majeur est la validation du numéro d'AS à l'origine d'une certaine route.) La validation d'origine est maintenant opérationnelle (registres Internet, protocoles, mis en œuvre sur certains routeurs) et en théorie elle peut être mise en œuvre en sachant que le nombre de ressources signées est encore faible au moment de la rédaction du présent document.

o La validation de chemin fournie par BGPsec [RFC7353] cherche à s'assurer que personne n'annonce de faux/mauvais chemins BGP qui pourraient attirer du trafic pour une certaine destination ; voir la [RFC7132]. BGPsec est encore un sujet de travaux en cours au moment de la rédaction du présent document et ne peut donc pas être mis en œuvre (voir RFC8205).

La mise en œuvre des mécanismes de SIDR est supposée résoudre beaucoup des problèmes de sécurité de l'acheminement de BGP à long terme, mais il peut se passer du temps avant que des déploiements soient faits et que les objets soient signés.

Aussi, on notera que l'infrastructure SIDR est complémentaire (elle ne remplace pas) des bonnes pratiques de sécurité décrites dans le présent document. Donc, les administrateurs de réseau DEVRAIENT mettre en œuvre tout mécanisme proposé par SIDR (par exemple, la validation d'origine de chemin) par dessus les autres mécanismes existants même si ils peuvent parfois apparaître comme visant le même but.

Si la validation d'origine de chemin est mise en œuvre, le lecteur DEVRAIT se référer aux règles décrites dans la [RFC7115].

En bref, chaque route externe reçue sur un routeur DEVRAIT être vérifiée par rapport à l'ensemble de données de l'infrastructure de clé publique de ressource (RPKI, Resource Public Key Infrastructure) :

o si une autorisation d'origine de route (ROA, Route Origin Authorization) correspondante est trouvée et est valide, alors le préfixe DEVRAIT être accepté ;

o si le ROA est trouvé et est INVALIDE, le préfixe DEVRAIT alors être éliminé ;

o si on ne trouve pas de ROA, le préfixe DEVRAIT alors être accepté, mais la route correspondante DEVRAIT recevoir une préférence basse.

En plus de cela, les administrateurs de réseau DEVRAIENT signer leurs objets d'acheminement afin que leurs routes puissent être validées par les autres réseaux qui effectuent la validation d'origine.

On devrait comprendre que le modèle RPKI apporte de nouveaux défis intéressants. L'article "Sur les risques que des autorités de RPKI se comportent mal" [RPKI] explique comment le modèle RPKI peut impacter l'Internet si les autorités ne se comportent pas comme elles sont supposées. Une analyse plus poussée de RPKI est certainement nécessaire car elle porte une partie de la sécurité de BGP.

6.1.3 Préfixes qui sont trop spécifiques

La plupart des fournisseurs d'accès Internet (FAI) ne vont pas accepter les annonces au delà d'un certain niveau de spécificité (et en retour, ils n'annoncent pas les préfixes qu'ils considèrent comme trop spécifiques). Cette spécificité acceptable est décidée pour chaque échange d'homologue à homologue entre deux homologues BGP. Certaines communautés de FAI ont essayé de documenter la spécificité acceptable. Le présent document ne porte aucun jugement sur ce qui est la meilleure approche, il note juste qu'il y a des pratiques existantes sur l'Internet et recommande que le lecteur s'y rapporte. Par exemple, la communauté RIPE a documenté que, au moment de la rédaction du présent document, les préfixes IPv4 plus longs que /24 et les préfixes IPv6 plus longs que /48 ne sont généralement ni annoncés ni acceptés dans l'Internet [RIPE399] [RIPE532].

Ces valeurs pourront changer à l'avenir.

6.1.4 Filtres de préfixe appartenant à l'AS locale et à l'aval

Un réseau DEVRAIT filtrer ses propres préfixes sur les échanges d'homologue à homologue avec tous ses homologues (direction entrante). Cela empêche le trafic local (d'une source locale à une destination locale) de fuiter sur un échange d'homologue à homologue externe, au cas où quelqu'un d'autre annoncerait le préfixe sur l'Internet. Cela protège aussi l'infrastructure qui peut souffrir directement si le préfixe de cœur de réseau est soudain préféré sur l'Internet.

Dans certains cas, par exemple, dans des scénarios de multi rattachement, de tels filtres NE DEVRAIENT PAS être appliqués, car cela pourrait casser la redondance désirée.

Dans une certaine mesure, de tels filtres peuvent aussi être configurés sur un réseau pour les préfixes vers l'aval afin de les protéger aussi. De tels filtres doivent être définis avec précaution car ils peuvent casser les mécanismes de redondance existants. Par exemple, quand un opérateur a un abonné multi rattachements, il devrait continuer d'accepter le préfixe de l'abonné en provenance de ses homologues et vers l'amont. Cela va rendre possible à l'abonné de continuer d’accéder au réseau

(7)

de son opérateur (et aux autres abonnés) via l'Internet même si l'échange d'homologue à homologue BGP entre l'abonné et l'opérateur est interrompu.

6.1.5 Préfixes de LAN IXP 6.1.5.1 Sécurité réseau

Quand un réseau est présent sur un IXP et que des homologues avec d'autres membres IXP sur un sous réseau commun (préfixe de LAN IXP) il NE DEVRAIT accepter des préfixes plus spécifiques pour le préfixe de LAN IXP de la part d'aucun de ses homologues BGP externes. Accepter ces routes peut créer un trou noir pour la connectivité au LAN IXP.

Si le préfixe de LAN IXP est accepté comme une "correspondance exacte", il faut prendre soin d'empêcher d'autres routeurs dans le réseau d'envoyer du trafic IXP vers le préfixe de LAN IXP appris de l'extérieur (recherche récurrente de route pointant sur la mauvaise direction). Cela peut être réalisé en préférant les routes IGP aux BGP externes (EBGP) ou en utilisant "l'auto prochain bond BGP" sur toutes les routes apprises sur cet IXP.

Si le préfixe de LAN IXP est accepté, il DEVRAIT n'être accepté que des AS que le IXP autorise à l'annoncer -- cela va généralement être automatiquement réalisé par le filtrage des annonces qui utilisent la base de données IRR.

6.1.5.2 PMTUD et le problème de uRPF lâche

Afin que la PMTUD fonctionne en présence de uRPF lâches, il est nécessaire que tous les réseaux qui peuvent générer du trafic qui pourrait s'écouler à travers le IXP (c’est-à-dire, les membres IXP et leurs nœuds vers l'aval) aient une route pour le préfixe de LAN IXP. Ceci est nécessaire car un message ICMP "paquet trop gros" envoyé par les routeurs des membres IXP peut être sourcé en utilisant une adresse du préfixe de LAN IXP. En présence de uRPF lâche, ce paquet ICMP est éliminé si il n'y a pas de route pour ce préfixe de LAN IXP ou une route moins spécifique couvrant le préfixe de LAN IXP.

Dans ce cas, tout membre IXP DEVRAIT s'assurer qu'il a une route pour le préfixe de LAN IXP ou un préfixe moins spécifique que tous ses routeurs et qu'il annonce le préfixe de LAN IXP ou le chemin moins spécifique (jusqu'à une route par défaut) à ses nœuds vers l'aval. Les annonces faites pour cela DEVRAIENT passer par des filtres générés par l'IRR décrit au paragraphe 6.1.2.2.1 ainsi que les filtres de "préfixes qui sont trop spécifiques" décrites au paragraphe 6.1.3. La façon la plus aisée de mettre cela en œuvre est que le IXP lui-même prenne soin de l'origine de son préfixe et l'annonce à tous les membres IXP à travers un échange d'homologue à homologue BGP. Très vraisemblablement, les serveurs d'acheminement BGP vont être utilisés pour cela, et le IXP va envoyer son préfixe entier, qui va être égal, ou moins spécifique, au préfixe de LAN IXP.

L'Appendice A donne un exemple de lignes directrices concernant le préfixe de LAN IXP.

6.1.6 Chemin par défaut 6.1.6.1 IPv4

Normalement, le préfixe 0.0.0.0/0 n'est pas destiné à être accepté ou annoncé sauf dans des configurations spécifiques d'abonné/fournisseur ; le filtrage général en dehors de ces cas est RECOMMANDÉ.

6.1.6.2 IPv6

Normalement, le préfixe ::/0 n'est pas destiné à être accepté ou annoncé sauf dans des configurations spécifiques d'abonné/fournisseur ; le filtrage général en dehors de ces cas est RECOMMANDÉ.

6.2 Recommandations de filtrage de préfixe dans les réseaux à acheminement complet

Pour les réseaux qui ont le tableau BGP Internet complet, certaines politiques devraient être appliquées sur chaque homologue BGP pour les routes reçues et annoncées. Il est RECOMMANDÉ que chaque système autonome configure des règles pour les routes annoncées et reçues à toutes ses frontières, car cela va protéger le réseau et son homologue même dans le cas de mauvaise configuration. La politique de filtrage la plus couramment utilisée est proposée dans ce paragraphe et utilise les filtres de préfixe définis au paragraphe 6.1.

6.2.1 Filtres avec homologues Internet 6.2.1.1 Filtrage entrant

Il y a fondamentalement deux options -- l'option lâche où aucune vérification ne va être faite à l'égard des allocations de RIR et la stricte où il va être vérifié que les annonces se conforment strictement à ce qui est déclaré dans les registres d'acheminement.

(8)

6.2.1.1.1 Filtrage entrant option lâche

Dans ce cas, les préfixes suivants reçus d'un homologue BGP vont être filtrés : o préfixes qui ne sont pas acheminables mondialement (paragraphe 6.1.1) o préfixes non alloués par l'IANA (IPv6 seulement) (paragraphe 6.1.2.1) o routes qui sont trop spécifiques (paragraphe 6.1.3)

o préfixes qui appartiennent à l'AS local (paragraphe 6.1.4) o préfixes de LAN IXP (paragraphe 6.1.5)

o route par défaut (paragraphe 6.1.6)

6.2.1.1.2 Filtrage entrant option stricte

Dans ce cas, des filtres sont appliqués pour s'assurer que les annonces se conforment strictement à ce qui est déclaré dans les registres d'acheminement (paragraphe 6.1.2.2). Les registres ne sont pas toujours précis (préfixes manquants, informations inexactes, etc.). Cela varie selon les registres et les régions de l'Internet. Avant d'appliquer une politique stricte, le lecteur DEVRAIT vérifier l'impact sur le filtre et s'assurer que la solution n'est pas pire que le problème.

Aussi, en cas de défaillance du script, chaque administrateur peut décider si toutes les routes sont acceptées ou rejetées selon la politique d'acheminement. Alors qu'accepter les routes durant cette période pourrait mettre en danger la sécurité de l'acheminement BGP, les rejeter pourrait réacheminer trop de trafic sur les homologues de transit, et pourrait causer plus de dommages que ce qu'aurait pu faire une politique lâche.

En plus de cela, les administrateurs de réseau pourraient appliquer les filtres suivants par avance au cas où le registre d'acheminement qui est utilisé comme source d'informations par le script ne serait pas totalement de confiance :

o les préfixes qui ne sont pas mondialement acheminables (paragraphe 6.1.1) o les routes qui sont trop spécifiques (paragraphe 6.1.3)

o les préfixes qui appartiennent à l'AS local (paragraphe 6.1.4) o les préfixes de LAN IXP (paragraphe 6.1.5)

o la route par défaut (paragraphe 6.1.6) 6.2.1.2 Filtrage sortant

La configuration devrait assurer que seuls les préfixes appropriés sont envoyés. Ce peut être, par exemple, les préfixes qui appartiennent à la fois au réseau en question et à ceux qui lui sont à l'aval. Cela peut être réalisé en utilisant les communautés BGP, les chemins d'AS, ou les deux. Aussi, il peut être souhaitable d'ajouter les filtres suivants avant toute politique pour éviter les annonces de route indésirables à cause d'une mauvaise configuration :

o les préfixes de LAN IXP (paragraphe 6.1.5) o la route par défaut (paragraphe 6.1.6)

Si il est possible de faire la liste des préfixes à annoncer, il est alors suffisant de juste configurer la liste des préfixes permis et de refuser le reste.

6.2.2 Filtres avec consommateurs 6.2.2.1 Filtrage entrant

La politique d'entrée à l'égard des clients finaux est très simple : seuls les préfixes de consommateurs DEVRAIENT être acceptés, tous les autres DEVRAIENT être éliminés. La liste des préfixes acceptés peut être spécifiée manuellement, après avoir vérifié qu'ils sont valides. Cette validation peut être faite avec les autorités de gestion des adresses IP appropriées.

Les mêmes règles s'appliquent quand le consommateur est un réseau qui connecte d'autres clients (par exemple, un fournisseur de transit Tier 1 qui connecte des fournisseurs de service). Une exception est quand le réseau consommateur applique un strict filtrage de préfixe entrant/sortant, et qu'il y a trop de préfixes annoncés par ce réseau pour en faire la liste dans la configuration de routeur. Dans ce cas, les filtres comme ceux du paragraphe 6.2.1.1 peuvent être appliqués.

6.2.2.2 Filtrage sortant

La politique se sortie avec les consommateurs peut varier selon les routes que le consommateur veut recevoir. Dans le scénario le plus simple possible, le consommateur peut vouloir ne recevoir que la route par défaut ; ce peut être facilement fait en appliquant un filtre avec seulement la route par défaut.

Dans le cas où le consommateur veut recevoir l'acheminement complet (si il est multi rattachements ou si il veut avoir une vue du tableau de l'Internet) les filtres suivants peuvent être appliqués à l'échange d'homologue à homologue BGP :

(9)

o la route par défaut (paragraphe 6.1.6)

Dans certains cas, le consommateur peut désirer recevoir la route par défaut en plus du tableau BGP complet. Ceci peut être fait simplement par le fournisseur en retirant le filtre pour la route par défaut. Comme la route par défaut peut n'être pas présente dans le tableau d'acheminement, les administrateurs de réseau peuvent décider de ne la générer que pour les échanges d'homologue à homologue où elle doit être annoncée.

6.2.3 Filtres avec fournisseurs amont 6.2.3.1 Filtrage entrant

Si le tableau d'acheminement complet est désiré de vers l'amont, le filtrage de préfixe à appliquer est le même que celui pour les homologues du paragraphe 6.2.1.1 à l'exception de la route par défaut. Parfois, la route par défaut (en plus du tableau BGP complet) peut être désirée d'un fournisseur vers l'amont. Si le fournisseur vers l'amont est supposé annoncer seulement la route par défaut, un filtre simple sera appliqué pour n'accepter que le préfixe par défaut et rien d'autre.

6.2.3.2 Filtrage sortant

Les filtres à appliquer ne vont très probablement pas beaucoup différer de ceux appliqués pour les homologues Internet (paragraphe 6.2.1.2). Cependant, des politiques différentes pourraient être appliquées si un réseau particulier vers l'amont ne devait pas fournir le transit à tous les préfixes.

6.3 Recommandations de filtrage de préfixe pour les réseaux d'extrémité 6.3.1 Filtrage entrant

Le réseau d'extrémité va déployer les filtres correspondant aux routes qu'il demande vers l'amont. Si une route par défaut est demandée, un simple filtre entrant peut être appliqué pour n'accepter que la route par défaut (paragraphe 6.1.6). Si le réseau d'extrémité n'est pas capable de faire la liste des préfixes parce qu'il y en a trop (par exemple, si cela exige le tableau complet de l'acheminement Internet) il devrait alors configurer les filtres suivants pour éviter de recevoir de mauvaises annonces de vers l'amont :

o préfixes non acheminables (paragraphe 6.1.1) o routes trop spécifiques (paragraphe 6.1.3)

o préfixes appartenant à l'AS local (paragraphe 6.1.4)

o route par défaut (paragraphe 6.1.6) selon que la route est ou non demandée.

6.3.2 Filtrage sortant

Un réseau d'extrémité va très probablement avoir une politique très directe : il va seulement annoncer ses routes locales. Il peut aussi configurer les filtres de préfixe décrits au paragraphe 6.2.1.2 pour éviter d'annoncer des routes invalides à son fournisseur vers l'amont.

7. Atténuation de fluctuations de chemin BGP

Le mécanisme d'atténuation de fluctuations de chemin de BGP rend possible d'appliquer des pénalités aux routes chaque fois qu'elles changent dans le tableau d'acheminement BGP. Initialement, ce mécanisme a été créé pour protéger l'entier Internet de divers événements qui impactent un seul réseau. Les études ont montré que les mises en œuvre de l'atténuation des fluctuations de chemin BGP pouvaient causer beaucoup plus de dommages que d'avantages ; donc, dans le passé, la communauté RIPE a fait des recommandations contre l’utilisation de l'atténuation des fluctuations de chemin BGP [RIPE378]. Ultérieurement, des études ont été effectuées pour proposer de nouveaux seuils d'atténuation de fluctuation de route afin de rendre la solution

"utilisable" ; voir la [RFC7196] et [RIPE580] (dans lequel RIPE a révisé ses recommandations). Le présent document RECOMMANDE de suivre les recommandations de l'IETF et de RIPE et d'utiliser l'atténuation des fluctuations de chemin BGP avec les seuils configurés ajustés.

8. Préfixes maximum sur une relation d'homologue à homologue

Il est RECOMMANDÉ de configurer une limite au nombre de routes à accepter d'un homologue. Les règles suivantes sont généralement RECOMMANDÉES :

(10)

o De la part des homologues, il est RECOMMANDÉ d'avoir une limite inférieure au nombre de routes dans l'Internet. Cela va clore l'échange d'homologue à homologue BGP si l'homologue annonce soudain le tableau complet. Les administrateurs de réseau peuvent aussi configurer des limites différentes pour chaque homologue, selon le nombre de routes qu'ils sont supposés annoncer, plus un peu de place pour permettre la croissance.

o De la part de l'amont qui fournit l'acheminement complet, il est RECOMMANDÉ d'avoir une limite supérieure au nombre de routes dans l'Internet. Une limite est quand même utile afin de protéger le réseau (et en particulier, la mémoire des routeur) si trop de routes sont envoyées de l'amont. La limite devrait être choisie selon le nombre de routes qui peuvent réellement être traitées par les routeurs.

Il est important de revoir régulièrement ces limites qui sont configurées alors que les changements de l'Internet peuvent survenir rapidement. Certains fabricants proposent des mécanismes pour avoir deux seuils : tandis que le chiffre supérieur spécifié va clore l'échange d'homologue à homologue, le premier seuil va seulement déclencher un enregistrement d'événement et peut être utilisé pour ajuster passivement les limites sur la base des observations faites sur le réseau.

9. Filtrage de chemin d'AS

Cette section fait la liste des pratiques RECOMMANDÉES lors du traitement des chemins d'AS BGP.

o Les administrateurs de réseau DEVRAIENT accepter des consommateurs que des chemins d'AS de deux ou quatre octets contenant les ASN qui appartiennent au consommateur (ou sont autorisés à transiter à travers lui). Si les administrateurs de réseau ne peuvent pas construire et générer des expressions de filtrage pour mettre cela en œuvre, ils DEVRAIENT envisager de n'accepter que les longueurs de chemin pertinentes pour le type de consommateur qu'ils ont (comme dans le cas ou ces consommateurs sont une extrémité ou qu'ils ont des consommateurs en propre) et DEVRAIENT essayer de décourager des ajouts excessifs sur de tels chemins. Cette politique lâche pourrait être combinée avec des filtres pour des chemins d'AS spécifiques à deux ou quatre octets qui ne doivent pas être acceptés si il sont annoncés par le consommateur, comme des fournisseurs de transit vers l'amont ou des ASN homologues.

o Les administrateurs de réseau NE DEVRAIENT PAS accepter des préfixes avec des numéros d'AS privés dans le chemin d'AS sauf si les préfixes viennent des consommateurs. Une exception pourrait survenir quand l'amont offre un service particulier comme la génération d'un trou noir sur la base d'un numéro d'AS privé : dans ce cas, les préfixes DEVRAIENT être acceptés. Les consommateurs devraient être informées par l'amont afin de mettre en place une politique ad hoc pour utiliser de tels services.

o Les administrateurs de réseau NE DEVRAIENT PAS accepter des préfixes quand le premier numéro d'AS dans ce chemin d'AS n’est pas celui de l'homologue sauf si l'échange d'homologue à homologue est fait vers un serveur d'acheminement BGP [RFC7947] (par exemple, sur un IXP) avec un traitement transparent du chemin d'AS. Dans ce cas, cette vérification doit être désactivée, car le premier numéro d'AS va être celui d'un membre IXP, tandis que le numéro d'AS de l'homologue va être celui du serveur d'acheminement BGP.

o Les administrateurs de réseau NE DEVRAIENT PAS annoncer des préfixes avec un chemin d'AS non vide sauf si ils ont l'intention de fournir le transit pour ces préfixes.

o Les administrateurs de réseau NE DEVRAIENT PAS annoncer des préfixes avec des numéros d'AS vers l'amont dans le chemin d'AS à leur AS homologue sauf si ils ont l'intention de fournir le transit pour ces préfixes.

o Les numéros d'AS privés sont conventionnellement utilisés dans des contextes qui sont "privés" et NE DEVRAIENT PAS être utilisés dans les annonces aux homologues BGP qui ne font pas partie de tels arrangements privés, et ils DEVRAIENT être supprimés quand ils sont reçus d'homologues BGP qui ne font pas partie des arrangements privés.

o Les administrateurs de réseau NE DEVRAIENT PAS outrepasser le comportement par défaut de BGP, c'est-à-dire, ils ne devraient pas accepter leur propre numéro d'AS dans le chemin d'AS. Quand on envisage une exception, l'impact (qui peut être sévère sur l'acheminement) devrait être étudié avec attention.

Le filtrage de chemin d'AS devrait être plus analysé quand la dénumérotation d'ASN est effectuée. Une telle opération est courante, et des mécanismes existent pour permettre une migration en douceur de l'ASN [RFC7705]. La technique usuelle de migration, locale pour un routeur, consiste à modifier le chemin d'AS de sorte qu'il soit présenté à un homologue avec l'ASN précédant, comme si aucune dénumérotation n'avait été faite. Cela rend possible de changer l'ASN d'un routeur sans reconfigurer tous les homologues EBGP en même temps (car cette opération exigerait la synchronisation avec tous les homologues rattachés à ce routeur). Durant cette opération de dénumérotation, les règles décrites ci-dessus peuvent être ajustées.

(11)

10. Filtrage de prochain bond

Si l'échange d'homologue à homologue se fait sur un réseau partagé, comme un IXP, BGP peut annoncer les préfixes avec un prochain bond de tiers, dirigeant donc les paquets non sur l'homologue annonçant le préfixe mais quelque part ailleurs.

C'est une propriété désirable pour les établissements de serveurs d'acheminement BGP [RFC7947], où le serveur d'acheminement va relayer les informations d'acheminement mais n'a ni la capacité ni le désir de recevoir les paquets de données réels. Ainsi, le serveur d'acheminement BGP va annoncer les préfixes avec un réglage de prochain bond pointant sur le routeur qui a à l'origine annoncé le préfixe au serveur d'acheminement.

Dans l'échange d'homologue à homologue direct entre FAI, ceci est indésirable, car un des homologues pourrait tromper l'autre en envoyant des paquets dans un trou noir (prochain bond inaccessible) ou sur un tiers non soupçonneux qui aurait alors à écouler le trafic. En particulier pour l'envoi sur un trou noir, la racine du problème est difficile à voir sans inspecter les préfixes BGP au routeur receveur de l'IXP.

Donc, une politique d'acheminement entrant DEVRAIT être appliquée aux échanges d'homologue à homologue IXP afin de régler le prochain bond sur des préfixes acceptés de l'adresse IP de l'homologue BGP (appartenant au LAN IXP) qui a envoyé le préfixe (ce qui est ce que "l'auto prochain bond" appliquerait sur le côté envoyeur).

Cette politique NE DEVRAIT PAS être utilisée sur les échanges d'homologue à homologue de serveur d'acheminement ou sur des échanges d'homologue à homologue où les administrateurs de réseau permettent intentionnellement à l'autre côté d'envoyer des prochains bonds de tiers.

Cette politique DEVRAIT aussi être ajustée si les bonnes pratiques de déclenchement à distance de trou noir (RTBH, Remote Triggered Black Holing) [RFC6666] sont mises en œuvre. Dans ce cas, les administrateurs de réseau vont appliquer un prochain bond BGP bien connu pour les routes qu'ils veulent filtrer (si une menace Internet est observée de/vers cette route, par exemple). Ce prochain bond bien connu va être acheminé statiquement sur une interface nulle. En combinaison avec une vérification RPF en envoi individuel, cela va éliminer le trafic de et vers ce préfixe. Les homologues peuvent échanger des informations sur les trous noir en utilisant, par exemple, des communautés BGP particulières. Les administrateurs de réseau pourraient propager des informations de trou noir à leurs homologues en utilisant une communauté BGP sur laquelle ils se sont mis d'accord : quant ils reçoivent une route avec cette communauté, une politique configurée pourrait changer le prochain bond afin de créer le trou noir.

11. Nettoyage de communauté BGP

Facultativement, on peut envisager le règles suivantes sur les chemins d'AS BGP :

o Les administrateurs de réseau DEVRAIT nettoyer les communautés entrantes avec leur numéro dans l'ordre des bits de poids fort, et permettre seulement les communautés dont les consommateurs/homologues peuvent l'utiliser comme mécanisme de signalisation

o Les administrateurs de réseau NE DEVRAIT PAS supprimer les autres communautés appliquées sur les routes reçues (communautés non supprimées après application de la déclaration précédente). En particulier, ils DEVRAIENT garder les communautés d'origine quand elles appliquent une communauté. Les consommateurs peuvent avoir besoin d'elles pour communiquer avec des fournisseurs vers l'amont. En particulier, les administrateurs de réseau NE DEVRAIENT PAS (généralement) supprimer la communauté "no-export", car elle est généralement annoncée par leur homologue dans un certain but.

12. Considérations sur la sécurité

Le présent document est entièrement consacré à la sécurité du fonctionnement de BGP. Il décrit les meilleures pratiques que chacun devrait adopter pour sécuriser l'infrastructure BGP : protéger le routeur BGP et les sessions BGP, adopter un préfixe BGP et des filtres de chemin d'AS cohérents, et configurer les autres options pour sécuriser les réseaux BGP.

Le présent document ne vise pas à décrire les mises en œuvre BGP existantes, les vulnérabilités potentielles, ou les façons dont elles traitent les erreurs. Il ne précise pas comment la protection pourrait être appliquée contre les techniques d'attaque qui utilisent des paquets truqués.

(12)

13. Références

13.1 Références normatives

[RFC2119] S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC4271] Y. Rekhter, T. Li et S. Hares, "Protocole de routeur frontière version 4 (BGP-4)", janvier 2006. (D.S.) (MàJ par RFC6608, RFC8212)

[RFC5082] V. Gill et autres, "Mécanisme de sécurité de TTL généralisé (GTSM)", octobre 2007. (P.S. ; Remplace RFC3682) [RFC5925] J. Touch, A. Mankin, R. Bonica, "Option Authentification de TCP", juin 2010. (Remplace RFC2385). (P. S.) [RFC6811] P. Mohapatra, et autres, "Validation d’origine de préfixe BGP", janvier 2013. (P;S; ; MàJ par RFC8481 [RFC7196] C. Pelsser et autres, "Rendre utilisables les amortissements de fluctuations de chemins", mai 2014 (P.S.)

13.2 Références pour information

[IANA-SPIPv6] IANA, "IANA IPv6 Special-Purpose Address Registry", < http://www.iana.org/assignments/iana-ipv6- special-registry >.

[IANA-IPv4] IANA, "IANA IPv4 Address Space Registry", < http://www.iana.org/assignments/ipv4-address-space >.

[IANA-SPIPv4] IANA, "IANA IPv4 Special-Purpose Address Registry", < http://www.iana.org/assignments/iana-ipv4- special-registry >.

[IANA-IPv6] IANA, "Internet Protocol Version 6 Address Space", < http://www.iana.org/assignments/ipv6-address-space >.

[IRTT] "IRRToolSet project page", < http://irrtoolset.isc.org >.

[RADb] Merit Network Inc., "Merit RADb", < http://www.radb.net >.

[RFC2385] A. Heffernan, "Protection des sessions de BGP via l'option de signature MD5 de TCP", août 1998. (P.S. ; MàJ par la RFC6691) ; remplacée par RFC5925)

[RFC2827] P. Ferguson, D. Senie, "Filtrage d'entrée de réseau : Combattre les attaques de déni de service qui utilisent l'usurpation d'adresse de source IP", mai 2000. (MàJ par RFC3704) (BCP0038)

[RFC3704] F. Baker, P. Savola, "Filtrage d'entrée pour réseaux à rattachement multiples", mars 2004. (BCP0084)

[RFC4012] L. Blunk et autres, "Langage de spécification de politique d'acheminement de nouvelle génération (RPSLng)", mars 2005. (MàJ les RFC2725, RFC2622) (P.S.)(MàJ par RFC7909)

[RFC6192] D. Dugal, C. Pignataro, R. Dunn, "Protection du plan de contrôle du routeur", mars 2011. (Information)

[RFC6480] M. Lepinski, S. Kent, "Infrastructure pour la prise en charge de l’acheminement Internet sécurisé", février 2012.

(Info.)

[RFC6666] N. Hilliard, D. Freedman, "Préfixe d’élimination pour IPv6", août 2012. (Information)

[RFC6952] M. Jethanandani, K. Patel, L. Zheng, "Analyse des problèmes de BGP, LDP, PCEP, et MSDP selon le guide de conception du chiffrement et de l’authentification des protocoles d’acheminement (KARP)", mai 2013

(Information)

[RFC7115] R. Bush, "Opération de validation d’origine fondée sur l’infrastructure de clé publique de ressource (RPKI)", janvier 2014, (BCP0185).

[RFC7132] S. Kent, A. Chi, "Modèle de menace pour la sécurité de chemin BGP", février 2014. (Information) [RFC7353] S. Bellovin, R. Bush, D. Ward, "Exigences de sécurité pour la validation de chemin BGP", août 2014.

(13)

(Information)

[RFC7705] W. George, S. Amante, "Mécanismes de migration de système autonome et leurs effets sur l'attribut AS_PATH de BGP", novembre 2015. (P.S. ; MàJ RFC4271)

[RFC7947] E. Jasinska, et autres, "Serveur d'acheminement BGP d'échange Internet", septembre 2016. (P.S.) [RIPE351] Karrenberg, D., "RIPE-351 - De-Bogonising New Address Blocks", octobre 2005.

[RIPE378] Smith, P. et C. Panigl, "RIPE-378 - RIPE Routing Working Group Recommendations On Route-flap Damping", mai 2006.

[RIPE399] Smith, P., Evans, R., et M. Hughes, "RIPE-399 - RIPE Routing Working Group Recommendations on Route Aggregation", décembre 2006.

[RIPE532] Smith, P. et R. Evans, "RIPE-532 - RIPE Routing Working Group Recommendations on IPv6 Route Aggregation", novembre 2011.

[RIPE580] Smith, P., Bush, R., Kuhne, M., Pelsser, C., Maennel, O., Patel, K., Mohapatra, P., et R. Evans, "RIPE-580 - RIPE Routing Working Group Recommendations On Route-flap Damping", janvier 2013.

[RPKI] Cooper, D., Heilman, E., Brogle, K., Reyzin, L., et S. Goldberg, "On the Risk of Misbehaving RPKI Authorities", < http://www.cs.bu.edu/~goldbe/papers/hotRPKI.pdf >.

Appendice A. Exemple de filtrage de préfixe de LAN IXP

Un préfixe IPv4 /22 est alloué à un IXP dans la région RIPE par le NCC RIPE (X.Y.0.0/22 dans cet exemple) et il utilise un /23 de ce /22 pour le LAN IXP (disons X.Y.0.0/23). Ce préfixe de LAN IXP est celui utilisé par les membres IXP pour configurer les échanges d'homologue à homologue EBGP. Un numéro d'AS pourrait aussi être alloué à l'IXP (AS64496 dans notre exemple).

Tout membre IXP DEVRAIT s'assurer qu'il filtre les préfixes plus spécifiques que X.Y.0.0/23 provenant de tous ses homologues EBGP. Si il recevait X.Y.0.0/24 ou X.Y.1.0/24 cela pourrait sérieusement impacter son acheminement.

L'IXP DEVRAIT générer X.Y.0.0/22 et l'annoncer à ses membres par un échange d'homologue à homologue EBGP (très vraisemblablement à partir de ses serveurs d'acheminement BGP, configurés avec AS64496).

Les membres IXP DEVRAIENT n'accepter le préfixe IXP que si il passe les filtres générés par l'IRR (voir le paragraphe 6.1.2.2.1).

Les membres IXP DEVRAIENT alors annoncer le préfixe X.Y.0.0/22 vers l'aval. Cette annonce passerait par les filtres fondés sur l'IRR car il est généré par l'IXP.

Remerciements

Les auteurs tiennent à remercier les personnes dont les noms suivent de leurs commentaires et de leur soutien : Marc Blanchet, Ron Bonica, Randy Bush, David Freedman, Wesley George, Daniel Ginsburg, David Groves, Mike Hugues, Joel Jaeggli, Tim Kleefass, Warren Kumari, Jacques Latour, Lionel Morand, Jerome Nicolle, Hagen Paul Pfeifer, Thomas Pinaud, Carlos Pignataro, Jean Rebiffe, Donald Smith, Kotikalapudi Sriram, Matjaz Straus, Tony Tauber, Gunter Van de Velde, Sebastian Wiesinger, et Matsuzaki Yoshinobu.

Les auteurs tiennent à remercier une fois encore Gunter Van de Velde qui a présenté le document à plusieurs réunions de l'IETF dans divers groupes de travail, aidant ainsi à la dissémination de ce document et en collectant de précieux retours.

Adresse des auteurs

Jerome Durand Ivan Pepelnjak Gert Doering

Cisco Systems, Inc. NIL Data Communications SpaceNet AG

(14)

11 rue Camille Desmoulins Tivolska 48 Joseph-Dollinger-Bogen 14

Issy-les-Moulineaux 92782 CEDEX Ljubljana 1000 Muenchen D-80807

France Slovenia Germany

mél : jerduran@cisco.com mél : ip@ipspace.net mél : gert@space.net