You are on page 1of 6

Bonnes pratiques de scurisation de BGP

Jrme Durand
Cisco Systems
11 rue Camille Desmoulins
92130 Issy-les-Moulineaux

Rsum
Cet article rappelle les bonnes pratiques de scurisation du protocole de routage de lInternet : BGP
(Border Gateway Protocol). Il rappelle notamment les conseils donns dans le RFC 7454 : BGP
Operations and Security en les adaptant pour la communaut RENATER. Larticle commence par
rappeler les lments essentiels pour la scurisation de la session utilise par TCP mais aussi la
scurisation du routeur. La plus grande partie de larticle reste ddie au filtrage des routes, pour les
rseaux de collecte mais aussi pour les tablissements. Une solution innovante appele SIDR (Secure
Inter-Domain Routing) est prsente pour amliorer encore le niveau de contrle. Pour finir dautres
rgles sont rapidement passes en revue : BGP route flap dampening, mise en place de seuils sur le
nombre de prfixes reus, analyse des AS-path ou communauts BGP.

Mots-clefs
BGP, RPKI, Securit, IPv4, IPv6, Internet, RFC 7454, TCP, Politique de routage

1 Introduction
BGP (Border Gateway Protocol) est le protocole de routage de linternet : il permet aux diffrents rseaux
de schanger leurs routes dynamiquement tout en conservant un haut niveau de contrle dans les
politiques dannonce. Depuis toujours, des bonnes pratiques existent pour conserver un environnement
fiable et scuris : scurisation du routeur, scurisation des sessions TCP, contrle des routes changes,
analyse des chemins dAS ainsi que des communauts. De nombreux documents prcisaient des
ensembles de rgles mais il manquait une relle vue densemble valide par une communaut dexperts.
Cette situation a chang depuis ce dbut danne 2015 car toutes ces bonnes pratiques sont maintenant
publies dans le RFC 7454 : BGP Operations and Security . Etant auteur principal du RFC 7454, je
prsente ici les principaux lments de ce document et en adapte le contenu afin quil profite au
maximum la communaut ducation-recherche franaise.

2 De la ncessit de bonnes pratiques


BGP est un protocole bien connu et largement dploy. Il peut paratre aujourdhui un peu tardif pour
publier des bonnes pratiques puisque la plupart des acteurs nont pas attendu pour les mettre en place.
Cependant plusieurs lments mont incit raliser ce document :
Le Cloud : BGP est jusque l une technologie surtout utilise par les oprateurs, rseaux de
recherche ou grosses entreprises. Lavnement du Cloud ncessite de plus en plus de liens
directs entre utilisateurs et fournisseurs de contenus. Les capacits requises, les niveaux de
service attendus, et les contraintes de cots vont trs probablement motiver de nombreux
acteurs sinterconnecter directement et ils devront pour cela utiliser BGP. Les entreprises
sont dailleurs une cible affiche du France-IX, premier point dchange en France en terme
de volume et de membres connects. Permettre ces nouveaux utilisateurs de BGP de le
dployer en toute scurit a t une motivation pour rdiger ce document.

JRES 2013 - Montpellier 1/6


IPv6 : si la communaut Recherche & Education a t prcurseur depuis des annes sur
ladoption dIPv6, nous observons seulement en ce moment une vritable acclration des
dploiements. Documenter les bonnes pratiques de scurisation de BGP pour IPv6 ma sembl
essentiel pour aider les personnes dployer la dernire version du protocole de linternet.
SIDR (Secure Inter-Domain Routing) : de nouveaux mcanismes de scurisation font leur
apparition, permettant de valider notamment lorigine des routes mais aussi les chemins
complets via une PKI de routage (RPKI). Intgrer ces nouveaux mcanismes avec les rgles
prcdemment utilises ma sembl tre un exercice intressant.
Avoir un change entre experts : il me semblait important que les experts BGP changent
leurs bonnes pratiques afin darriver des bases communes. Jai dailleurs dcouvert lors de
ces changes que la plupart des experts (dont moi) ne connaissaient pas forcment toutes les
bonnes pratiques. Certains lments peuvent facilement tre oublis lors de la dfinition de
politiques de routage.

3 Rsum des bonnes pratiques


Cet article na pas pour vocation traduire le RFC7454. Le lecteur est invit le lire puisquil a t rdig
dans un objectif didactique. Les lecteurs sont galement encourags lire les ventuelles rfrences du
RFC 7454 qui lui semblent intressantes. Cependant je propose de rsumer ici les lments essentiels
prendre en compte pour la communaut ducation & recherche.

3.1 Protection du routeur


