1. Introduction
1. Introduction
Une route BGP associe un préfixe d'adresse à un ensemble de systèmes autonomes (AS) qui identifient le chemin interdomaine que le préfixe a parcouru sous forme d'annonces BGP. Cet ensemble est représenté comme l'attribut AS_PATH dans BGP [RFC4271] et commence par l'AS qui a été à l'origine du préfixe. Pour aider à réduire les menaces bien connues contre BGP, notamment les annonces erronées de préfixes et les attaques de type man-in-the-middle, l'une des exigences de sécurité est la capacité de valider l'AS d'origine des routes BGP. Plus précisément, il faut valider que le numéro AS prétendant être à l'origine d'un préfixe d'adresse (tel que dérivé de l'attribut AS_PATH de la route BGP) est effectivement autorisé par le détenteur du préfixe à le faire. Ce document décrit un mécanisme de validation simple pour satisfaire partiellement cette exigence.
La Resource Public Key Infrastructure (RPKI, Infrastructure à clé publique des ressources) décrit une approche pour construire une base de données formellement vérifiable d'adresses IP et de numéros AS en tant que ressources. L'architecture globale de RPKI telle que définie dans [RFC6480] se compose de trois composants principaux:
-
une infrastructure à clé publique (PKI) avec les objets de certificat nécessaires,
-
des objets de routage signés numériquement, et
-
un système de dépôt distribué pour conserver les objets qui supporterait également une récupération périodique.
Le système RPKI est basé sur des certificats de ressources qui définissent des extensions à X.509 pour représenter les adresses IP et les identifiants AS [RFC3779], d'où le nom RPKI. Les autorisations d'origine de route (ROA, Route Origin Authorizations) [RFC6482] sont des objets signés numériquement séparés qui définissent des associations entre les AS et les blocs d'adresses IP. Enfin, le système de dépôt est exploité de manière distribuée via l'IANA, la hiérarchie des registres Internet régionaux (RIR) et les ISP.
Afin de bénéficier du système RPKI, il est prévu que les parties de confiance au niveau AS ou organisation obtiennent une copie locale de la collection d'objets signés, vérifient les signatures et les traitent. Le cache doit également être actualisé périodiquement. Le mécanisme d'accès exact utilisé pour récupérer le cache local est hors du cadre de ce document.
Les routeurs BGP individuels peuvent utiliser les données traitées contenues dans le cache local pour valider les annonces BGP. Les détails du protocole pour récupérer les données traitées du cache local vers les routeurs BGP sont hors du cadre de ce document (référez-vous à [RFC6810] pour un tel mécanisme). Ce document propose un moyen par lequel un routeur BGP peut utiliser les données traitées afin d'attribuer un "état de validation" à chaque préfixe dans un message BGP UPDATE reçu.
Notez que l'attestation complète du chemin par rapport à l'attribut AS_PATH d'une route est hors du cadre de ce document.
Comme le DNS, le RPKI global ne présente qu'une vue vaguement cohérente, selon le timing, la mise à jour, la récupération, etc. Ainsi, un cache ou routeur peut avoir des données différentes sur un préfixe particulier qu'un autre cache ou routeur. Il n'y a pas de "correction" pour cela; c'est la nature des données distribuées avec des caches distribués.
Bien que RPKI fournisse le contexte pour ce document, il est également possible d'utiliser toute autre base de données capable de mapper les préfixes à leurs AS d'origine autorisés. Chaque base de données distincte aura ses propres caractéristiques opérationnelles et de sécurité particulières; de telles caractéristiques sont hors du cadre de ce document.