Sécurité du 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

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

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), il réétudiera le sujet en 2004.

Dans sa thèse Network Layer Protocols with Byzantine Robustness, Radia Perlman reconnaît et étudie les problèmes de la sécurisation des infrastructures de routage. 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.

En 1992, Ronald Rivest publie pour le compte du Network Working Group le document la RFC 1321 où il décrit un algorithme de signature rapide Message Digest 5 (MD5) 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” 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 ; 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 qui résoudrait le problème. 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 et fait une distinction entre les routages internes aux domaines (iBGP) et externes (eBGP)

La même année, Brijesh Kumar écrit avec Jon Crowcroft (en) sur l’utilisation d’une signature numérique. Ils mentionnent l'algorithme MD5 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.

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

Des signatures numériques à la redéfinition de Cisco

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) publiera des RFC analysant les vulnérabilités de sécurité.

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). Cette modification améliore l’authentification des chemins et permet d’éviter les boucles.

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

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

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

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.

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 Ces PKI seraient tenues dans les registres internet régionaux (RIR) et parallèles au système existant d’AS.

En novembre 2001, 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. 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. Les mises à jour dans la base de données sont cryptées avec IPsec ou MD5 pour en assurer la sécurité

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

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

C. Kruegel tente de valider les chemins en vérifiant les nœuds traversés. 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.

Geoffrey Goodell propose le protocole et l’architecture Interdomain Routing Validator (IRV). 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.

De BGP 4 à l'idée de BGPSEC

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

Josh Karlin propose Pretty Good BGP 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.

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

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

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. Ce mécanisme permet l’évaluation des AS et la confiance qu’on peut porter à leurs annonces. Selon ces évaluations, on peut ralentir la propagation des annonces.

Patrick Reynolds propose N-BGP, un outil de surveillance externe pour la sécurité de BGP. 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.

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). 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. Au bout du compte, lorsqu’un utilisateur souhaite rejoindre une destination, plusieurs chemins sont à sa disposition.

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

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

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 et annonce de rpki-engine.

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.

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)

Définition des points de sécurité et des vulnérabilités

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

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

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 mais la plus importante des vulnérabilités de BGP est son protocole de communication TCP. 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é

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 .

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

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

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é

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) lors de leur trajets entre les paires. L’absence d’intégrité entraîne la possibilité que les routes et l’état des routeurs soient manipulés par un attaquant ou annonceur BGP configuré mal intentionnellement.

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

Confidentialité

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

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é

La disponibilité est l’assurance que les services sont accessibles et donc que les chemins soient praticables pour les entités autorisées. 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. 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.

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

Non-répudiation

Non-Repudiation est la protection contre les fausses répudiations de communication. 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

Le contrôle d’accès est la protection contre les utilisations non autorisées des ressources d’un système, (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 ? 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

Une menace est définie comme un adversaire compétent et motivé. 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.

Les équipements réseaux

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

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

Hackers

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.

Criminels

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.

Registres

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.

Nations

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

Attaques

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

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.
• 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.
• l’usurpation d’un message NOTIFCATION cause la fin immédiate des communications par le routeur receveur.
• Rejouer un ancien message de mise à jour peut mener à ajouter ou supprimer une route.

Shunt

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é. Cette attaque utilise la génération d’un chemin sain qui ne sera pas affecté et un empoisonnement des annonceurs BGP. 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 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.

Dommages

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.

• Famine : Le trafic de données destinées à un nœud est transmis à une partie du réseau qui ne peut le délivrer.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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.
• 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é.
• 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.
• Instabilité : BGP devient instable de telle sorte que la convergence sur un état de transfert global n'est pas atteinte.
• Surcharge (overload) : Les messages BGP deviennent une portion significative du trafic que le réseau doit supporter.
• É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.
• 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.

Solutions

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

Moyens

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

Cryptographie

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 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 . 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. Ces fonctions sont utilisés dans les options TCP tels que MD5 et Authentification pour assurer l’intégrité entre deux routeurs voisins.

Base de données

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), 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) et le serveur whois (Kruegel, 2003).

Protocole en groupe de recouvrement

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é

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

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

Intégrité MD5

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). Effectivement, l’un des nombreux défauts de sécurité est basé sur l’extrême dangerosité de la confiance des annonceurs en l’authentification via l’adresse IP. 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 mais ne protègent pas contre ces attaques car elles opèrent en dessous de la couche application.

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. 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.Cette sécurité repose sur le principe que l'attaquant qui ignore le secret ne peut pas fabriquer de faux paquets. (signature des paquets)

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.

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. Les implémentation doivent supporter au minimum une clef composé d’une chaîne ASCII de 80 octets ou moins.