BGP communique sur le port TCP 179. Il a t montr quen labsence de mcanisme de protection, un
trafic important destination dun routeur sur le port TCP 179 avait des consquences dsastreuses. Il
convient donc de bien protger le routeur de ce type dattaques.
Les routeurs volus peuvent fournir un mcanisme de protection du plan de contrle. Le trafic
destination du routeur lui-mme est analys par des rgles spcifiques avant dtre accept. Ainsi il sera
possible de limiter la quantit de trafic BGP reu ou mme de naccepter ce dernier automatiquement que
depuis les peers BGP configurs.
En labsence de tels mcanismes de protection du plan de contrle, il sera ncessaire dappliquer des
filtres quivalents au niveau du plan de donnes (ACL ou policing sur les interfaces pour sassurer que le
trafic BGP nest reu que depuis les peers configurs et ce dans des proportions acceptables).

3.2 Protection de la session TCP


BGP repose sur TCP et la protection de la session est un pralable au bon fonctionnement de BGP. On va
distinguer 2 lments possibles configurer :
Application du GTSM (Generalized TTL Security Mechanism). Cette mthode consiste
envoyer les paquets BGP avec un TLL de 255 afin de sassurer quils ne sont pas transmis au
del du lien local. De la mme manire chaque peer naccepte que les paquets qui arrivent
avec un TTL de 255. Cela permet de se protger contre le spoofing (usurpation de lidentit
dun des peers)
Authentification des peers BGP. Si traditionnellement MD5 est la solution la plus
communment adopte du fait de son support large sur toutes les plateformes, des mcanismes
plus rcents comme TCP-AO peuvent tre prfrs quand ils sont disponibles. Certains
peuvent mme considrer IPsec dans des cas trs critiques. Nous noterons toutefois que
lutilisation de telles mesures est surtout ncessaire sur les liens partags ou le risque de
spoofing est possible (points dchange Internet) Le GTSM et mme le routage en place
rendent compliques les attaques dans le cas de liens privs.

JRES 2013 - Montpellier 2/6


3.3 Filtrage des prfixes cas gnral
Le RFC7454 dtaille longuement les types de prfixes filtrer et les mthodes le plus communment
utilises pour cela. Les rgles suivantes sappliquent pour les organisations qui veulent la table de routage
complte. Des rgles plus simplifies peuvent tre appliques pour ceux qui ne veulent que la route par
dfaut de RENATER.

3.3.1 Des nouveaux registres de prfixes


La rdaction du RFC7454 a point du doigt le manque de document des prfixes spcifiques fournis par
lIETF (le fameux RFC 1918 qui a depuis largement volu). Les fameux special purpose prefixes
taient traditionnellement documents dans des RFC, par dfinition des documents figs une fois rdigs,
et il fallait bien veiller toujours faire rfrence au dernier RFC sur le sujet. Aussi ces documents
mentionnaient les prfixes en question mais ne disaient pas comment les router.
Aujourdhui 2 registres ont t crs listant les prfixes spciaux IPv4 et IPv6 et le routage adopter (voir
bibliographie). Le lecteur est invit sy rfrer pour vrifier ses rgles de routage. Je rappelle ici que les
prfixes filtrer ne sont pas seulement les fameux 10.0.0.0/8, 172.16.0.0/12 et 192.168.0.0/16 !

3.3.2 Filtrage des prfixes non allous par lIANA


LIANA alloue des prfixes aux RIRs (Regional Internet Registries) qui son tour alloue des prfixes aux
LIR (oprateurs ou organisations qui ncessitent des adresses IP publiques).
Une bonne pratique a t de ne router que les prfixes allous par lIANA aux RIRs. Dans lInternet IPv4,
tous les prfixes ont maintenant t allous aux RIRs et une telle pratique na plus lieu dtre. En
revanche dans lInternet IPv6 une telle pratique reste utile. Le lecteur trouvera dans la bibliographie la
liste des allocations de prfixes IPv6 par lIANA. Il conviendra bien videmment de mettre en place les
processus pour rgulirement mettre jour ces rgles. Certains constructeurs intgrent des mcanismes
permettant de simplifier la mise jour de ces prfixes.

3.3.3 Filtrage des prfixes non allous par les RIRs


Il est possible daller plus loin dans le contrle des routes en sassurant que celles-ci sont bien alloues
correctement par les RIRs. Une premire solution consiste analyser les registres de ces derniers et
construire des rgles prcises de filtrage. Cela reprsente un travail fastidieux puisque des scripts de
configuration sont ncessaires pour automatiser ces actions. Il ne semble a priori pas utile pour la
communaut RENATER.
Une mthode plus rcente consiste adopter une architecture nomme SIDR (Secure Inter-Domain
Routing), dcrite dans le dtail en section 3.4.

