La infraestructura de clave pública de recursos ( RPKI ), también conocida como certificación de recursos , es un marco de infraestructura de clave pública (PKI) especializado para respaldar una seguridad mejorada para la infraestructura de enrutamiento BGP de Internet .
RPKI proporciona una forma de conectar información de recursos numéricos de Internet (como números del sistema autónomo y direcciones IP ) a un ancla de confianza . La estructura del certificado refleja la forma en que se distribuyen los recursos numéricos de Internet . Es decir, la IANA distribuye inicialmente los recursos a los registros regionales de Internet (RIR), quienes a su vez los distribuyen a los registros locales de Internet (LIR), quienes luego distribuyen los recursos a sus clientes. Los propietarios legítimos de los recursos pueden utilizar RPKI para controlar el funcionamiento de los protocolos de enrutamiento de Internet para evitar el secuestro de rutas y otros ataques. En particular, RPKI se utiliza para proteger el protocolo de puerta de enlace fronteriza (BGP) a través de la validación de origen de ruta (ROV) de BGP, así como el protocolo de descubrimiento de vecinos (ND) para IPv6 a través del protocolo de descubrimiento seguro de vecinos (SEND).
La arquitectura RPKI está documentada en RFC 6480. La especificación RPKI está documentada en una serie extendida de RFC: RFC 6481, RFC 6482, RFC 6483, RFC 6484, RFC 6485, RFC 6486, RFC 6487, RFC 6488, RFC 6489, RFC 6490, RFC 6491, RFC 6492 y RFC 6493. SEND está documentado en RFC 6494 y RFC 6495. Estos RFC son un producto del grupo de trabajo SIDR ("Secure Inter-Domain Routing") del IETF , [1] y son basado en un análisis de amenazas que se documentó en RFC 4593. Estos estándares cubren la validación del origen BGP, mientras que la validación de la ruta la proporciona BGPsec , que se ha estandarizado por separado en RFC 8205. Ya existen varias implementaciones para la validación del origen del prefijo. [2]
RPKI utiliza certificados PKI X.509 (RFC 5280) con extensiones para direcciones IP e identificadores AS (RFC 3779). Permite a los miembros de registros regionales de Internet , conocidos como registros locales de Internet (LIR), obtener un certificado de recursos que enumera los recursos numéricos de Internet que poseen. Esto les ofrece una prueba validable de titularidad, aunque el certificado no contiene información de identidad. Utilizando el certificado de recurso, los LIR pueden crear certificaciones criptográficas sobre los anuncios de ruta que autorizan con los prefijos y ASN que poseen. Estas certificaciones se describen a continuación.
Una Autorización de origen de ruta (ROA) [3] establece qué sistema autónomo (AS) está autorizado para originar ciertos prefijos IP . Además, puede determinar la longitud máxima del prefijo que el AS está autorizado a anunciar.
La longitud máxima del prefijo es un campo opcional. Cuando no está definido, el AS sólo está autorizado a anunciar exactamente el prefijo especificado. Cualquier anuncio más específico del prefijo se considerará inválido. Esta es una forma de imponer la agregación y evitar el secuestro mediante el anuncio de un prefijo más específico.
Cuando está presente, especifica la longitud del prefijo IP más específico que el AS está autorizado a anunciar. Por ejemplo, si el prefijo de la dirección IP es 10.0.0.0/16 y la longitud máxima es 22, el AS está autorizado a anunciar cualquier prefijo inferior a 10.0.0.0/16 , siempre que no sea más específico que / 22 . Entonces , en este ejemplo , el AS estaría autorizado a anunciar 10.0.0.0/16 , 10.0.128.0/20 o 10.0.252.0/22 , pero no 10.0.255.0/24 .
Una Autorización de proveedor de sistema autónomo (ASPA) establece qué redes pueden aparecer como adyacencias ascendentes directas de un sistema autónomo en BGP AS_PATH. [4]
Cuando se crea un ROA para una determinada combinación de AS de origen y prefijo, esto tendrá un efecto en la validez RPKI [5] de uno o más anuncios de ruta. Pueden ser:
Tenga en cuenta que las actualizaciones de BGP no válidas también pueden deberse a ROA configurados incorrectamente. [6]
Hay herramientas de código abierto [7] disponibles para ejecutar la autoridad de certificación y administrar el certificado de recursos y los objetos secundarios, como los ROA. Además, los RIR cuentan con una plataforma RPKI alojada disponible en sus portales de miembros. Esto permite a los LIR optar por confiar en un sistema alojado o ejecutar su propio software.
El sistema no utiliza un único punto de publicación de repositorio para publicar objetos RPKI. En cambio, el sistema de repositorio RPKI consta de múltiples puntos de publicación de repositorios distribuidos y delegados. Cada punto de publicación del repositorio está asociado con uno o más puntos de publicación de certificados RPKI. En la práctica, esto significa que cuando administra una autoridad de certificación, un LIR puede publicar todo el material criptográfico por sí mismo o puede confiar en un tercero para su publicación. Cuando un LIR elige utilizar el sistema alojado proporcionado por el RIR, en principio la publicación se realiza en el repositorio del RIR.
El software de confianza recuperará, almacenará en caché y validará los datos del repositorio mediante rsync o el protocolo delta del repositorio RPKI (RFC 8182). [8] Es importante que una parte dependiente se sincronice periódicamente con todos los puntos de publicación para mantener una vista completa y oportuna de los datos del repositorio. Los datos incompletos o obsoletos pueden dar lugar a decisiones de enrutamiento erróneas. [9] [10]
Después de la validación de los ROA, las certificaciones se pueden comparar con el enrutamiento BGP y ayudar a los operadores de redes en su proceso de toma de decisiones. Esto se puede hacer manualmente, pero los datos de origen del prefijo validados también se pueden enviar a un enrutador compatible utilizando el protocolo RPKI a enrutador (RFC 6810). [11] Cisco Systems ofrece soporte nativo en muchas plataformas [12] para recuperar los datos RPKI. configurarlo y usarlo en la configuración del enrutador. [13] Juniper ofrece soporte en todas las plataformas [14] que ejecutan la versión 12.2 o posterior. Quagga obtiene esta funcionalidad a través de BGP Secure Routing Extensions (BGP-SRx) [15] o una implementación RPKI [16] totalmente compatible con RFC basada en RTRlib. RTRlib [17] proporciona una implementación C de código abierto del protocolo RTR y verificación del origen del prefijo. La biblioteca es útil para los desarrolladores de software de enrutamiento pero también para los operadores de red. [18] Los desarrolladores pueden integrar RTRlib en el demonio BGP para extender su implementación hacia RPKI. Los operadores de red pueden utilizar RTRlib para desarrollar herramientas de monitoreo (por ejemplo, para verificar el funcionamiento adecuado de las cachés o evaluar su desempeño).
RFC 6494 actualiza el método de validación de certificados de los mecanismos de seguridad del protocolo Secure Neighbor Discovery Protocol (SEND) para el Neighbor Discovery Protocol (ND) para utilizar RPKI para su uso en IPv6. Define un perfil de certificado SEND utilizando un perfil de certificado RPKI RFC 6487 modificado que debe incluir una única extensión de delegación de dirección IP RFC 3779.