Malheureusement, MD5 a montré des faiblesse aux attaques de recherche de collisionet est considéré par certains comme insuffisamment résistant en raison de la criticité de l’application.(En décembre 2008, une attaque réussie contre MD5 a permis de générer de faux certificats X.509 ) Et même si MD5 a été rendu obligatoire , son champ prévu dans BGP fût largement inutilisé. 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 et la non protection des bugs d'un paire.

Atténuation de la fenêtre de TCP

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

Internet Protocol Security (IPSEC)

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

TCP AO

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

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.

Mais elle :

• permet le choix entre plusieurs fonctions de hachage qui sont recensées dans la RFC 5926 (Agilité d’algorithme)
• génère automatiquement des clefs de session grâce à des clefs maîtresses (MKT) définies par le champ KeyID des paquets TCP 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).

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

Un intermédiaire (middlebox) risque de rejeter ou modifier les paquets. S’il modifie l’adresse IP (routeur NAT), TCP-AO ne peut plus fonctionner. Il faudrait alors encapsuler le flux TCP ou de compter sur l'extension NAT du RFC 6978. 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é.

TCP AO NAT

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.

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.

ROA/RPKI

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

Voir aussi Resource Public Key Infrastructure

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

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

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.

Proposées par la recherche

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

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

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

Pretty Secure BGP (psBGP)

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

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. 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.
• quelques entités (AS) doivent avoir connaissance de l’assignation des préfixes.
• les corroborations de différentes sources assure la véracité d’une information.

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)
2. l’évaluation des AS étrangers facilite les vérifications et la sécurité pour l’équilibrage de charges.
3. Une liste des préfixes (PAL) pour chaque AS contenant ceux qui lui sont locaux et ceux de ses voisins.
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.

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

Pretty Good BGP

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

Pretty good BGP (pgBGP) est un système de détection distribué des anomalies proposé en 2006 par Josh Karlin, Stephanie Forrest et Jennifer Rexford et amélioré en 2008. 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. Il permet également à un administrateur le déployant de connaître l’évolution de son réseau.

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. Au 23 juillet 2008, 1.546.996 routes sont dans le RIB dont 5.111 d’elles étaient anormales d’après l’IAR.

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. Une implémentation de pgBGP existe pour Quagga.

Autres propositions

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

Autres

Contrôle par TTL

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

Incidents

Incident AS 7007 de 1997

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. Cet incident a attiré l'attention sur ce type de vulnérabilité.

Incident YouTube de 2008

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.

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

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

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.

Incident du 27 août 2010

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.

Request For Comments

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 septembre 1981.
• RFC 1321 (mis à jour par RFC 6151) : l'Algorithme MD5 Message-Digest, écrit en avril 1992.
• RFC 1654 (obsolète depuis RFC 1771) : Border Gateway Protocol 4 (BGP-4), écrit en juillet 1994.
• RFC 1771 (obsolète depuis RFC 4271) : Première redéfinition de Border Gateway Protocol 4 (BGP-4), écrit en mars 1995.
• RFC 2385 (mis à jour par RFC 6691; obsolète depuis RFC 5925) : Option de signature MD5 pour TCP dans BGP (TCP-MD5), écrit en août 1998.
• 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 avril 2002.
• RFC 3779 : Extension de X.509 pour identification des adresses IP et des identifieurs de systèmes autonomes (AS), écrit en juin 2004.
• RFC 4271 (mis à jour par RFC 6286, RFC 6608, RFC 6793) : Respécification du protocole Border Gateway 4 (BGP-4), écrit en janvier 2006.
• RFC 4272 : Analyse des vulnérabilités de sécurité de BGP, écrit en janvier 2006.
• 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 décembre 2005.
• 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 août 2006.
• RFC 4893 (obsolète depuis RFC 6793) : Énonciation de l'idée d'identifier les systèmes autonomes (AS) sur quatre octets, écrit en mai 2007.
• RFC 5280 (mis à jour par RFC 6818) : Respécification du « profile » d'un certificat X.509 pour une infrastructure à clef publique (PKI), écrit en mai 2008.
• RFC 5925 : Option de signature Authentification pour TCP dans BGP (TCP-AO), écrit en juin 2010.
• RFC 5926 : Liste des algorithmes cryptographiques disponibles pour TCP-AO, écrit en juin 2010.
• RFC 6151 : Mise à jour des considérations de sécurité pour les algorithmes MD5 Message Digest et HMAC-MD5, écrit en mars 2011.
• RFC 6286 : Mise à jour des identifiants BGP, écrit en juin 2011.
• RFC 6480 : Description d'une architecture pour une infrastructure afin d'améliorer la sécurité du routage sur Innternet, écrit en février 2012.
• RFC 6481 : Description de l'infrastructure à clef publique de ressources (RPKI), écrit en février 2012.
• RFC 6482 : « Profile » des autorisations d'origine d'une route (ROA), écrit en février 2012.
• RFC 6483 : Validation de l'origine des routes en utilisant ROA et RPKI, écrit en février 2012.
• RFC 6608 : Rajout de code d'erreur pour BGP, écrit en mai 2012.
• RFC 6691 : Options TCP et le Maximum Segment Size (MSS), écrit en juillet 2012.
• RFC 6793 : Augmentation de la taille des identifiants de systèmes autonomes (AS) à quatre octets, écrit en décembre 2012.
• RFC 6811 : Mécanisme pour valider l'origine d'un préfixe IP, écrit en janvier 2013.
• RFC 6952 : Analyse de divers protocole dont BGP dans la distribution des clefs et l'authentification, écrit en mai 2013.
• RFC 6978 : Solution pour l'option TCP-AO malgré des routeurs NAT, écrit en juillet 2013.