3.3.4 Filtrage des prfixes trop spcifiques


Gnralement les prfixes IPv4 et IPv6 de longueur respective suprieure /24 et /48 ne sont pas routs
sur lInternet. Les organisations peuvent gnralement filtrer les prfixes plus spcifiques sur leurs
peerings externes sauf si elles ont pralablement valid le routage de ces prfixes.

3.3.5 Filtrage des prfixes locaux


On va sassurer que les prfixes locaux soient filtrs depuis lextrieur.

3.3.6 Filtrage de la route par dfaut


Quand on va vouloir la table de routage globale, on va gnralement filtrer la route par dfaut en IPv4 et
en IPv6.

JRES 2013 - Montpellier 3/6


3.3.7 Filtrage des prfixes sur les points dchange Internet
Les points dchange concernent assez peu les tablissements et rseaux de collecte connects
RENATER, aussi le lecteur pourra regarder le RFC7454 sil dsire davantage dinformations sur les
bonnes pratiques adopter quand il est prsent sur un point dchange.

3.4 SIDR Secure Inter-Domain Routing


Larchitecture SIDR a pour objectif de scuriser le routage inter-domaine sur Internet. Il existe 2 briques :
la validation de lAS dorigine des routes, et la validation du chemin dAS.

3.4.1 Validation de lorigine des routes.


Cela se fait en validant que le numro dAS (ASN) origine dune route reue en BGP correspond bien
une dclaration pralable du propritaire du prfixe appele ROA (Route Origin Authorization). Une PKI
de routage (RPKI) a t cre pour cela. La hirarchie des signatures dun objet route par les diffrentes
entits concernes (IANA, RIR, LIR) garantie la validit de linformation. Cette brique est aujourdhui
en production et chacun peut (et mme doit) signer ses objets route en spcifiant lASN dorigine
thorique.
Pour valider les routes au niveau des routeurs, on va sappuyer sur un validator, lment extrieur au
routeur, qui va reconstruire la table de routage Internet thorique en parcourant larbre hirarchique de la
RPKI. Ce validator fait les oprations complexes ncessaires pour sassurer de la validit des routes
(analyse des certificats, ). Il communique ensuite au routeur les routes rcupres via un protocole
client/serveur dfini dans le RFC 6810. Il est ensuite possible sur le routeur de comparer les annonces
reues avec la table thorique et de prendre des dcisions.
Comme toutes les ROA nont pas encore t crs par leurs possesseurs, il convient dutiliser des rgles
encore un peu souples. Le RFC 7454 propose les rgles suivantes :
1. Accepter le prfixe sil correspond au ROA ;
2. Rejeter le prfixe sil ne correspond pas au ROA (ROA trouv mais lASN origine thorique ne
correspond pas avec celui reu) ;
3. Donner une plus faible priorit aux prfixes reus pour lesquels un ROA nexiste pas (en don-
nant la route BGP une local-preference plus faible par exemple).
On notera galement que ce mcanisme peut galement servir un organisme pour simplifier la mise en
place de filtrages sur son rseau. Ainsi on peut imaginer quau lieu dappliquer des prefix-lists sur les
peerings entre RENATER et ses utilisateurs, on se contente de vrifier les routes reues par rapport une
base de donnes locale (qui contiendrait les ASN privs ou publiques de ces membres). Cela pourrait
simplifier les oprations et mme ventuellement automatiser la prise en compte de demandes de
modifications de routage.

3.4.2 Validation du chemin complet


La vrification de lASN dorigine nempche pas une organisation dannoncer un prfixe qui ne lui
appartient pas puisquil lui suffit dusurper galement le numro dAS du dtenteur du prfixe.
Lopration est plus complexe et on se protge dans tous les cas derreurs de configurations qui ont t la
plus principale raison des grands problmes de routage rencontrs ces dernires annes sur Internet.
Larchitecture SIDR a donc galement dfini une solution permettant dviter ce scenario via la signature
des annonces BGP. On parle de BGPsec. Peu de dploiements de BGPsec existent.

3.5 Filtrage des prfixes sur la communaut RENATER

3.5.1 Cas dun tablissement RENATER


Route par dfaut uniquement

JRES 2013 - Montpellier 4/6


Dans ce cas, ltablissement nacceptera du rseau en amont (RENATER ou un rseau de
collecte) que la route par dfaut (0.0.0.0/0 pour IPv4 et ::/0 pour IPv6). Les autres prfixes
seront rejets. Il nenverra que ses prfixes en les agrgeant au maximum.
Table de routage complte
Dans ce cas ltablissement appliquera les rgles dcrites en section 3.3 sur les routes en
entre. Il nenverra que ses prfixes en les agrgeant au maximum.

