Sécurité du Border Gateway Protocol

Ajouter des liens
Un article de Wikipédia, l'encyclopédie libre.
Article principal : Border Gateway Protocol.

La sécurité du Border Gateway Protocol est devenue préoccupante lorsqu'internet s'est ouvert au grand public, au cours des années 1990.

Depuis l’émergence du World Wide Web, les utilisateurs de navigateurs web sollicitent des serveurs aux localisations géographiques diverses. Le fournisseur d'accès à internet n'est généralement pas en mesure d'acheminer le trafic à sa destination finale par l'intermédiaire de sa seule infrastructure de routage. Pour atteindre cet objectif les différents opérateurs d'internet coopèrent. Afin de permettre l’interconnexion entre les réseaux des différents opérateurs d'internet et ainsi de pouvoir acheminer les paquets IP de bout en bout, internet exploite le protocole Border Gateway Protocol (BGP). À ce titre BGP est au cœur de la mise en œuvre d'internet et tout acte de malveillance entraînant son dysfonctionnement a un impact planétaire.

BGP est utilisé au niveau de routeurs spécialisés appelés les annonceurs BGP. Ce protocole consiste en l’échange de chemins d'accès, c'est-à-dire de listes contenant les sous-réseaux pour lesquels le routeur propose du transit. Chaque sous-réseau, le plus souvent géré par une entreprise ou un fournisseur d'accès à Internet, est associé à un système autonome (abrégé « AS ») d'origine ainsi qu'à une liste d'AS qui ont été traversés (généralement des opérateurs de réseau). Chaque organisation qui dispose d'un AS a sa propre politique de routage.

Le protocole BGP, bien que révisé en 2006, date de 1994 et plusieurs incidents liés à une vulnérabilité du protocole ou de son implémentation ont déjà affecté une partie d'internet. Des efforts ont été entrepris par l'Internet Engineering Task Force (IETF), au sein duquel le groupe de travail Secure Inter-Domain Routing (SIDR) est chargé d'améliorer la sécurité du protocole.

Historique[modifier | modifier le code]

Cette frise chronologique détaille l'historique des technologies relatives à la sécurité du Border Gateway Protocol :

De Perlman à la première définition de BGP4[modifier | modifier le code]

Avant même l’avénement de protocole Border Gateway, à la fin des années 1980, des failles de sécurité sont étudiées et répertoriées. C’est le cas en 1988 pour les problèmes byzantins avec Radia Perlman qui est une des premières personnes à publier sur ce domaine, et en 1989 avec les failles de sécurité du protocole de communication Transmission Control Protocol (TCP) décortiquées par Steven M. Bellovin (en)[1], il réétudiera le sujet en 2004[2].

Dans sa thèse Network Layer Protocols with Byzantine Robustness[3], Radia Perlman reconnaît et étudie les problèmes de la sécurisation des infrastructures de routage[2]. En s’appuyant entre autres sur les travaux de Diffie et Hellman, elle y exprime deux solutions : une infrastructure à clés publiques (PKI) impliquant donc la cryptographie asymétrique pour protéger l'intégrité des données, et l'identification des routeurs et de leur voisinage pour mieux connaître la topologie du réseau[4].

En 1992, Ronald Rivest publie pour le compte du Network Working Group le document la RFC 1321[5] où il décrit un algorithme de signature rapide Message Digest 5 (MD5)[glossaire 1] pour les machines 32 bits. Cet algorithme répond partiellement aux problèmes relevés car il permet l’identification des paires voisines d’un routeur et de protéger l’intégrité des données malgré l’utilisation de TCP.

En 1993, Brijesh Kumar étaye les conclusions de Pearlman dans son article “ Integration of security in network routing protocols”[6] où il analyse la présence de la cryptographie dans la sécurisation du routage. Ses conclusions sont que les cryptosystèmes symétriques prendraient trop de ressources mémoires (une clef pour chaque routeur à sauvegarder) et engendreraient autant de calculs qu’il y a de clefs[7] ; Malheureusement, les machines de l’époque ne disposaient pas de la puissance de calcul nécessaire pour l’utilisation de l’infrastructure à clef publique proposée par Perlman [8] qui résoudrait le problème[7]. De plus, il émet la nécessité de regrouper les routeurs dans des domaines, les futurs systèmes autonomes (AS), pour alléger la quantité de ressources requises[9],[10] et fait une distinction entre les routages internes aux domaines (iBGP) et externes (eBGP)[9],[4]

La même année, Brijesh Kumar écrit avec Jon Crowcroft (en) sur l’utilisation d’une signature numérique[11]. Ils mentionnent l'algorithme MD5[12] de Rivest et y ajoutent l’idée de numéroter les mises à jour par des numéros de séquence, pour protéger leur intégrité et fraîcheur[glossaire 2],[13],[14].

En , BGP 4 est une première fois définie dans la RFC 1654[15] pour remplacer le protocole Exterior Gateway (EGP) avant d’être redéfinie en mars 1995 dans la RFC 1771[16].

Des signatures numériques à la redéfinition de Cisco[modifier | modifier le code]

Malgré les recherches et études sur le sujet, BGP 4 n’utilise aucun moyen cryptographique pour sécuriser les échanges même si les failles de sécurité sont connues et présentées par l’IETF lui-même par le biais de Sandra Murphy qui dès décembre 1997 à 2006(RFC 4272[17]) publiera des RFC analysant les vulnérabilités de sécurité[13].

En 1996, Bradley R. Smith propose un ensemble de modifications au protocole BGP qui consistent à introduire une signature numérique pour chaque annonceur traversé (le prédécesseur)[4]. Cette modification améliore l’authentification des chemins[18] et permet d’éviter les boucles[19].

En 1997, Steven Cheung écrit sur l’utilisation de chaînes de hashage et l’optimisation des acceptations de mises à jour de chemins[4].

En 1998, Kirk A. Bradley propose une approche collaborative et distribuée pour les vérifications, le protocole WATCHERS[4].

En août, Andy Heffernan publie la RFC2385 relative à l’option TCP, la signature MD5[20],[4].

Entre 2000 et 2003, plusieurs protocoles ont été proposés pour améliorer la sécurité des réseaux et en particulier pour vérifier si un système autonome (AS) a le droit d’annoncer un chemin comprenant un certain préfixe[glossaire 3],[2].

En 2000, Stephen Kent décrit le protocole Secure BGP (S-BGP) pour le compte de la société Bolt, Beranek and Newman (BBN) qui fonctionne avec deux PKI. À chaque réception de mise à jour, le routeur BGP contacte le premier PKI afin de vérifier le préfixe IP dans le chemin et l'AS auquel il appartient. Le second PKI est ensuite contacté pour vérifier l’AS[18],[4] Ces PKI seraient tenues dans les registres internet régionaux (RIR) et parallèles au système existant d’AS[13].

En , Xiaoliang Zhao publie un Internet Draft “Validation of the multiple origin ASes conflicts through BGP community attribute" et "An Analysis of BGP Multiple Origin AS (MOAS)Conflicts" qui traitent du cas où un préfixe semble faire partie de plusieurs AS (MOAS) qui sont causés par le multi-homing ou les mauvaises configurations[4]. Il y définit les listes de MOA pour distinguer ceux qui sont valides des autres.

En 2002, la société Cisco propose Secure Origin BGP (soBGP) décrit d’abord par James Ng dans le document Extensions to BGP to Support Secure Origin BGP (soBGP) puis par Russ White en 2003. soBGP repose sur une base de données sécurisée pour connaître la topologie et les possesseurs des préfixes[10]. Les mises à jour dans la base de données sont cryptées avec IPsec ou MD5 pour en assurer la sécurité[21],[4],[13]

L'IETF propose également une succession de documents étudiant l'utilisation de certificats X.509 associés à des infrastructures à clef publique (RFC 3280[22]).

En 2003, Stephen M. Bellovin et Emden R. Gansner traitent des attaques permettant de couper les relations entre les annonceurs visant à modifier la topologie.

Lan Wang s’intéresse à la protection des routes BGP grâce aux systèmes de noms de domaine (DNS)[4]. Les routes menant aux DNS sont conservées dans une base de données. Lorsque ces routes ont été utilisées un nombre de fois défini, elles sont vérifiées humainement pour servir d’historique afin de filtrer les routes BGP[10].

C. Kruegel tente de valider les chemins en vérifiant les nœuds traversés[4]. Pour savoir si un chemin conduit à une adresse IP donnée, il se base sur les graphes de connectivité et les informations géographiques des bases de données contenues dans les registres régionaux de l’internet (Whois) pour apprendre la topologie des réseaux[23].

Geoffrey Goodell propose le protocole et l’architecture Interdomain Routing Validator (IRV)[4]. Dans son modèle, la sécurité est assurée en déportant les responsabilités d’autorité à un serveur IRV propre à chaque AS. Lors de la réception d’une nouvelle route, l’annonceur BGP contacte l’IRV et lui communique le chemin qui pour chaque AS traversé requête vers les serveurs IRV correspondant. Cette disposition réduit les besoins en mémoire et calcul pour la cryptographie[23].

De BGP 4 à l'idée de BGPSEC[modifier | modifier le code]

En , l’IETF réactualise les spécifications du protocole BGP 4 (RFC 4271) et rend obligatoire l’utilisation de l’option MD5[20] pour les communications TCP. Pour l’occasion, Sandra Murphy republie une étude des vulnérabilités de BGP (RFC 4272).

