L'article « Quelques pistes sur le renforcement de la sécurité autour du protocole de routage BGP » a été publié aux pages 60-65 du numéro 70 (novembre/décembre 2013) de MISC. Ayant un peu étudié la sécurité de BGP, je souhaite donner mon avis qui tiendra compte du format (revue papier) qui oblige les auteurs à fortement résumer leurs propos.
Je réagis maintenant car j'achète, éventuellement (si une thématique abordée m'intéresse), la version PDF de ce magazine à l'unité et qu'il faut attendre la publication du numéro suivant pour que le numéro précédent devienne disponible au téléchargement. Je ne trollerai pas sur cette pratique ni sur celle qui consiste à faire payer le même prix pour la version numérique (pixellisée, mauvaise qualité) que pour la version papier alors que les coûts de production ne sont pas identiques (dupliquer un fichier, PDF ou pas, on frôle le zéro en coût de production). Oui, j'imagine bien qu'il faut rémunérer la production initiale (le contenu, la mise en page) et le fait que la version numérique n'est pas dominante sur la version papier, ce qui oblige à imprimer des exemplaires avec un risque d'invendus à provisionner mais quand même ...
Je mets une copie de cet article à votre disposition.
Mon premier regret sera que l'article ne met pas directement en évidence les deux catégories d'attaques existantes : celles qui visent la communication entre deux pairs BGP et celles qui visent à injecter de fausses informations qui se propageront de pair en pair. Une mention de la différence sera néanmoins faite dans la première conclusion (section 2.6).
De même, l'article ne met pas suffisamment en évidence la solution bien actuelle pour garantir l'origine d'une annonce BGP, RPKI+ROA, au profit des solutions historiques dont on sait qu'elles ne seront ni normalisées en l'état ni déployées. C'est dommage car on a l'impression que l'article est tourné vers le passé plutôt que vers le présent/futur et incite à l'immobilisme ("aucune vraie solution pour sécuriser BGP").
La section 2.2 (« Le contrôle par les secrets partagés ») traite uniquement de MD5, ce qui est assez dommage de nos jours ... Alors oui, IPsec et TCP AO ne sont pas encore suffisamment déployés pour justifier de faire la une des journaux TV mais je m'attendais à ce qu'ils soient cités dans cet article publié dans une revue spécialisée sur la sécurité informatique.
Les exemples de configuration sont mal formulés. Exemple : « neighbor «destination_adresse» password «mot» ». Ne serait-il pas plus exact de parler de « adresse_pair » au lieu de « destination_adresse » ?
Section 2.3 - « Le contrôle par les TTLs » :
En effet, partant du principe que les sessions de routage BGP entre deux routeurs sont généralement directes, les paquets IP contenant des informations de routage BGP émis par un routeur doivent arriver à l’autre routeur avec un TTL = TTL -1.
Le TTL est décrémenté uniquement en cas de forward. Un routeur reçoit un paquet, se rend compte qu'il ne lui est pas destiné, cherche une entrée dans sa FIB, décrémente le TTL. Si TTL = 0, il détruit le paquet et envoie un message ICMP « Time to Live exceeded in Transit » (type 11, code 0 😉 ) à celui qui prétend en être l'expéditeur. Si TTL > 0, le routeur forward le paquet.
Le RFC 5082 - The Generalized TTL Security Mechanism (GTSM) explique clairement que le paquet doit avoir un TTL fixé à 255 à l'émission et qu'il doit être inchangé à la réception. On lit souvent, y compris dans la CLI Cisco[1], que l'on doit avoir un TTL supérieur ou égal 254 à la réception : c'est une erreur ou plutôt, d'après mes recherches, un sacrifice de la sécurité sur l'autel de la compatibilité avec de vieilles architectures qui ne devaient pas gérer correctement la décrémentation du TTL (source : le plus loin que j'ai pu remonter, la présentation de cette proposition de TTL à 255 lors de la 27e rencontre NANOG : The BGP TTL Security Hack (BTSH)).
GTSM (Generalized TTL Security Mechanism) permet de généraliser cette approche à plusieurs sauts possibles et autres protocoles [RFC3682].
Le RFC 5082 a rendu obsolète le RFC 3682.
Sections 3.2 et 3.3 - « sBGP (secure BGP) » et « soBGP (secure origin BGP) » :
La première initiative a été le protocole sBGP (secure-BGP)
Ni S-BGP ni soBGP ne sont des protocoles.
Section 3.2 - « sBGP (secure BGP) » :
La validation de l’origine d’une route repose sur de la cryptographie à clé asymétrique nécessitant la mise en œuvre d’un système à clé publique où chaque système autonome possède alors un certificat électronique. La structure de gestion de clés proposée permet de traiter les extensions pour les blocs d’adresses certifiant l’appartenance d’une adresse à un AS.
Heu ... je ne comprends pas la dernière phrase ... En plus clair : les certificats x509 seront étendus avec de nouveaux types qui permettront de lier le titulaire de la clé privée du certificat à un préfixe IP/ASN. Ces extensions sont normalisées dans le RFC 3779 et doivent être présentes dans les certificats utilisés dans RPKI+ROA.
Un certificat est donc délivré à chaque organisme propriétaire d’un bloc d’adresse IP par l’entité responsable del’attribution des adresses IP. En partant du haut, on trouve l’IANA (Internet Assigned Numbers Autority) qui gère l’espace d’adressage d’Internet et l’assignation des blocs de numéros d’AS.
L'IANA gère, au plus haut niveau, toutes les ressources numériques uniques d'Internet, que ça soit les numéros d'AS, l'adressage IP ou bien encore les nombres dans les protocoles (exemple : les valeurs possibles pour les champs « Protocol »/« Next header » de la couche IP).
La validation du chemin pris par une annonce de route repose aussi sur de la cryptographie à clé asymétrique permettant de signer à chaque saut d’AS le chemin émis (avec sa clé privée) vers un autre système autonome comme l’illustre la figure 2 (les signatures s’empilent alors comme les couches d’un oignon).
Ce n'est pas ce que j'ai retenu de S-BGP. Pour moi, il y a autant de Route Attestation que d'AS traversés et elles ne sont pas empaquetées en oignon, chacune est indépendante. La présentation d'un des auteurs nous dit :
To validate a route received from ASn, ASn+1 requires:
[...]
- An RA corresponding to each AS along the path (ASn to AS1), where the RA generated and signed by the router in ASn encompasses the Network Layer Reachability Information (NLRI) and the path from ASn+1 through AS1- A certified public key for each S-BGP router that signed an RA along the path (ASn to AS1), to check the signatures on the corresponding RAs
[...] The router verifies the signature on each RA and verifies the correspondence between the signer of the RA and the authorization to represent the AS in question. There also must be a correspondence between each AS in the path and an appropriate RA. If all of these checks pass, the UPDATE is valid.
On arrive à la section consacrée à RPKI+ROA, la plus floue de toute, ce qui est dommage compte tenu que RPKI+ROA est la solution normalisée à l'IETF pour initier la définition d'un routage inter-AS sécurisé.
Cette nouvelle initiative de l’IANA (groupe de travail sur la sécurité du routage inter-domaine (SIDR)) [...]
SIDR est le nom d'un groupe de travail de l'IETF. RPKI+ROA n'a rien à voir avec l'IANA. C'est assez comique de lire ça quand on sait que personne n'a voulu de l'IANA comme racine unique de la RPKI.
La solution repose sur :
- Une infrastructure de distribution de certificats numériques dont l’objectif est de prouver qu’un AS a le droit d’annoncer un préfixe. Elle s’appelle la RPKI (Resource Public Key Infrastructure)
Non, les certificats certifient que le détenteur de la clé privée associée à la clé publique contenue dans ce certificat est le titulaire des ressources (préfixes IP) mentionnées dans le certificat et qu'il peut en distribuer tout ou partie.
- Le ROA (Route Origin Authorization) est un objet signé par une autorité indiquant que « le préfixe y peut être originé par un AS donné x ». Plus spécifiquement, il s’agit d’un fichier signé avec la clé du certificat de l’autorité donnant les AS qui peuvent être à l’origine d’un ou plusieurs préfixes.
Non, un ROA ne peut contenir qu'un seul ASN. Il peut en revanche contenir plusieurs préfixes. L'"autorité" qui signe un ROA est un opérateur réseau qui détient un certificat lui procurant droit sur un préfixe IP.
L’autorité peut donc publier son certificat et ses ROAs dans des bases de données publiques (RIPE, etc.).
Ce n'est pas faux dans la pratique mais attention : la base de données publique, la RPKI, est un ensemble de dépôts dont tout un chacun peut obtenir une copie en utilisant le protocole rsync (ce que font les logiciels cités plus bas dans l'article RPKI Validator, rcynic ou bien encore RPSTIR). Ce système de dépôts est distribué et hiérarchique. Seul l'usage fait que, pour l'instant, il ne semble pas exister d'autres instances de publication que celles des 5 RIR.
Ce sont les ROAs qui seront traduits en une liste de filtrage au niveau de l’équipement réseau.
Sémantiquement incorrect. Les ROA contiennent des assertions. Exemple : « l'AS 64501 est autorisé à être à l'origine d'une annonce pour les préfixes 192.0.2.0/24 et 2001:0DB8::/32 ». Cette assertion sera transmise au routeur, qui la stockera en vue de la comparer aux annonces BGP qu'il reçoit. Il réalisera ensuite l'action choisie par l'administrateur en fonction de l'état de sortie de cette comparaison. Si l'état de sortie est « invalid » et que l'administrateur a configuré une politique pour affecter une local pref moindre aux annonces dont l'origine sera marquée invalide, alors la route contenue dans l'annonce recevra une local pref moindre. Il n'y a pas de traduction en ACL ou que sais-je comme la tournure de phrase le laisse supposer.
Cependant et comme l’injection de la liste de filtrage ROAs en mémoire sur un équipement semble dans bien des cas tout simplement impossible (tous les routeurs ne sont pas forcément puissants), une architecture via un cache-validateur semble donc être requise via le protocole RTR (RPKI/Router Protocol).
Aucun rapport. L'injection des assertions contenues dans les ROA consomme de la RAM quelle que soit la manière dont on les transmet au routeur (RTR, manuellement, ...). Les caches-validateurs sont là pour déporter le travail de récupération et de validation cryptographique des objets de la RPKI.
Le cache/validateur ne revoit que les ROAs pour des AS donnés, la décision de routage restant à la décision du routeur via sa configuration
Non. Le cache-validateur envoie au routeur toutes les assertions contenues dans les ROA qu'il a réussi à valider cryptographiquement.
Nous sommes arrivés à la fin de l'article.
[1] La commande « show tcp tcb <tcb> » affiche : « Mininum incoming TTL 254, Outgoing TTL 255 » lors de l'utilisation de la fonctionnalité « ttl-security hops 1 ».