3.5.2 Cas dun rseau de collecte


Route par dfaut uniquement
Vers RENATER
Dans ce cas le rseau de collecte nacceptera de RENATER que la route par dfaut
(0.0.0.0/0 pour IPv4 et ::/0 pour IPv6). Les autres prfixes seront rejets. Il enverra
RENATER ses prfixes ainsi que tous les prfixes des tablissements connects.
Vers les tablissements
Il enverra la route par dfaut et ventuellement les routes locales. Dans ce cas il appliquera
en sortie les filtres ncessaires pour respecter les rgles dcrites dans la section 3.3.
Table de routage complte
Vers RENATER
Dans ce cas ltablissement appliquera les rgles dcrites en section 3.3 sur les routes en
entre. Il enverra ses prfixes ainsi que tous les prfixes des tablissements connects.
Vers les tablissements
Selon le choix de ltablissement il enverra la route par dfaut, les routes locales ou toute la
table BGP. Dans les deux derniers cas il appliquera en sortie les filtres ncessaires pour
respecter les rgles dcrites dans la section 3.3.

3.6 BGP flap dampening


Le BGP flap dampening est une technique permettant de pnaliser les routes BGP qui bagottent afin de
protger le reste de lInternet de modifications de routage trop frquentes. Cette technique reste
aujourdhui recommande mais en utilisant de nouveaux seuils de pnalit documents dans le RFC 7196.

3.7 Maximum de prfixes sur un peering


Une manire simple de se protger dun routage anormal consiste reprer un nombre inhabituel de
routes reus sur un peering. On pourra ainsi rapidement reprer quand un peer sens nous annoncer
uniquement ses routes commence envoyer toute la table Internet quil apprend par ailleurs.
Il est donc recommand de configurer des seuils sur chaque peering pour recevoir dans un premier temps
une alarme et ensuite couper le peering quand la quantit de route est vraiment anormale.
Dans le cas de la communaut RENATER, le choix de couper un peering en cas de nombre de routes trop
important doit tre tudi attentivement car cela revient le plus souvent se priver de communication vers
lextrieur. Aussi cette limite aura surtout vocation protger les ressources internes en cas danomalies
sur le peering vers RENATER.

3.8 Filtrage de lAS-Path


De nombreuses rgles peuvent tre faites sur lAS-Path. Elles nont globalement peu dintrt sur la
communaut RENATER, mais il peut tre intressant de noter les recommandations gnrales suivantes :

JRES 2013 - Montpellier 5/6


Un rseau de collecte peut dcider daccepter des tablissements que les routes ayant
uniquement lASN de ce dernier dans lAS path. Des exceptions pourront tre mises en uvre
si plusieurs tablissements sont cascads et utilisent BGP ;
Une rgle globale consiste sassurer que le premier numro dAS de lAS-path correspond
bien au numro dAS du peer en question ;
Un tablissement nenverra pas de routes avec un AS-Path non nul sauf sil dsire offrir de la
connectivit une autre entit ;
Il ne faut pas modifier le comportement par dfaut de BGP qui sassure que le numro dAS
local nest pas reu de lextrieur afin de se prmunir des boucles. Si de telles modifications
devaient tre faites un soin tout particulier devrait tre port sur le design compte tenu des
impacts dsastreux possibles.

3.9 Filtrage du next-hop


Une bonne pratique globale consiste sassurer que le next-hop BGP correspond bien au neighbor BGP.
En injectant un faux next-hop, il est possible de forcer un peer rediriger son trafic o lon veut. Au sein
de la communaut RENATER, de telles pratiques sont peu probables et lapplication dune telle rgle
nest pas critique.

3.10 Analyse des communauts


Pour la communaut RENATER, la recommandation utile consiste ne pas supprimer les communauts
reues. Ces dernires peuvent tre utilises en amont/aval et ont t positionnes pour faciliter
llaboration de politique de routage.

4 Bibliographie
IANA. (s.d.). IPv4 Special Purpose Address Registry. Rcupr sur
http://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml
IANA. (s.d.). IPv6 address space registry. Rcupr sur http://www.iana.org/assignments/ipv6-unicast-
address-assignments/ipv6-unicast-address-assignments.xml
IANA. (s.d.). IPv6 Special Purpose Address Registry. Rcupr sur
http://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml
J. Durand, I. P. (s.d.). RFC 7454 - BGP operations and security.
R. Bush, R. A. (s.d.). RFC 6810 - The Resource Public Key Infrastructure (RPKI) to Router Protocol.

JRES 2013 - Montpellier 6/6