Sécurité du Border Gateway Protocol

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 juillet 1994, 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].

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 novembre 2001, Xiaoliang Zhao publie un Internet DraftInternet 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].

En janvier 2006, 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 février 2007, 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 juin 2010, 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 mars 2011, 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 décembre 2012. (RFC 6793)

En février 2012, 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 janvier 2013, 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)

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.

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].

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.

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-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.

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.

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.

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 routeur 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].

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].

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].

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].

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].

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].

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

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].

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].

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.

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.

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.

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 décembre 2008, 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].

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) est un protocole de communication sécurisé par des solutions crptographiques pour les réseaux IP.

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].

En juillet 2013, 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].

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).

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.

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).

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].

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.

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) 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].

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-)pé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 23 juillet 2008, 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].

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

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é.

Le 25 avril 1997, 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é.

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

Le 24 février 2008, 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).

Le 19 août 2009, 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].

Le 27 août 2010, 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].

• (fr) Stéphane Bortzmeyer, « [[:rfc:4272|RFC 4272]]: BGP Security Vulnerabilities Analysis », 21 janvier 2006
• (fr) « Protocole BGP, l’Internet en danger ? », 29 août 2008
• (fr) Cédric Llorens et Fabrice Bruel, « Quelques éléments de sécurité autour du protocole de routage BGP », Misc 21, 18 octobre 2008
• (en) John Leyden, « Mystery traffic redirection attack pulls net traffic through Belarus, Iceland », The register, 22 novembre 2013
• (de) Kahle Christian, « Route Injection: Datenstrom am Router umgeleitet », 25 novembre 2013
• (en) Michael Mimoso, « Internet Traffic Following Malicious Detours Via Route Injection Attacks », 20 novembre 2013
• (fr) Guillaume Lucas (Université de Strasbourg), « Sécuriser le routage sur Internet », 7 mai 2013
• (en) « Stealing the internet », DefCon 16, 8 août 2008
• (fr) Joseph E. Fares, « Routage inter-domaine : Sécurité et enjeux », 20 décembre 2004
• (fr) « Influence des bonnes pratiques sur les incidents BGP », SSTIC 2012, 2012
• (fr) Laurent Levier, « Attaques des réseaux », Ed. Techniques Ingénieur, 2005
• (en) « Secure Inter-Domain Routing (sidr) documents », ietf, 2013
• (en) Dominique Lacroix, « Le routage, enjeu de cyberstratégie », Le Monde, 2012
• (en) Radia Joy Perlman, « Network Layer Protocols with Byzantine Robustness », Massachusetts Institute of Technology, 24 août 1988, p. 1-121
• (en) S. Kent et A. Chi, « Threat Model for BGP Path Security », 22 novembre 2013, p. 1 - 19
• (fr) Nicolas Jombart et Franck Davy, « Les signatures MD5 des segments TCP », 14 août 2003
• (fr) Stéphane Bortzmeyer, « [[:rfc:2385|RFC 2385]]: Protection of BGP Sessions via the TCP MD5 Signature Option », 6 janvier 2009 (consulté le 12 décembre 2013)
• (en) Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik et Benne de Weger, « MD5 considered harmful today », 30 décembre 2008 (consulté le 12 décembre 2013)
• (en) Josh Karlin, « Pretty Good BGP : autonomous security for autonomous systems », 23 juillet 2008 (consulté le 13 décembre 2013)
• (fr) Stéphane Bortzmeyer, « La sécurité de BGP et l'importance des réactions rapides », 10 septembre 2008 (consulté le 13 décembre 2013)
• (en) Carolyn Duffy Marsan, « Detecting Internet routing "lies" », sur Network World, 2009 (consulté le 15 décembre 2013)
• (en) « The TCP Authentication Option », sur Internet Engineering Task Force (IETF), 2010 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « [[:rfc:5925|RFC 5925]]: The TCP Authentication Option », sur http://www.bortzmeyer.org/, 2010 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « [[:rfc:6978|RFC 6978]]: A TCP Authentication Option NAT Extension », sur http://www.bortzmeyer.org/, 2013 (consulté le 15 décembre 2013)
• (en) J. Touch, « A TCP Authentication Option Extension for NAT Traversal », sur http://www.rfc-editor.org/, 2013 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « [[:rfc:6811|RFC 6811]]: BGP Prefix Origin Validation », sur http://www.bortzmeyer.org/, 2013 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « Des certificats pour prouver qu'on est titulaire d'une ressource Internet », sur http://www.bortzmeyer.org/, 2009 (consulté le 8 janvier 2014)
• (en) Stephen T. Kent, « Securing the Border Gateway Protocol », sur http://www.cisco.com/, 2003 (consulté le 11 janvier 2014)
• (en) Vincent J. Bono, « 7007 Explanation and Apology », 26 avril 1997
• (en) Peter G. Neumann, « Internet routing black hole », 1^er mai 1997
• « Protocole BGP, l’Internet en danger ? », 29 août 2009
• (en) BBC News, « Pakistan lifts the ban on YouTube », 26 février 2008
• (en) RIPE NCC, « YouTube Hijacking: A RIPE NCC RIS case study », 17 mars 2008
• Stéphane Bortzmeyer, « Le Pakistan pirate YouTube », 25 février 2008
• (en) Nick Boyadjiev, « Anyone else seeing "(invalid or corrupt AS path) 3 bytes E01100" ? », 2 octobre 2009
• (en) Robert McMillan, « Research experiment disrupts Internet, for some », 27 août 2010
• (en) Erik Romijn, « RIPE NCC and Duke University BGP Experiment », 31 août 2010