En juin, le SIDR, groupe de l'IETF chargé de sécuriser BGP, publie la première version du document A Profile for X.509 PKIX Resource Certificates (RFC 6487[24]).

Josh Karlin propose Pretty Good BGP[25] qui filtre les annonces en fonction d’un historique de chemins considérés de confiance. Les routes considérées anormales sont mises en quarantaine pendant 24 heures pour ralentir leur propagation et communiquées aux administrateurs pour vérification[4].

Dyonisus Blazakis définit une nouvelle unité pour jauger la stabilité d’une route. Cette unité est la distance d’édition d’ASPATH (AED)[26],[4]. Elle est convenue sur l’idée que plus le nombre d’AS traversé est élevé, moins le chemin est sûr[10].

Jian Qiu pense qu’aucune solution permet de contrer efficacement les détournements, et plus précisément celui redistribué. (A et B paires et C un AS malicieux, A apprend à C une route qu’il réapprend à B alors que B est relié à A : il a alors accès au trafic venant de B pour A.). Il propose alors une variante légère à l’épreuve du détournement de BGP et un plan pour son déploiement progressif[4]. Le principe pour éviter le détournement est que chaque AS et RIR fournit un serveur communiquant les informations pertinentes des AS et des préfixes IP (Qui possède cette IP ? Quels sont les voisins de A ?). Ensuite chaque AS utilise ce serveur de maintenance comme base de données basé sur l’historique pour autoriser ses routeurs à accepter et communiquer une route[10].

Sophie Y. Qiu étudie les changements d’origine des annonces. Lors de la réception d’une route pour un préfixe d’IP donné, si l’AS d’origine change, le serveur contacte le réseau et les AS pour identifier la source de cette modification afin d’identifier les AS mal configurés[27]. Ce mécanisme permet l’évaluation des AS et la confiance qu’on peut porter à leurs annonces[28]. Selon ces évaluations, on peut ralentir la propagation des annonces[29],[4].

Patrick Reynolds propose N-BGP, un outil de surveillance externe pour la sécurité de BGP[4]. Pour chaque routeur, un serveur N-BGP recherche les erreurs (sniffing) sur les liens avec ses pairs. S’il détecte des routes invalides, il communique des mises en garde.

Kevin Butler explore le moyen de simplifier les opérations cryptographiques de hash et signature en s’appuyant sur la stabilité naturelle des chemins[4].

Earl Barr travaille sur la détection des MOA et les communications entre les AS. Il en synthétise son framework Descartes BGP (D-BGP)[4]. Il fonctionne sur le travail collaboratif des AS pour déterminer le possesseur d’un préfixe et si le conflit persiste fournit des logs détaillés pour les administrateurs.

Dan Wendlandt émet l’idée de l'Availability-Centric Routing (ACR). L’intégrité et la confidentialité sont laissées à la charge des utilisateurs. Seule la disponibilité intéresse les annonceurs BGP. Pour cela, les routes sont conservées et jaugées dans des dépôts de routes[27]. Au bout du compte, lorsqu’un utilisateur souhaite rejoindre une destination, plusieurs chemins sont à sa disposition[4].

Ioannis Avramopoulos cherche à rendre furtifs les paquets de diagnostic utilisables par BGP pour vérifier une route dans Stealth probing : efficient data-plane testing inside tunnel[4]. Il en fournit Stealth probing qui est un outil de surveillance pour les plans de données sécurisées.

Yih-Chun Hu propose le mécanisme Grassroots-PKI qui permet à toute entité de routage de créer des certificats qu’elle signera pour revendiquer des adresses IP[4] afin d’obtenir une infrastructure de clef publique (PKI) globale.

En , An Infrastructure to Support Secure Internet Routing du SIDR qui donnera la RFC 6480 décrit ce qui deviendra RPKI.

En mai, l’IETF indique la possibilité d’un changement pour l’identification des AS. À la place d’être identifié sur deux octets, il le sera sur quatre à cause de la distribution des adresses IPv6. Il reconnaît que ceci ouvre la possibilité d’attaques pendant le déploiement dues aux incohérences entre les attributs AS_PATH et AS4_PATH correspondant aux routeurs à emprunter pour arriver à destination ainsi que boucles[30].

X. Hu étudie la possibilité d’identifier les chemins suspicieux en utilisant des empreintes digitales[4]. Ces empreintes seraient des informations relatives aux propriétés des hôtes (os, services, ports)[29].

En 2008, le registre régional de l'internet APNIC, haute autorité de l'internet pour les pays asiatiques et du pacifique, a été le premier à inclure la publication de certificats RPKI comme partie de l'ensemble des services fournis aux possesseurs de ressources internet. Ces certificats permettent l'identification de l'AS qui dispose d'un préfixe d'IP[31] et annonce de rpki-engine[32].

En , les faiblesses de l’option MD5 de TCP font que l’Internet Engineering Task Force (IETF) propose une nouvelle option pour sécuriser les communications. Il s’agit de l’option d’authentification (TCP-AO). Elle permet d’utiliser d’autres fonctions de hashage que MD5 et propose une génération de clefs[33].

En juillet, BGP Prefix Origin Validation est proposé par l'Internet Engineering Task Force (IETF) qui donnera la RFC 6811. Il permet l'identification des AS possesseurs d'ensemble d'IP à l'aide de Resource Public Key Infrastructure (RPKI) et Route Origin Authorization (ROA).

Dès , des documents de l'Internet Engineering Task Force (IETF) présente une vue globale de l'extension BGPSEC.

En juin, l’IETF standardise l’identification des annonceurs BGP avec quatre octets (RFC 6286) dont la manière de soutenir ceci est décrite en . (RFC 6793)

En , l’IETF définit les ROA (RFC 6480) et les RPKI (RFC 6481) ainsi que leur collaboration pour assurer la sécurité de BGP. (RFC 6483)

En mai, l’IETF rajoute à BGP 4 la possibilité pour les annonceurs d’envoyer des messages d’erreurs lors de la réception d’une annonce. (RFC 6608)

En , la RFC 6481 (décrivant les RPKI) est finalisée.

En mai, l’IETF fournit un document sur l’état des lieux pour la sécurité des protocoles utilisant BGP. (RFC 6952)

En juillet, L’option TCP-AO est corrigée pour être utilisable malgré la présence d’entité NAT sur les liens entre deux annonceurs. Leur présence rendait impossible son utilisation. Cette modification entraîne une baisse de sécurité du mécanisme. (RFC 6978)

Définition des points de sécurité et des vulnérabilités[modifier | modifier le code]

Pour les protocoles de routage tel que BGP, les vulnérabilités et les menaces sont minimisées ou éliminées avec la présence de ces six points de sécurité[34]. Les principaux sont la protection des informations de routage en terme d’intégrité, d’authenticité (assurée par l’authentification) et, dans certains cas, la confidentialité des mises à jour des chemins. Ces points permettent d’assurer la confiance nécessaire en BGP pour la mise à jour des chemins qui traversent Internet[34].

À cela s’ajoute la disponibilité, le contrôle d'accès et la non-répudiation[34].

BGP a plusieurs vulnérabilités parmi lesquelles on retrouve la nature des routeurs (une machine nécessite de l’électricité et peut tomber en panne) et les chronomètres propres à l’état de l’automate BGP [35] mais la plus importante des vulnérabilités de BGP est son protocole de communication TCP[36]. Entre autres, la durée des sessions TCP (qui se compte en semaines) entre deux routeurs BGP permet d’enregistrer les paquets qu’ils se transmettent pour les réutiliser une fois que 2^32 paquets ont été envoyés : Cette possibilité entraîne un risque de sécurité. Enfin, l’option TCP MD5 qui a été rendu obligatoire, souffre des années de recherche en cryptographie.

La dernière vulnérabilité de BGP est la mixité et le pluralisme des organisations qui gèrent les routeurs BGP.

Authentification/Authenticité[modifier | modifier le code]

L’authenticité est la vérification de l’identité revendiqué par une entité d’un système. Elle évite que des routeurs légitimes acceptent des informations de routage émis par une entité non autorisée [34].

Pour résumer, il doit être vérifiable que[37] :

  • Un AS ait autorisé un routeur de le représenter.
  • L’AS existe.
  • L’AS a autorisé un routeur à s’ajouter au chemin.
  • le chemin suit bien l’itinéraire qu’il indique.

Malheureusement, aucun mécanisme n’a été spécifié pour le besoin d’assurer l’authenticité des attributs d’un chemin qui a été annoncé par un AS[38],[7]. Seules les options pour TCP : MD5 et Origin Authentification; ont été proposées mais elles ne permettent d’identifier que le voisin direct grâce à une signature cryptographique[7].

En 2013, la spécification de BGP Prefix Origin Validation (RFC 6811) permet de vérifier l'AS d'origine d'un chemin avec l'utilisation d'un certificat X.509 grâce à RPKI et ROA.

Intégrité[modifier | modifier le code]

L’intégrité est la protection des données (informations de routages) pour s’assurer qu’elles ne sont ni altérées ni détruites d’une manière non autorisée (corruption intentionnelle)[34] lors de leur trajets entre les paires[37]. L’absence d’intégrité entraîne la possibilité que les routes et l’état des routeurs soient manipulés[39] par un attaquant ou annonceur BGP configuré mal intentionnellement[7].

Mis à part les options rajoutés à TCP (MD5 et Origin Authentification), BGP n’a aucun mécanisme interne fournissant une forte protection de l’intégrité des messages dans les communications de type paire à paire[38]. L’utilisation des numéros de séquence des paquets TCP dans le calcul des signatures assurent en partie l’intégrité entre deux routeurs qui sont voisins[40].