Bibliographie

• (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,‎ 2004, 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,‎ 14-16 novembre 2006, 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,‎ 5-8 décembre 2004, 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, n^o 2,‎ avril 2004, 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, n^o 4,‎ 6 août 2002, 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,‎ 25-27 janvier 2000, 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, n^o 16,‎ 14 novembre 2006, 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,‎ 29-31 octobre 2007, 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, n^o 1 (premier trimestre 2009),‎ 4 mars 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, n^o 1 (premier trimestre 2010),‎ 22 décembre 2009, 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,‎ janvier 2006, p. 97 - 99 (lire en ligne)
• (en) S. Murphy, « BGP Security Vulnerabilities Analysis », RFC 4272, Network Working Group, Sparta, Inc.,‎ janvier 2006 (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, n^o 4,‎ octobre 2010, 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,‎ novembre 2006 (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,‎ 11 septembre 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, n^o 1321,‎ avril 1992, p. 1-21 (lire en ligne, consulté le 12 décembre 2013)
• (en) S. M. Bellovin, « Security problems in the TCP/IP protocol suite », ACM SIGCOMM Computer Communication Review, ACM New York, NY, USA, vol. 2, n^o 19,‎ 1^er avril 1989, 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,‎ août 1998, p. 1-6 (lire en ligne, consulté le 12 décembre 2013)
• (en) Wang Xiaoyun et Yu Hongbo, « How to Break MD5 and Other Hash Functions », Advances in Cryptology – EUROCRYPT 2005, Springer Berlin Heidelberg, vol. 3494,‎ août 2005, 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 12 décembre 2013)
• (en) J. Touch, « Defending TCP Against Spoofing Attacks », Internet-Draft,‎ juillet 2007, 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,‎ août 2010, 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,‎ 2002, 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, n^o 15,‎ octobre 2008, 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,‎ 12-15 novembre 2006, 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, n^o 3,‎ juillet 2007, 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, n^o 2,‎ printemps 1993, 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, n^o 5,‎ octobre 1993, 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,‎ 18-22 novembre 1996, 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,‎ 10-11 février 1997, p. 85 - 92 (ISBN 0-8186-7767-8, DOI 10.1109/NDSS.1997.579225)

Glossaire & Références

Voir aussi

• Border Gateway Protocol

Liens externes

• (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 »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 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 »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 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 »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 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" »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 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 bortzmeyer.org, 2010 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « [[:rfc:6978|RFC 6978]]: A TCP Authentication Option NAT Extension », sur bortzmeyer.org, 2013 (consulté le 15 décembre 2013)
• (en) J. Touch, « A TCP Authentication Option Extension for NAT Traversal », sur rfc-editor.org, 2013 (consulté le 15 décembre 2013)
• (fr) Stéphane Bortzmeyer, « [[:rfc:6811|RFC 6811]]: BGP Prefix Origin Validation », sur 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 bortzmeyer.org, 2009 (consulté le 8 janvier 2014)
• (en) Stephen T. Kent, « Securing the Border Gateway Protocol »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, sur 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 »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 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 »^{(Archive.org • Wikiwix • Archive.is • Google • Que faire ?)}, 27 août 2010
• (en) Erik Romijn, « RIPE NCC and Duke University BGP Experiment », 31 août 2010