Infraestructura de clave pública de recursos

Una autorización de origen de ruta (ROA) ^{[ 3 ]} indica qué sistema autónomo (AS) está autorizado a originar ciertos prefijos IP , utilizados para la validación del origen de ruta (ROV). Además, puede imponer la longitud máxima del prefijo que el AS está autorizado a anunciar. Una ROA verificada criptográficamente se denomina carga útil de ROA validada (VRP), que normalmente se transfiere a un enrutador para realizar el filtrado de rutas.

Una autorización de proveedor de sistema autónomo (ASPA) ^{[ 6 ]} indica qué redes pueden aparecer como adyacencias ascendentes directas de un sistema autónomo en las rutas AS_PATH de BGP. Esto proporciona una forma más sencilla de validar rutas BGP en comparación con BGPsec, que se describe a continuación.

Los operadores de AS publican certificaciones que especifican qué otros ASN pueden aparecer como un upstream en cualquier AS_PATH recibido a través de BGP. Hay dos variantes de validación ASPA, dependiendo de dónde se recibió el anuncio BGP: ^{[ 7 ]}

• Se recibió un anuncio de un cliente o un par lateral: Aquí, se asume que cada adyacencia AS es una relación cliente-proveedor. Si todos los AS del cliente publican un registro ASPA válido que incluya el ASN del proveedor correspondiente que se ve en la ruta dada, el anuncio se considera válido. Si algún AS que aparece en la ruta no tiene ningún registro ASPA (por ejemplo, porque aún no ha implementado ASPA), la validez del anuncio es desconocida , en cuyo caso aún debería aceptarse para admitir la implementación incremental de ASPA, de forma similar a la validación del origen de la ruta. De lo contrario, si no se aplica ninguna de las dos situaciones, el anuncio se considera inválido y debe rechazarse.
• Se recibió un anuncio de un proveedor ascendente: Este caso es más complejo que el anterior, ya que la ruta AS_PATH puede contener varios tipos de relaciones AS. Dado que BGP no codifica la relación de dos AS adyacentes y, de otro modo, determinar estas relaciones es imposible sin información previa, la validación ASPA se basa en la información certificada para determinar si una ruta AS_PATH recibida es plausible. El algoritmo de validación comienza desde ambos extremos de la ruta AS y cuenta el número de adyacencias que son relaciones cliente-proveedor válidas según los datos ASPA. La ruta válida más larga que comienza desde el AS de origen, la última en la ruta AS_PATH, se denomina rampa ascendente , mientras que la rampa descendente comienza desde el AS que verifica. Si la rampa ascendente y la descendente están separadas por como máximo una adyacencia, lo que indica una conexión de interconexión lateral en la parte superior de la jerarquía AS, el anuncio se considera válido (tenga en cuenta que las rutas ascendente y descendente también pueden superponerse, lo que indica un proveedor común para uno de los otros AS). Este proceso también garantiza que se cumpla la propiedad de ausencia de valles de las rutas BGP. De forma similar a lo anterior, si algún AS no tiene ningún registro ASPA, se desconoce la validez del anuncio , y si ninguno de los dos casos se da, el anuncio no es válido.

La adición de la ruta BGP AS al principio no tiene efecto en el proceso de validación, ya que los ASN duplicados consecutivos en AS_PATH se reducen a uno solo antes del proceso de validación.

Los ISP de nivel 1 publican un registro ASPA que contiene la única entrada AS0, lo que indica que estas redes no tienen enlaces ascendentes y cualquier anuncio que sugiera lo contrario es inválido. ^{[ 8 ]}

El protocolo de seguridad de puerta de enlace de frontera (BGPsec) es una extensión de seguridad del protocolo de puerta de enlace de frontera definida en el RFC 8205 , junto con los RFC adicionales 8206 a 8209, publicados en septiembre de 2017. BGPsec proporciona seguridad al permitir que los receptores de mensajes BGPsec UPDATE verifiquen criptográficamente la ruta AS recibida. ^{[ 9 ]} BGPsec reemplaza el atributo BGP con un nuevo atributo. ^{[ 10 ]} AS_PATHBGPsec_Path

BGPsec utiliza certificados de enrutador, definidos en la RFC 8209 y publicados a través de RPKI, que los validadores obtienen para verificar una firma BGPsec recibida en un mensaje UPDATE. Los enrutadores crean las firmas utilizando su clave privada, y estas se pueden verificar mediante la clave pública contenida en el certificado de enrutador correspondiente. 

El uso de firmas criptográficas aumenta significativamente la sobrecarga de recursos en los enrutadores al enviar y recibir anuncios BGP. Además, para brindar un beneficio de seguridad significativo, BGPsec debe implementarse en una gran parte de los enrutadores, a diferencia de ROV y ASPA, que brindan beneficios de seguridad inmediatos en las implementaciones tempranas. Estas son las principales razones por las que BGPsec prácticamente no se usa en Internet, y las implementaciones funcionales para él son escasas. ^{[ 11 ]} A junio de 2026, cero certificados de enrutador válidos publicados en el RPKI de Internet, en comparación con más de 375 mil ROA y varios miles de ASPA, a pesar de que ASPA ni siquiera se ha estandarizado completamente en este momento.

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 repositorio distribuidos y delegados. Cada punto de publicación de repositorio está asociado a uno o más puntos de publicación de certificados RPKI. En la práctica, esto significa que, al gestionar una autoridad de certificación, un LIR puede publicar todo el material criptográfico por sí mismo o bien depender de un tercero para la publicación. Cuando un LIR opta por utilizar el sistema alojado proporcionado por el RIR, en principio la publicación se realiza en el repositorio del RIR.

Después de la validación de las atestación como ROA, se pueden comparar con el estado de 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 usando el Protocolo RPKI a Enrutador (RFC 6810). ^{[ 16 ]} Cisco Systems ofrece soporte nativo en muchas plataformas ^{[ 17 ]} para obtener el conjunto de datos RPKI y usarlo en la configuración del enrutador. ^{[ 18 ]} Juniper ofrece soporte en todas las plataformas ^{[ 19 ]} que ejecutan la versión 12.2 o posterior. BIRD admite de forma nativa el Protocolo RPKI a Enrutador a través del protocolo "RPKI" en la configuración, y puede hacer ROV y ASPA basado en esto. Quagga obtiene esta funcionalidad a través de las Extensiones de Enrutamiento Seguro BGP (BGP-SRx) ^{[ 20 ]} o una implementación RPKI ^{[ 21 ]} totalmente compatible con RFC basada en RTRlib. La biblioteca RTRlib ^{[ 22 ]} proporciona una implementación en C de código abierto del protocolo RTR y la verificación del origen del prefijo. Esta biblioteca es útil tanto para desarrolladores de software de enrutamiento como para operadores de red. ^{[ 23 ]} Los desarrolladores pueden integrar RTRlib en el demonio BGP para extender su implementación hacia RPKI. Los operadores de red pueden usar RTRlib para desarrollar herramientas de monitorización (por ejemplo, para comprobar el correcto funcionamiento de las cachés o evaluar su rendimiento).

El RFC 6494 actualiza el método de validación de certificados de los mecanismos de seguridad del protocolo de descubrimiento seguro de vecinos (SEND) para que el protocolo de descubrimiento de vecinos (ND) utilice RPKI en IPv6. Define un perfil de certificado SEND que utiliza un perfil de certificado RPKI RFC 6487 modificado, el cual debe incluir una única extensión de delegación de dirección IP RFC 3779.