Confidentialité[modifier | modifier le code]

La confidentialité est la protection que les données, les mises à jour des tables de routages, qui sont communiquées ne soient pas observables par les entités non autorisées[34]. Ce point permet d’éviter l’espionnage et les routines (polices : règles de filtrage) qui viennent à se répéter au cours du temps[39].

Malheureusement, les données de routage transportés par le protocole le sont en clair. Il n’y a donc aucun cryptosystème mis en place pour les protéger de l’espionnage/l'observation.

Disponibilité[modifier | modifier le code]

La disponibilité est l’assurance que les services sont accessibles et donc que les chemins soient praticables pour les entités autorisées[34]. La communication des annonceurs repose sur des connexions TCP de longue durée. Ces connexions entre annonceurs peuvent être la cible d’une attaque de type déni de service[39]. Dans notre cas, ceci entraînerait l’arrêt de la communication entre les deux annonceurs BGP. L’attaquant pourrait également empêcher un annonceur de fonctionner en le privant de ses ressources et de facto rendre inaccessibles les chemins qui transitent par ce routeur[41].

Malgré la panne d’un routeur BGP, l’interconnexion[glossaire 4] des réseaux et la grande redondance des chemins assure l’existence d’autres chemins pour rejoindre une destination.

Non-répudiation[modifier | modifier le code]

Non-Repudiation est la protection contre les fausses répudiations de communication[34]. Elle assure que les paquets ont bien été envoyés et reçus. On l’atteint souvent par le biais de certificats.

Contrôle d'accès[modifier | modifier le code]

