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 la información de recursos numéricos de Internet (como números de 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, los recursos son distribuidos inicialmente por la IANA 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. RPKI puede ser utilizado por los titulares legítimos de los recursos 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 asegurar 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 de Vecinos Seguros (SEND).
La arquitectura RPKI está documentada en RFC 6480. La especificación RPKI está documentada en una serie 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. Estas RFC son un producto del grupo de trabajo SIDR ("Secure Inter-Domain Routing") del IETF , [1] y se basan 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 los registros regionales de Internet , conocidos como registros locales de Internet (LIR), obtener un certificado de recursos que enumera los recursos de números de Internet que poseen. Esto les ofrece una prueba validable de su titularidad, aunque el certificado no contiene información de identidad. Mediante el certificado de recursos, los LIR pueden crear certificaciones criptográficas sobre los anuncios de ruta que autorizan que se realicen 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 a generar determinados 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 se define, el AS solo 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 hacer cumplir 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 . Por lo tanto, 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_PATHs. [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]
Existen herramientas de código abierto [7] disponibles para ejecutar la autoridad de certificación y administrar el certificado de recurso y los objetos secundarios, como los ROA. Además, los RIR tienen 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 su lugar, el sistema de repositorio RPKI consta de múltiples puntos de publicación de repositorio distribuidos y delegados. Cada punto de publicación de repositorio está asociado con uno o más puntos de publicación de certificados RPKI. En la práctica, esto significa que cuando se ejecuta una autoridad de certificación, un LIR puede publicar todo el material criptográfico por sí mismo o puede confiar en un tercero para la 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 la parte que confía obtendrá, almacenará en caché y validará los datos del repositorio mediante rsync o el Protocolo Delta de Repositorio RPKI (RFC 8182). [8] Es importante que una parte que confía sincronice regularmente con todos los puntos de publicación para mantener una vista completa y oportuna de los datos del repositorio. Los datos incompletos o desactualizados 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 red 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 mediante el protocolo RPKI a enrutador (RFC 6810), [11] Cisco Systems ofrece soporte nativo en muchas plataformas [12] para obtener el conjunto de datos RPKI 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 más reciente. 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 la 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 ampliar su implementación hacia RPKI. Los operadores de red pueden utilizar RTRlib para desarrollar herramientas de monitoreo (por ejemplo, para verificar el funcionamiento correcto de los cachés o para evaluar su rendimiento).
La RFC 6494 actualiza el método de validación de certificados de los mecanismos de seguridad del protocolo Secure Neighbor Discovery (SEND) para el protocolo Neighbor Discovery (ND) con el fin de utilizar RPKI en IPv6. Define un perfil de certificado SEND que utiliza un perfil de certificado RPKI RFC 6487 modificado que debe incluir una única extensión de delegación de dirección IP RFC 3779.