Le contrôle d’accès est la protection contre les utilisations non autorisées des ressources d’un système[34], (le contrôle d’accès ou gestion des droits qui est le produit de l'authentification et la confidentialité). Dans BGP, un des contrôles d’accès les plus importants est le système autonome d’origine (Origin verification) pour un préfixe IP donné : cet AS a-t-il le droit de fournir une route pour cet adresse IP [37]? La solution est donnée en 2013 grâce à l'utilisation de BGP Prefix Origin Validation (RFC 6811) qui identifie le possesseur d'un préfixe IP grâce à des certificats utilisant le ROA/RPKI.

Menaces[modifier | modifier le code]

Une menace est définie comme un adversaire compétent et motivé[42]. Cet adversaire est une entité (personne ou organisation) perçue comme malicieuse, par rapport à la sécurité d'une police du système. La décision de caractériser une entité comme un adversaire est prise par les responsables de la sécurité du système[43].

Les équipements réseaux[modifier | modifier le code]

Un équipement peut devenir une menace s'il est mal configuré ou atteint un état non attendu par le concepteur du système. On parle alors de problèmes byzantins.

Les opérateurs du réseau[modifier | modifier le code]

Pouvant être une menace, un opérateur peut être motivé que ses routeurs BGP émettent des messages de mises à jour avec des informations de routage inexactes. De tels messages permettent de détourner le trafic par des chemins économiquement avantageux pour l'opérateur mais qui seraient autrement rejetés ou moins avantageux pour d'autres opérateurs réseau. Puisque les opérateurs contrôlent les routeurs BGP de leurs réseaux, ils sont en position de modifier leur comportement de manière aléatoire. Les routeurs gérés par des opérateurs réseau sont des points stratégiques susceptibles d'être utilisés pour pratiquer des attaques "Man in the middle (MITM)" qui permettent le contrôle des données et du plan de données (par où elles vont transiter)[44].

Hackers[modifier | modifier le code]

Considéré comme une menace, un hacker peut prendre le contrôle des ordinateurs et routeurs des opérateurs gérant un réseau. Dans ce cas, les hackers seraient capables d'agir comme les opérateurs cités dans la section précédente. Il est assumé que les hackers n'ont généralement pas la capacité d'effectuer d'attaques MITM sur la plupart des liaisons entre les réseaux (liaisons utilisées pour transmettre le trafic BGP et des abonnés). Un hacker peut être recruté, en dehors de sa connaissance, par des criminels ou des nations, pour agir à leur profit. Des hackers peuvent être motivés par un désir de reconnaissance, par profit ou en soutien à une cause. La distinction avec les criminels est due à ces motivations pouvant être non pécuniaires[45].

Criminels[modifier | modifier le code]

Pouvant être une menace, des criminels peuvent persuader (via des menaces ou l'extorsion) un opérateur réseau à agir comme décrit précédemment et effectuer des attaques de grandes envergures. Des criminels pourraient persuader l'équipe d'un fournisseur de télécommunication de permettre des attaques MITM sur des liaisons entre les routeurs. Leurs motivations incluent l'extorsion d'argent des opérateurs réseau ou de leurs clients. Ils peuvent également souhaiter dissimuler la source de spam, d'attaque DOS ou d'autres activités criminelles[45].

Registres[modifier | modifier le code]

Tout registre dans le RPKI pourrait être une menace. L'équipe chargée d'un registre est capable de manipuler le contenu des dépôts ou de mal gérer les certificats les RPKI qu'ils émettent. Ces actions pourraient nuire à un opérateur réseau ou à un de ses clients. Cette équipe pourrait être motivée par la pression d'une nation sous laquelle le registre opère ou par une influence criminelle[45].

Nations[modifier | modifier le code]

Pouvant être une menace, une nation pourrait contrôler un ou plusieurs opérateurs réseau sur son territoire, et les pousser à agir comme présenté plus haut. Une nation peut avoir une capacité technique d'écoute active (à travers son territoire) qui permet d'effectuer une attaque MITM sur le trafic entre les réseaux (cette aptitude peut être facilitée par le contrôle ou l'influence qu'elle détient sur un fournisseur de télécommunication interne à sa nation.) La nation aurait la faculté d'attaquer et prendre le contrôle des routeurs ou des ordinateurs gestionnaires du réseau de son territoire. Il pourrait forcer les registres à agir de manières malintentionnées envers les clients du registre. Ces motivations incluent le désir de contrôler le flux du trafic de son pays ou de détourner le trafic d'une autre nation (pour une écoute passive ou active, incluant les attaques DoS)[46].

Attaques[modifier | modifier le code]

Les attaques peuvent être perpétrées sur les routeurs BGP, le protocole BGP, les sous-protocoles, et les câbles de raccordement.

Les attaques visant les sessions de communications entre deux paires BGP. Elles incluent celles visant le protocole TCP comme :

  • l’attaque à base de paquets TCP RST. Les paquets TCP doivent être forgés en utilisant une certaine fenêtre de numéro de séquence pour en assurer son succès. Le routeur BGP qui recevra le paquet, fermera la connexion de communication[47].
  • l’attaque à base de paquets TCP SYN. Les paquets SYN sont utilisés pour initialiser une connexion TCP. En TCP, pour chaque message, un acquittement est attendu : le routeur BGP va donc acquitter et attendre son propre acquittement en conservant en mémoire le début de la communication. Si un attaquant inonde le serveur de TCP SYN, ce dernier utilisera de la mémoire pour se souvenir des acquittement qu’il attend. Finalement, le routeur n’aura plus de ressource et ne sera plus en mesure d’ouvrir de nouvelles connexions ou entraîner le crash du serveur. Cette attaque peut aussi permettre de se connecter simplement au routeur pour lui passer des messages BGP[47].

Depuis que les routeurs BGP échangent différents messages pour accomplir leurs opérations, une attaque peut être organisée à l’aide de ces messages. Ces attaques sont :

  • l’espionnage de ces messages. Cet acte non autorisé peut aider à l’usurpation des paquets.
  • Si une erreur est présente dans l’entête d’un message de BGP, cela causera la fermeture d’une connexion de communication avec un pair[47].
  • Si l’attaquant peut supprimer les messages KEEPALIVE d’un flux de données, alors une session de communication peut être fermée car le routeur qui ne les reçoit pas pensera que son pair est éteint. S’il considère que le pair est éteint, les paquets de données utilisateur qu’il devait lui transférer passeront par une autre route[47].
  • l’usurpation d’un message NOTIFCATION cause la fin immédiate des communications par le routeur receveur[47].
  • Rejouer un ancien message de mise à jour peut mener à ajouter ou supprimer une route[47].

Shunt[modifier | modifier le code]

Présenté en 2008 par Alex Pilosov et Tony Kapela lors de la Defcon, le Shunt est une attaque combinée de plusieurs techniques qui permet d’obtenir les paquets à destination d’une cible et de les lui renvoyer avec peu de chance d’être détecté[48]. Cette attaque utilise la génération d’un chemin sain qui ne sera pas affecté et un empoisonnement des annonceurs BGP[49]. Ce chemin sain est celui communiqué comme chemin d’AS lors de son annonce frauduleuse. L’empoisonnement/annonce frauduleuse consiste en la répétition de l’annonce d’origine avec un masque plus précis (/28 à la place de /24). L’annonce sera rejetée par les annonceurs présents dans le chemin sain [50] mais acceptée et enregistrée par les autres. Elle est efficace en raison du manque de filtrage entre les annonceurs BGP qui sont pairs[51],[52].

Dommages[modifier | modifier le code]

Ils sont la conséquence de l'utilisation d'un chemin erroné pour la transmission des paquets. Ces conséquences peuvent affecter exclusivement un nœud du système (un service particulier, exemple : Youtube) ou l'ensemble du réseau et de l'internet[53].

  • Famine : Le trafic de données destinées à un nœud est transmis à une partie du réseau qui ne peut le délivrer[54].
  • Congestion du réseau : De plus en plus de trafic de données est transmis à travers une portion du réseau qui ne peut le supporter. Cette augmentation provoque alors un ralentissement global[54].
  • Trou noir (Blackhole) : Une grande quantité du trafic est dirigée pour être transmise à travers un routeur qui ne peut traiter le haut niveau de trafic et supprime beaucoup/la plupart/tous les paquets de données[53].
  • Retard : Le trafic de données destiné à un nœud est expédié le long d'un chemin qui est inférieur en capacité de transmission à celui qu'il devrait autrement prendre[53].
  • Boucle : Le trafic de données est transmis le long d'un chemin qui boucle, donc les données ne seront jamais délivrés[53].
  • Espionnage : Le trafic de données est transmis à travers un routeur ou un réseau qui ne devrait pas accueillir les paquets. Ce cheminement est l'opportunité pour des menaces d'observer le trafic et de récupérer les données communiquées[53].
  • Partition : Une partie du réseau estime qu'il est partitionné à partir du reste du réseau, alors qu'en fait, il ne l'est pas[53].
  • Coupure (Cut) : Une portion du réseau croit qu'il n'y a pas d'itinéraire pour un réseau donné alors qu'en fait il y est relié[53].
  • Churn : La transmission dans le réseau change rapidement, ce qui entraîne de grandes variations dans les modes de prestation de données et nuit aux techniques de contrôle de la congestion[53].
  • Instabilité : BGP devient instable de telle sorte que la convergence sur un état de transfert global n'est pas atteinte[53].
  • Surcharge (overload) : Les messages BGP deviennent une portion significative du trafic que le réseau doit supporter[53].
  • Épuisement des ressources : Les messages BGP causent eux-mêmes un épuisement des ressources critiques des routeurs, telles que l'espace des tables de routage[53].
  • Usurpation d'adresse (spoofing) : Le trafic de données est transmis à travers un routeur ou un réseau qui usurpe l'adresse légitime. Ceci permet une attaque active en fournissant l'opportunité de modifier les données[53].

Solutions[modifier | modifier le code]

Un ensemble de technique a été proposé mais surtout depuis la proposition de S-BGP et soBGP en 2003.

Moyens[modifier | modifier le code]

Pour sécuriser le protocole Border Gateway, plusieurs outils ou techniques sont envisageables.

Cryptographie[modifier | modifier le code]

La cryptographie est la discipline la plus utilisée dans la protection des données et l'authentification des systèmes. Elle repose sur la possibilité de chiffrer (rendre illisible) et déchiffrer un message à l’aide d’un secret. On divise en deux écoles les différents cryptosystèmes :

  • Les systèmes symétriques qui n’utilisent qu’une clef connue de tous ceux qui doivent chiffrer et déchiffrer les messages (AES)
  • Les systèmes asymétriques qui utilise une paire de clef comprenant une publique pour ceux qui souhaitent écrire à celui qui la leur a fourni et la clef privée permet de lire (RSA). De plus, il donne la possibilité de signer des données. On parle de signature

Les cryptosystèmes symétriques sont plus léger en besoin de calcul pour être utilisés que ceux asymétriques. Mais dans le cas de BGP, si un routeur devait connaître une clef pour chaque entité qu’il doit identifier ou comprendre, les besoins en capacités mémoires seraient très importants [7] et ce système n’assurerait pas de sécurité car tous connaîtraient les clefs secrètes des autres.

Les cryptosystèmes asymétriques permettent mieux d’assurer la sécurité des échanges. Effectivement, en plus d’assurer la confidentialité des communications tant que la clef privée est secrète : la cryptographie asymétrique permet de générer des signatures qui sont chiffrées avec la clef privée et lues avec la clef publique et qui permettent d’assurer l’intégrité et l’authentification d’un paire BGP. Le problème de BGP était la mise en place d’une infrastructure à clef publique (PKI) comme proposée par Perlman. Cette infrastructure permet de communiquer des certificats correspondants aux clefs publiques quand un routeur souhaite vérifier les routes et s'assurer de leurs origines. En l'absence de cette infrastructure, c'est à l'homme de s'assurer de la présence et la validité des clefs ou l'utilisation de techniques comme celle de Diffie-Hellman [3],[55]. De plus, les signatures permettent d’assurer la non répudiation.

À cela on peut ajouter les fonctions de hachage, elles génèrent une empreinte qui est censé être unique à des données[11],[56]. Ces fonctions sont utilisés dans les options TCP tels que MD5 et Authentification pour assurer l’intégrité entre deux routeurs voisins[20].

Base de données[modifier | modifier le code]

Les bases de données permettent la collecte d’informations. Dans le cas de BGP, ces informations ayant trait aux routages peuvent être des certificats (explication au-dessus avec les infrastructures à clefs publiques), des routes sauvegardées au fur et à mesure comme proposé par Karlin en 2006 avec Pretty Good BGP (pgBGP)[57], des relations entre préfixe IP et AS comme quel est le système autonome (AS) d’origine d’une plage d'adresses IP (2006, Sophie Y. Qiu) ou tout simplement des routes.

Ces informations qui peuvent être centralisées (PKI) ou distribuées dans des serveurs pour chaque AS (IRV) ou chaque routeur (pgBGP) permettent d’analyser les modifications de topologie d’internet (changement d’origine d’une IP ou nouveau chemin) ce qui entraîne des tests ou des pénalités sur les chemins. Ceci permet l’évaluation de systèmes autonomes et de la confiance qu’on peut leur porter. L’évaluation des systèmes et les informations collectées peuvent être utilisées pour créer un oracle qui, par exemple, pour chaque chemin décide de le filtrer en fonction de son historique. Il est également possible d’utiliser des bases de données préexistantes telles que les serveurs DNS (Wang, 2003)[4] et le serveur whois (Kruegel, 2003)[23].

Protocole en groupe de recouvrement[modifier | modifier le code]

Les protocoles en groupe de recouvrement servent à mettre en place des règles ou des méthodologies pour vérifier les plans de données. Basé sur l’utilisation des bases de données ou l’étude des routes, un protocole peut, dans le cas de base de données distribuées, être de se concerter lorsqu’un événement est observé qui présente une anomalie (MOA) entre serveurs de confiance pour connaître la source de l’erreur ou la véracité des données. (Bradley, 1998) Ces observateurs peuvent être extérieur (Reynolds, 2006) ou interne (Listen de Subramanian, 2004) au routeur.

Pénalité[modifier | modifier le code]

En cas de détection d’anomalie, des pénalités peuvent être apportées par les routeurs aux propagations des routes. De base, un annonceur BGP qui reçoit une route lui applique une police qui correspond à des règles de filtrage mises en place par l’administrateur système. La pénalité repose sur le même principe. En fonction des évaluations et de la détection d’anomalies, le routeur peut :

  • filtrer une route
  • isoler un routeur ou système autonome (ignorer les chemins passant par lui car jugés indignes de confiance)
  • retarder la propagation de la route. Comme pgBGP qui met en quarantaine pendant 24 heures les routes qu’il considère anormales.

Test des plans de données[modifier | modifier le code]

Les tests réalisés sur les plans de données sont la vérification des chemins. l’exemple précédent sur la participation de l’historique à la détection des anormalités ou des Multiple Origin AS en est un exemple. Il est possible pour un routeur de tenter une connexion auprès d’une IP qu’un préfixe contient pour vérifier si le chemin fonctionne. Cette technique a été amélioré par Avramopoulos en 2006 avec l’utilisation d’un tunnel pour éviter des contre-mesures de la part des attaquants. Cette partie contient également le contrôle TTL.

Définies par l'IETF[modifier | modifier le code]

Intégrité MD5[modifier | modifier le code]

L’intégrité MD5 correspond à TCP MD5. Il s’agit d’une extension de TCP où l’on ajoute un haché MD5 basé sur un code d’authentification des messages (MAC)[58]. Effectivement, l’un des nombreux défauts de sécurité est basé sur l’extrême dangerosité [59] de la confiance des annonceurs en l’authentification via l’adresse IP[60]. La motivation principale est donc de protéger les annonceurs BGP des paquets TCP usurpant un correspondant légitime et plus particulièrement les attaque DoS utilisant les paquets TCP RESET qui vont couper les sessions de communication.Les techniques comme TLS qui sont complémentaires au TCP MD5[61] mais ne protègent pas contre ces attaques car elles opèrent en dessous de la couche application[62],[63].

chaque paquet TCP contiendra une option validant partiellement les paquets. Cette option correspond à un haché de 16 octets produit avec l’algorithme MD5 en utilisant la pseudo entête IP, l’entête TCP, les données du paquet (s’il y en a) et un secret partagé entre les paires (clef ou mot de passe) spécifique à la connexion[58]. Ce mot de passe n’apparaît pas en clair et est traité au niveau de la couche application. L’utilisation de plusieurs mots de passe est possible selon l’état de la connexion[64].Cette sécurité repose sur le principe que l'attaquant qui ignore le secret ne peut pas fabriquer de faux paquets[63]. (signature des paquets[62]) [58]

Avec l’accumulation de l’encodage d’authentification des messages en MD5 et les numéros de séquences, TCP peut protéger l’intégrité d’un message et contrer les attaques de type Replay Attack. Il ne protège pas la confidentialité des messages il n’y a pas de mécanisme d’encryptage spécifié. Mais cette solution requiert qu’une clef secrète soit manuellement configuré dans les deux routeurs qui vont communiquer. Ceci place une lourde responsabilité sur les administrateurs réseaux. Des variantes hachant tout ou partiellement les paquets en utilisant une ou plusieurs clefs traitent de nombreux problèmes d'usurpation et de détournement inhérente à TCP[58].

Les routeurs dédiés à BGP savent utiliser cette option. Ainsi, sur IOS, c'est le mot-clé password y fait référence. La situation est plus délicate sur les routeurs non-dédiés fondés sur Unix. même s’il existait des patches, ils n'ont pas eu pendant longtemps le support du RFC 2385 en série car par question de principe : cette option viole le modèle en couches avec ses aller-retours entre l'application et TCP; Aujourd'hui, le noyau Linux dispose de cette fonction . En pratique, l'exigence de sessions « TCP MD5 » a souvent servi à éliminer ceux qui utilisent Quagga sur Unix et n'avaient pas de moyen facile de configurer leurs routeurs selon cette option[63]. Les implémentation doivent supporter au minimum une clef composé d’une chaîne ASCII de 80 octets ou moins[65].

Malheureusement, MD5 a montré des faiblesse aux attaques de recherche de collision[66]et est considéré par certains comme insuffisamment résistant en raison de la criticité de l’application[67].(En , une attaque réussie contre MD5 a permis de générer de faux certificats X.509 [68])[63] Et même si MD5 a été rendu obligatoire [69], son champ prévu dans BGP fût largement inutilisé[58]. De plus, d’autres problèmes persistent comme des paquets TCP légitimes qui peuvent être refusés alors que des paquets usurpés ICMP, non validés par la signature MD5, peuvent être acceptés. À ceci s’ajoute le coût en performance lié aux opérations cryptographiques ou l'augmentation de la taille des paquets[63] et la non protection des bugs d'un paire[70].

Atténuation de la fenêtre de TCP[modifier | modifier le code]

Une des solutions proposées par l'IETF pour contrer les attaques à base de paquets TCP, précisément RST mais peut également s'appliquer à SYN et aux injections de données[71], a été de réduire la taille de fenêtre TCP. Si un paquet TCP RST vient à être envoyé à un annonceur BGP au cours d'une communication, ce paquet doit être numéroté avec le prochain numéro de séquence attendu par le récepteur. Si ce numéro n'est pas correct, le récepteur répond par un acquittement de taille nulle. Si l'envoyeur était légitime, il n'aura qu'à ré-envoyer le paquet corrigé. Cette solution force l'attaquant à exécuter un brute force qui peut entraîner jusqu'à 2³² tentatives. Cette solution a pour défaut de violer les règles du protocoles TCP[72].

Internet Protocol Security (IPSEC)[modifier | modifier le code]

Pour un article plus général, voir Internet Protocol Security.

Internet Protocol Security (IPSEC) est un protocole de communication sécurisé par des solutions crptographiques pour les réseaux IP.

TCP AO[modifier | modifier le code]

En 2010, alors que les attaques contre l’algorithme de hachage MD5 se perfectionne, TCP option MD5 y reste limité et ne permet pas de changer de clés facilement (gestion humaine). IETF propose alors pour remplacer cette option : TCP Authentification Option[58]. Cette option est normalisé dans le RFC 5925 et suit les recommandations du cahier des charges Statement and Requirements for a TCP Authentication Option“ mais ne remplace pas IPsec[63].

Comme son prédécesseur TCP MD5, TCP-AO :

  • repose sur le calcul d’une signature cryptographique
  • ne dispose pas de solution pour gérer les clefs, à cause d’une trop faible quantités d’option TCP
  • n’assure pas la confidentialité des données mais l’authentification et l’intégrité de celles-ci. En conséquence, son rôle est de protéger les sessions de longues durées (plusieurs semaines) comme celles de BGP[73].

Mais elle :

  • permet le choix entre plusieurs fonctions de hachage qui sont recensées dans la RFC 5926 (Agilité d’algorithme)[58],[74]
  • génère automatiquement des clefs de session grâce à des clefs maîtresses (MKT)[75] définies par le champ KeyID des paquets TCP[73] et des paramètres supplémentaires comme l'ISN (Initial Sequence Number, voir la section 3.3 du RFC 793), qui sont passés en paramètres à une fonction cryptographique nommé KDF (Key Derivation Function)[76].

TCP-AO n'a pas de Security Index mais utilise le 4-tuple correspondants aux informations de connexions IP (ports & adresses). Le MAC dans les paquets TCP est calculé à partir des clés de session. En plus de fournir une preuve d’intégrité, une protection au rejeu est fournie [77],[58] car ajout d’une extension au numéro de séquence, la SNE (Sequence Number Extension) qui, combinée avec le numéro de séquence, donne un numéro unique à chaque paquet transmis.

L’un des problèmes est la réduction de place pour les options TCP, on ne peut donc pas espérer utiliser en même temps toutes les autres options TCP normalisées. Lors du redémarrage d’une machine si une connexion TCP était ouverte, la machine perdra la clef de cette connexion. Elle enverra donc des paquets RST lors de la réception des paquets TCP de son pair[78]. Mais ces RST seront ignorés par ce dernier car non authentifiés, ils devront donc attendre l’expiration de la session. C'est dommage mais empêche les RST « pirates »[79]. TCP-AO ne protège que TCP, pas les paquets ICMP.les paquets ICMP ayant le type 3 et les codes 2 à 4 et les paquets ICMPv6 de type 1 et de code 1 et de code 4 sont donc ignorés car ils peuvent casser une connexion TCP-AO, sans avoir besoin de s'authentifier[80].

Un intermédiaire (middlebox) risque de rejeter ou modifier les paquets[81]. S’il modifie l’adresse IP (routeur NAT), TCP-AO ne peut plus fonctionner[82]. Il faudrait alors encapsuler le flux TCP ou de compter sur l'extension NAT du RFC 6978[82]. S’il modifie les options, il faudrait configurer TCP-AO pour les ignorer dans le calcul de la MAC, ce qui autoriserait l’attaquant à les modifier et affaiblirait la sécurité[82].

TCP AO NAT[modifier | modifier le code]

En , une extension NAT est défini dans la RFC 6978 pour régler le problème dû aux équipement NAT. À l'aide de deux options correspondant à des booléens, le récepteur sait s'il doit prendre en compte ou non l'adresse ip et le port de la source ou de la destination[83].

Les options sont donc des flags et correspondent à localNAT et remoteNAT. Si localNAT est à vrai alors l'adresse IP et le port de source sont considérés à 0. Dans le cas de remoteNAT, c'est l'adresse IP et le port destination qui sont considérés égaux à 0 pour le calcul des clefs de sessions et du MAC[84].

ROA/RPKI[modifier | modifier le code]

Dernière solution en date, elle permet la vérification du système autonome d'origine grâce à des certificats X.509 pour une ressource IP (RFC 6483).

RPKI[modifier | modifier le code]

Voir aussi Resource Public Key Infrastructure (en)

La Resource Public Key Infrastructure (RPKI) est une infrastructure à clés publiques hiérarchisée qui relie une adresse IP à un AS et inversement (RFC 6480). Les ressources internet sont distribuées par l'IANA aux registres régionaux d'internet (RIR). Ces registres vont ensuite les distribuer à leur clients. RPKI contient donc les certificats (RFC 5280) qui permettent de détecter les détournements et autre attaques. Elle est la base du futur protocole BGPSEC.

ROA[modifier | modifier le code]

Route Origination Authorization (ROA) sont des attestations cryptographiques autorisant l'annonce de route pour des préfixes. Elles sont créées à partir des Certificats fournis par RPKI (RFC 6482).

BGP Prefix Origin Validation[modifier | modifier le code]

Défini en janvier 2013 dans la RFC 6811, BGP Prefix Origin Validation est la description de la manière dont on valide une annonce BGP, et plus précisément son origine. Pour cela on utilise des Validated ROA Payload[85].

Proposées par la recherche[modifier | modifier le code]

Cette section présente les deux principaux protocoles (S-BGP & soBGP) sur lesquels la sécurité de BGP semble évoluer ainsi que d'autres propositions qui ont été faites par la recherche.

S-BGP[modifier | modifier le code]

Proposé par BBN Technologies, Secure BGP (S-BGP) repose sur trois points [86]:

  • une infrastructure à clefs publiques (PKI) qui représentent les possesseurs et délégations d’adresses IP et les numéros d’AS. Elle utilise des certificats X.509 (v3) pour autoriser les routeurs à valider l’autorisation des autres routeurs à représenter des AS (ISP). La PKI autorise également les routeurs à vérifier que chaque fournisseur d'accès à Internet soit bien le gestionnaire des adresses IP qu'il annonce.
  • Les attestations, qui sont des signatures numériques, gèrent les autorisations et comportent deux types : les attestations d’adresses qui sont signés par un ISP ou un de ses abonnés pour autoriser des AS d’être l’origine d’un ensemble d’adresses IP; les attestations de routes signés par un routeur et qui contient la liste des AS à qui il va envoyer le message de mise à jour et qu’il autorise de le retransmettre.
  • L’utilisation du protocole IPSec entre les routeurs pour assurer la sécurité point à point pour les communications.

Les attestations et les certificats du PKI permettent d’assurer l’origine des ensembles d’adresses dont le chemin est mis à jour et que tous les AS qui transmettent le chemin y ont été autorisés. Cette solution est, malgré tous ces dispositifs, sensible à des attaques comme le rejeu car BGP n’utilise pas de numéro de séquence pour ses messages ou de données temporelle pour dentifier deux messages comportant les mêmes données[86].

Pretty Secure BGP (psBGP)[modifier | modifier le code]

Pretty Secure BGP (psBGP) est un système pour l’authentification d’origine des annonces énoncé en 2005 par P. C. VAN OORSCHOT, Tao WAN, et Evangelos KRANAKIS. Il s’inspire de soBGP, S-BGP et IRV[87]. Contrairement à ces prédécesseurs, il admet que : Même si les AS peuvent être gérés par une infrastructure de clefs publiques (PKI), il est impossible de gérer les adresses à travers un PKI centralisé[88]. psBGP n'en empêche malgré cela pas l’utilisation pour la délégation des préfixes mais dans ce cas psBGP aiderait pour l’authentification des préfixes qui n’y sont pas recensés[89].

En clair, Il protège contre la falsification des messages de mises à jour BGP et propose une nouvelle approche pour vérifier l’origine d’un préfixe par le recoupement d’information de plusieurs sources[89]. Il part des hypothèses que :

  • les autorités de confiance (registres des internets régionaux) pour l’assignation des préfixes ne sont pas toujours disponibles[89].
  • quelques entités (AS) doivent avoir connaissance de l’assignation des préfixes[89].
  • les corroborations de différentes sources assure la véracité d’une information[89].

Les principaux points assurant la sécurité sont :

  1. L’authentification des numéros de systèmes autonomes (AS) est porté par un certificat de clef publique d’une source de confiance. (relation entre le numéro d’AS et la clef publique)[89]
  2. l’évaluation des AS étrangers facilite les vérifications et la sécurité pour l’équilibrage de charges[90].
  3. Une liste des préfixes (PAL) pour chaque AS contenant ceux qui lui sont locaux et ceux de ses voisins[90].
  4. La mise en place d’une signature semblable à celle de S-BGP ce qui associait au système d’évaluation lui permet de vérifier l’intégrité des chemins d’AS[90].

Finalement, la responsabilité de l’authentification d’un annonceur est transmise à son AS et les paires voisines. Ceci diminue le coût de vérification d’un préfixe mais affaiblit l'autorité [91] car tout AS peut témoigner de la validité d'une demande d'origine. En général, l'hypothèse selon laquelle qu’aucun AS ne sera en collusion, peut être difficile à soutenir sur internet alors que la plupart des AS ne possèdent aucune relation entre eux[88]. De plus, les signatures cryptographiques à S-BGP peut être validés par un ensemble ce qui rend la procédure de validation de l’intégrité plus que légère[88].

Pretty Good BGP[modifier | modifier le code]

0,2-1 % des routes des tables de routages souffrent de mauvaises configurations chaque jour [92]: ceci entraîne des perturbations ou des opportunités pour des attaques[93].

Pretty good BGP (pgBGP) est un système de détection distribué des anomalies proposé en 2006[94] par Josh Karlin, Stephanie Forrest et Jennifer Rexford et amélioré en 2008[95]. pgBGP se base sur une table de confiance pour son routage et l’apprentissage de nouvelles routes. Cette table repose sur un historique. Avec l’idée que les chemins sont redondants et que ceux anormaux ont une courte durée de vie, elle vérifie si elle connaît les préfixes lorsqu’elle reçoit une nouvelle route. En cas de présence d’un système autonome (AS) ou d'un (sous-)préfixe inconnu dans la liste des préfixes, la route est mise en quarantaine pour 24 heures et les opérateurs sont prévenus par email. Cette méthodologie ralentit la diffusion de certaines routes au risque d’en utiliser de moins performantes mais permet un apprentissage itératif de la topologie du réseau et du comportement attendu par le routeur BGP. Ce système lutte contre les mauvaises configurations et les liens usurpés[96],[97]. Il permet également à un administrateur le déployant de connaître l’évolution de son réseau[98].

Cette solution est associée à un registre d’alerte d’internet (IAR) qui collecte les anomalies découvertes et les communiquent aux opérateurs pour les aider dans leur tâches[99],[100]. Au , 1.546.996 routes sont dans le RIB dont 5.111 d’elles étaient anormales d’après l’IAR[101].

Au niveau de l’équipement, la charge CPU est minimale et l’ajout de sessions BGP n’affecte pas significativement les besoins en mémoire de pgBGP mais il nécessite de base une extension de 20 Mo de RAM[101]. Une implémentation de pgBGP existe pour Quagga[102].

Autres propositions[modifier | modifier le code]

  • WATCHERS
  • Secure Origin BGP (soBGP)
  • Internet Route Verification (IRV)
  • Listen & Whisper
  • Descartes-BGP (D-BGP)
  • N-BGP
  • Grassroots-PKI
  • ...

Autres[modifier | modifier le code]

Contrôle par TTL[modifier | modifier le code]

Sur Internet, les paquets ont une durée de vie limitée pour éviter qu'au cas où une boucle survienne, les paquets ne subsistent pas indéfiniment dans la boucle. Cette durée de vie est indiquée par l'attribut Time to Live dans les paquets IP. Cette valeur fixée par l'émetteur du paquet et est décrémentée par chaque routeur de transit. Le paquet est détruit quand cette valeur arrive à 0 et son maximum est 255.

Le fonctionnement habituel de eBGP est de fixer le TTL des paquets d'une session BGP à 1, ce qui évite leur propagation accidentelle au-delà du sous-réseau. Cependant, ceci n'empêche pas une attaque où un routeur malveillant distant fixerait le TTL des paquets émis de façon que sa valeur arrive à 0 à la cible.

Pour améliorer la sécurité des protocoles de routage comme BGP, la RFC 5082[103] décrit un mécanisme dans lequel le TTL est initialement fixé à sa valeur maximale, 255, et la destination vérifie que le TTL à l'arrivée correspond bien au nombre de sauts attendu (254 en cas de connexion directe). À défaut, le paquet est rejeté.

Aspects économiques et sociaux[modifier | modifier le code]

Incidents[modifier | modifier le code]

Incident AS 7007 de 1997[modifier | modifier le code]

Le , l'AS 7007 a redistribué accidentellement BGP dans RIP et réciproquement. RIP étant un protocole classful, ceci a causé l'apparition de sous-réseaux de masque /24, plus spécifiques que les routes originales, ce qui a provoqué des instabilités importantes sur Internet[104],[105]. Cet incident a attiré l'attention sur ce type de vulnérabilité.

Incident YouTube de 2008[modifier | modifier le code]

Schéma représentant l'incident BGP du 24 février 2008.

Le , YouTube a été indisponible pendant deux heures environ. Le gouvernement (du Pakistan) a annoncé ce jour-là un blocage de YouTube. Pakistan Telecom a donc exécuté l’ordre[106],[107],[108].

Pakistan Telecom a alors annoncé à tous les routeurs des fournisseurs d'accès qu'il était la meilleure route à qui envoyer tout le trafic YouTube, qui a alors été coupé sur l'ensemble de la planète. Cette annonce a eu la même priorité que celle, légitime, de YouTube, car elle était plus spécifique (la longueur du préfixe était de 24 bits, contre 22 pour l'annonce légitime)[109].

Ce type d'incident est désigné sous les noms d'IP hijacking (détournement d'adresse IP) ou de black hole (trou noir).

Incident du 19 août 2009[modifier | modifier le code]

Le , un fournisseur d'accès japonais (AS 9354) annonça une route avec un attribut AS_PATH vide. Certaines implémentations de BGP de routeurs de fournisseur d'accès interrompent la session BGP avec une erreur quand ils reçoivent celui-ci, ce qui cause des perturbations dans plusieurs dorsales de FAI[110].

Incident du 27 août 2010[modifier | modifier le code]

Le , un attribut BGP expérimental utilisé dans un projet de recherche entre le RIPE NCC et l'université Duke a été propagé sur Internet et a révélé un bug dans l'implémentation BGP de certains constructeurs. Ceci a provoqué l'instabilité de plusieurs milliers de préfixes sur Internet[111],[112].

Request For Comments[modifier | modifier le code]

Les Request for comments (RFC) sont des documents officiels décrivant les standards d'internet. Voici une liste exhaustive des documents de cette collection ayant un rapport avec BGP et sa sécurité. (dernière mise à jour : 14/01/2014)

  • RFC 793 : Transmission Control Protocol (TCP), écrit en .
  • RFC 1321 (mis à jour par RFC 6151) : l'Algorithme MD5 Message-Digest, écrit en .
  • RFC 1654 (obsolète depuis RFC 1771) : Border Gateway Protocol 4 (BGP-4), écrit en .
  • RFC 1771 (obsolète depuis RFC 4271) : Première redéfinition de Border Gateway Protocol 4 (BGP-4), écrit en .
  • RFC 2385 (mis à jour par RFC 6691; obsolète depuis RFC 5925) : Option de signature MD5 pour TCP dans BGP (TCP-MD5), écrit en .
  • RFC 3280 (mis à jour par RFC 4325, RFC 4630; obsolète depuis RFC 5280) : « Profile » d'un certificat X.509 pour une infrastructure à clef publique (PKI), écrit en .
  • RFC 3779 : Extension de X.509 pour identification des adresses IP et des identifieurs de systèmes autonomes (AS), écrit en .
  • RFC 4271 (mis à jour par RFC 6286, RFC 6608, RFC 6793) : Respécification du protocole Border Gateway 4 (BGP-4), écrit en .
  • RFC 4272 : Analyse des vulnérabilités de sécurité de BGP, écrit en .
  • RFC 4325 (obsolète depuis RFC 5280) : Extension des certificats X.509 pour les informations d'accès à une infrastructure à clef publique (PKI), écrit en .
  • RFC 4630 (obsolète depuis RFC 5280) : Mise à jour dans le traitement de la Directorystring pour le « profile » des certificats X.509 pour une infrastructure à clef publique (PKI), écrit en .
  • RFC 4893 (obsolète depuis RFC 6793) : Énonciation de l'idée d'identifier les systèmes autonomes (AS) sur quatre octets, écrit en .
  • RFC 5280 (mis à jour par RFC 6818) : Respécification du « profile » d'un certificat X.509 pour une infrastructure à clef publique (PKI), écrit en .
  • RFC 5925 : Option de signature Authentification pour TCP dans BGP (TCP-AO), écrit en .
  • RFC 5926 : Liste des algorithmes cryptographiques disponibles pour TCP-AO, écrit en .
  • RFC 6151 : Mise à jour des considérations de sécurité pour les algorithmes MD5 Message Digest et HMAC-MD5, écrit en .
  • RFC 6286 : Mise à jour des identifiants BGP, écrit en .
  • RFC 6480 : Description d'une architecture pour une infrastructure afin d'améliorer la sécurité du routage sur Innternet, écrit en .
  • RFC 6481 : Description de l'infrastructure à clef publique de ressources (RPKI), écrit en .
  • RFC 6482 : « Profile » des autorisations d'origine d'une route (ROA), écrit en .
  • RFC 6483 : Validation de l'origine des routes en utilisant ROA et RPKI, écrit en .
  • RFC 6608 : Rajout de code d'erreur pour BGP, écrit en .
  • RFC 6691 : Options TCP et le Maximum Segment Size (MSS), écrit en .
  • RFC 6793 : Augmentation de la taille des identifiants de systèmes autonomes (AS) à quatre octets, écrit en .
  • RFC 6811 : Mécanisme pour valider l'origine d'un préfixe IP, écrit en .
  • RFC 6952 : Analyse de divers protocole dont BGP dans la distribution des clefs et l'authentification, écrit en .
  • RFC 6978 : Solution pour l'option TCP-AO malgré des routeurs NAT, écrit en .

Bibliographie[modifier | modifier le code]

  • (en) Zhang Ke, Zhao Xiaoliang et S. F.Wu Wu, « An analysis on selective dropping attack in BGP », Performance, Computing, and Communications, 2004 IEEE International Conference on,‎ , p. 593 - 599 (ISBN 0-7803-8396-6, DOI 10.1109/PCCC.2004.1395106)
  • (en) M. Chuah et K. Huang, « Detecting Selective Dropping Attacks in BGP », Local Computer Networks, Proceedings 2006 31st IEEE Conference on, Tampa, FL,‎ , p. 959 - 966 (ISSN 0742-1303, e-ISSN 1-4244-0419-3[à vérifier : ISSN invalide], DOI 10.1109/LCN.2006.322209)
  • (en) Kim Jintae, S.Y. Ko, D.M. Nicol, X.A. Dimitropoulos et G.F. Riley, « A BGP attack against traffic engineering », Simulation Conference, 2004. Proceedings of the 2004 Winter, vol. 1,‎ , p. 959 - 966 (ISBN 0-7803-8786-4, DOI 10.1109/WSC.2004.1371332)
  • (en) Ola Nordström et Constantinos Dovrolis, « Beware of BGP attacks », ACM SIGCOMM Computer Communication Review, New York, NY, USA, vol. 34, no 2,‎ , p. 1 - 8 (ISSN 0146-4833, DOI 10.1145/997150.997152)
  • (en) S. Kent, C. Lynn et K. Seo, « Secure Border Gateway Protocol (S-BGP) », Selected Areas in Communications, IEEE Journal on, vol. 18, no 4,‎ , p. 582 - 592 (ISSN 0733-8716, DOI 10.1109/49.839934)
  • (en) S. Murphy, O. Gudmundsson, R. Mundy et B. Wellington, « Retrofitting security into Internet infrastructure protocols », DARPA Information Survivability Conference and Exposition, 2000. DISCEX '00. Proceedings, vol. 1,‎ , p. 3-17 (ISBN 0-7695-0490-6, DOI 10.1109/DISCEX.2000.824937)
  • (en) Danny Doleva, Sugih Jaminb, Osnat Mokrync et Yuval Shavittc, « Internet resiliency to attacks and failures under BGP policy routing », Computer Networks, vol. 50, no 16,‎ , p. 3183–3196 (DOI 10.1016/j.comnet.2005.11.010)
  • (en) Sandra L. Murphy, « Secure Inter-Domain Routing Standards Evolution and Role in the Future GIG », Military Communications Conference, 2007. MILCOM 2007. IEEE, Orlando, FL, USA,‎ , p. 1 - 7 (e-ISSN 978-1-4244-1513-7[à vérifier : ISSN invalide], DOI 10.1109/MILCOM.2007.4455177)
  • (en) M.O. Nicholes et B. Mukherjee, « A survey of security techniques for the border gateway protocol (BGP) », Communications Surveys & Tutorials, IEEE, vol. 11, no 1 (premier trimestre 2009),‎ , p. 52 - 65 (ISSN 1553-877X, DOI 10.1109/SURV.2009.090105)
  • (en) K. Butler, T.R. Farley, P. McDaniel et J. Rexford, « A Survey of BGP Security Issues and Solutions », Proceedings of the IEEE, vol. 98, no 1 (premier trimestre 2010),‎ , p. 100 - 122 (ISSN 0018-9219, DOI 10.1109/JPROC.2009.2034031)
  • (en) Y. Rekhter, T. Li et S. Hares, « A Border Gateway Protocol 4 (BGP-4) », RFC 4271,‎ , p. 97 - 99 (lire en ligne)
  • (en) S. Murphy, « BGP Security Vulnerabilities Analysis », RFC 4272, Network Working Group, Sparta, Inc.,‎ (lire en ligne)
  • (en) Sharon Goldberg (Microsoft Research, Boston, MA, USA), Michael Schapira (Yale & Berkeley, New Haven, CT, USA), Peter Hummon (AT&T Research, Florham Park, NJ, USA) et Jennifer Rexford (Princeton University, Princeton, NJ, USA), « How Secure are Secure Interdomain Routing Protocols? », ACM SIGCOMM Computer Communication Review - SIGCOMM '10, ACM New York, NY, USA, vol. 40, no 4,‎ , p. 87 - 98 (ISSN 0146-4833, DOI 10.1145/1851275.1851195)
  • (en) Dan Wendlandt (Carnegie Mellon), Ioannis Avramopoulos (Princeton), David G. Andersen (Carnegie Mellon) et Jennifer Rexford (Princeton), « Don’t Secure Routing Protocols, Secure Data Delivery », In Proc. 5th ACM Workshop on Hot Topics in Networks,‎ (lire en ligne)
  • (en) Haowen Chan (Carnegie Mellon University), Debabrata Dash (Carnegie Mellon University), Adrian Perrig (Carnegie Mellon University) et Hui Zhang (Carnegie Mellon University), « Modeling adoptability of secure BGP protocol », SIGCOMM '06 Proceedings of the 2006 conference on Applications, technologies, architectures, and protocols for computer communications, ACM New York, NY, USA ©2006,‎ , p. 279-290 (ISBN 1-59593-308-5, DOI 10.1145/1159913.1159946)
  • (en) Ron Rivest, « The MD5 Message-Digest Algorithm », RFC, Network Working Group, no 1321,‎ , p. 1-21 (lire en ligne, consulté le )
  • (en) S. M. Bellovin, « Security problems in the TCP/IP protocol suite », ACM SIGCOMM Computer Communication Review, ACM New York, NY, USA, vol. 2, no 19,‎ , p. 32-48 (DOI 10.1145/378444.378449)
  • (en) A. Heffernan, « Protection of BGP Sessions via the TCP MD5 Signature Option », Internet-Drafts, Network Working Group,‎ , p. 1-6 (lire en ligne, consulté le )
  • (en) Wang Xiaoyun et Yu Hongbo, « How to Break MD5 and Other Hash Functions », Advances in Cryptology – EUROCRYPT 2005, Springer Berlin Heidelberg, vol. 3494,‎ , p. 19-35 (ISBN 978-3-540-25910-7 et 978-3-540-32055-5, ISSN 0302-9743, DOI 10.1007/11426639_2, lire en ligne, consulté le )
  • (en) J. Touch, « Defending TCP Against Spoofing Attacks », Internet-Draft,‎ , p. 1-28 (lire en ligne)
  • (en) A. Ramaiah, R. Stewart et M. Dalal, « Improving TCP's Robustness to Blind In-Window Attacks », Internet-Draft,‎ , p. 1-19 (ISSN 2070-1721, lire en ligne)
  • (en) Ratul Mahajan, David Wetheral et Tom Anderson, « Understanding BGP misconfiguration », ACM SIGCOMM Computer Communication Review, ACM New York, NY, USA,‎ , p. 3-16 (ISBN 1-58113-570-X, DOI 10.1145/964725.633027)
  • (en) Josh Karlin, Stephanie Forrest et Jennifer Rexford, « Autonomous security for autonomous systems », Computer Networks: The International Journal of Computer and Telecommunications Networking, Elsevier North-Holland, Inc. New York, NY, USA, vol. 52, no 15,‎ , p. 2908-2923 (DOI 10.1016/j.comnet.2008.06.012)
  • (en) Josh Karlin, Stephanie Forrest et Jennifer Rexford, « Pretty Good BGP: Improving BGP by Cautiously Adopting Routes », Network Protocols, 2006. ICNP '06. Proceedings of the 2006 14th IEEE International Conference on,‎ , p. 290 - 299 (ISBN 1-4244-0594-7 et 1-4244-0593-9, DOI 10.1109/ICNP.2006.320179)
  • (en) P.C. van Oorschot, Tao Wan et Evangelos Kranakis, « On interdomain routing security and pretty secure BGP (psBGP) », ACM Transactions on Information and System Security (TISSEC) International Conference on, ACM New York, NY, USA, vol. 10, no 3,‎ , p. 1-41 (DOI 10.1145/1266977.1266980)
  • (en) Brijesh Kumar, « Integration of security in network routing protocols », ACM SIGSAC Review, ACM New York, NY, USA, vol. 11, no 2,‎ , p. 18-25 (DOI 10.1145/153949.153953)
  • (en) Brijesh Kumar et Jon Crowcroft, « Integrating security in inter-domain routing protocols », ACM SIGCOMM Computer Communication Review, ACM New York, NY, USA, vol. 23, no 5,‎ , p. 36-51 (DOI 10.1145/165611.165615)
  • (en) B. R. Smith et J.J. Garcia-Luna-Aceves, « Securing the border gateway routing protocol », Global Telecommunications Conference, 1996. GLOBECOM '96. 'Communications: The Key to Global Prosperity, london,‎ , p. 81-85 (ISBN 0-7803-3336-5, DOI 10.1109/GLOCOM.1996.586129)
  • (en) B. R. Smith et J.J. Garcia-Luna-Aceves, « Securing distance-vector routing protocols », Network and Distributed System Security, 1997. Proceedings., 1997 Symposium on, San Diego, CA,‎ , p. 85 - 92 (ISBN 0-8186-7767-8, DOI 10.1109/NDSS.1997.579225)

Glossaire & Références[modifier | modifier le code]

Glossaire[modifier | modifier le code]

  1. ↑ Message Digest 5 (MD5) est une fonction de hachage cryptographique pour obtenir une empreinte/signature d'un ensemble de données.
  2. ↑ La fraîcheur d’un message est l’idée d’éviter la réutilisation de messages anciens, qui ont pu être retardés ou utilisés par un attaquant qui pourrait modifier les tables de routages.
  3. ↑ Masque de sous-réseau, ensemble d'adresses partageant le même préfixe de n bit. Notation : 192.0.0.0/8 pour les réseaux d'un préfixe de 8 bits dont la valeur est 192.
  4. ↑ Répétition et redondance des connexions entre des réseaux. Le réseau A est connecté aux réseaux B et C, et B et C sont également connectés.

Références[modifier | modifier le code]

  1. ↑ Bellovin 1989
  2. ↑ a b et c Van Oorschot 2007, p. 2
  3. ↑ a et b Perlman 1988, p. 90
  4. ↑ a b c d e f g h i j k l m n o p q r s t u v w et x Nicholes 2009, p. 2
  5. ↑ (en) Ron Rivest, « The MD5 Message-Digest Algorithm », Request for comments no 1321,
  6. ↑ Kumar 1993
  7. ↑ a b c d e et f Kumar 1993, p. 6
  8. ↑ Kumar 1993, p. 8
  9. ↑ a et b Kumar 1993, p. 7
  10. ↑ a b c d et e Nicholes 2009, p. 9
  11. ↑ a et b Kumar and Crowcroft 1993
  12. ↑ (en) Request for comments no 1321
  13. ↑ a b c et d Van Oorschot 2007, p. 37
  14. ↑ Nicholes 2009, p. 12
  15. ↑ (en) Y. Rekhter, T. Li, « A Border Gateway Protocol 4 (BGP-4) », Request for comments no 1654,
  16. ↑ (en) Y. Rekhter, T. Li, « A Border Gateway Protocol 4 (BGP-4) », Request for comments no 1771,
  17. ↑ (en) S. Murphy, « BGP Security Vulnerabilities Analysis », Request for comments no 4272,
  18. ↑ a et b Nicholes 2009, p. 7
  19. ↑ Smith 1996, p. 1
  20. ↑ a b et c Heffernan 1998
  21. ↑ Nicholes 2009, p. 8
  22. ↑ (en) R. Rousley, W. Polk, W. Ford, D. Solo, « Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile », Request for comments no 3280,
  23. ↑ a b et c Van Oorschot 2007, p. 38
  24. ↑ (en) G. Huston, G. Michaelson, R. Loomans, « A Profile for X.509 PKIX Resource Certificates », Request for comments no 6487,
  25. ↑ Pretty Good BGP: Improving BGP by Cautiously Adopting Routes
  26. ↑ Analyzing BGP ASPATH Behavior in the Internet
  27. ↑ a et b Nicholes 2009, p. 10
  28. ↑ Nicholes 2009, p. 13
  29. ↑ a et b Nicholes 2009, p. 11
  30. ↑ (en) Q. Vohra, « BGP Support for Four-octet AS Number Space », sur tools.ietf.org, .
  31. ↑ Marsan 2009
  32. ↑ Bortzmeyer 2009
  33. ↑ Touch 2010
  34. ↑ a b c d e f g h et i Smith 1997, p. 1
  35. ↑ Murphy 2006, p. 18
  36. ↑ Murphy 2006, p. 16
  37. ↑ a b et c Van Oorschot 2007, p. 8
  38. ↑ a et b Murphy 2006, p. 7
  39. ↑ a b et c Butler 2010, p. 4
  40. ↑ Kumar 1993, p. 4
  41. ↑ Butler 2010, p. 5
  42. ↑ Kent 2013, p. 6
  43. ↑ Kent 2013, p. 4
  44. ↑ Kent 2013, p. 6-7
  45. ↑ a b et c Kent 2013, p. 7
  46. ↑ Kent 2013, p. 7-8
  47. ↑ a b c d e et f Nicholes 2009, p. 54
  48. ↑ Pilosov 2008, p. 2
  49. ↑ Pilosov 2008, p. 22
  50. ↑ Pilosov 2008, p. 4
  51. ↑ Pilosov 2008, p. 18
  52. ↑ Pilosov 2008, p. 8
  53. ↑ a b c d e f g h i j k et l Murphy 2006, p. 5
  54. ↑ a et b Murphy 2006, p. 4
  55. ↑ Nicholes 2009, p. 16
  56. ↑ Smith 1996
  57. ↑ PrettyGood BGP: Improving BGP by Cautiously Adopting Routes
  58. ↑ a b c d e f g et h Butler 2010, p. 8
  59. ↑ Bellovin 1989, p. 14
  60. ↑ Bellovin 1989, p. 1
  61. ↑ Jombart 2003
  62. ↑ a et b Heffernan 1998, p. 1
  63. ↑ a b c d e et f Bortzmeyer 2009
  64. ↑ Heffernan 1998, p. 2
  65. ↑ Heffernan 1998, p. 5
  66. ↑ Xiaoyun 2005, p. 1
  67. ↑ Heffernan 1998, p. 4
  68. ↑ Sotirov 2008
  69. ↑ Rekhter 2006, p. 94
  70. ↑ Murphy 2006, p. 6-7
  71. ↑ Ramaiah 2010
  72. ↑ Touch 2007, p. 11
  73. ↑ a et b Bortzmeyer 2010
  74. ↑ Touch 2010, p. 43
  75. ↑ Touch 2010, p. 10
  76. ↑ Touch 2010, p. 11
  77. ↑ Touch 2010, p. 24
  78. ↑ Touch 2010, p. 20
  79. ↑ Touch 2010, p. 33
  80. ↑ Touch 2010, p. 34
  81. ↑ Touch 2010, p. 35
  82. ↑ a b et c Touch 2010, p. 36
  83. ↑ Bortzmeyer 2013
  84. ↑ Touch 2013, p. 4
  85. ↑ Bortzmeyer 2013
  86. ↑ a et b Kent 2003
  87. ↑ Van Oorschot 2007, p. 39
  88. ↑ a b et c Butler 2010, p. 16
  89. ↑ a b c d e et f Van Oorschot 2007, p. 3
  90. ↑ a b et c Van Oorschot 2007, p. 4
  91. ↑ Nicholes 2009, p. 7-8
  92. ↑ Ratul 2002, p. 13
  93. ↑ Bortzmeyerl2008, p. 13
  94. ↑ Karlinl2006
  95. ↑ Karlinl2008
  96. ↑ Karlinl2006, p. 2
  97. ↑ Karlinl2008, p. 6
  98. ↑ Butler 2010, p. 19
  99. ↑ Karlin 2008, p. Internet Alert Registry
  100. ↑ Karlinl2008, p. 7
  101. ↑ a et b Karlin 2008, p. Overview
  102. ↑ Karlin 2008, p. PGBGP + Quagga
  103. ↑ (en) Request for comments no 5082
  104. ↑ Bono 1997
  105. ↑ Neumann 1997
  106. ↑ CrashDump.com 2009
  107. ↑ BBC News 2008
  108. ↑ RIPE NCC 2008
  109. ↑ Bortzmeyer 2008
  110. ↑ Boyadjiev 2009
  111. ↑ McMillan 2010
  112. ↑ Romijn 2010

Voir aussi[modifier | modifier le code]

Liens externes[modifier | modifier le code]

Ce document provient de « https://fr.wikipedia.org/w/index.php?title=Sécurité_du_Border_Gateway_Protocol&oldid=214190531 ».