Resumen

  • RIPE NCC anuncia que su API RPKI ya permite crear y gestionar certificados de claves de router BGPsec.
  • El certificado autoriza una clave ligada a un ASN; no consigue que un router firme anuncios ni que su vecino valide el camino.

BGPsec tenía un problema muy de ventanilla: el estándar sabía describir el certificado que necesita una clave de router, pero al operador todavía le tocaba encajar esa pieza en su trabajo habitual de RPKI. RIPE NCC acaba de abrir una vía por API. La solicitud y la gestión del certificado pasan al software. Los routers, por desgracia, no aparecen al hacer clic.

La actualización para miembros del 23 de octubre dice que la API RPKI permite crear y gestionar certificados de claves de router BGPsec. Un día antes, Tim Bruijnzeels, ingeniero principal del RIPE NCC, explicó en la lista Routing WG que el titular de un ASN puede autorizar una clave para firmar anuncios BGP. La documentación técnica pública sitúa la API BGPsec en el entorno piloto RPKI, en localcert.ripe.net, y describe cómo crear objetos de clave y recuperar el certificado y su cadena. Eso acredita una función de aprovisionamiento; no ofrece un recuento de miembros que ya la usen en producción ni identifica un endpoint general para todas las cuentas.

El certificado tiene una tarea concreta. RFC 8209 define un certificado final RPKI que vincula una clave pública con uno o varios ASN. El router conserva la clave privada correspondiente y, si soporta BGPsec, la usa para firmar información del camino al enviar un UPDATE BGPsec a un vecino externo. El router receptor puede comprobar ese camino firmado con los certificados y las firmas disponibles.

No hace el trabajo de los demás objetos RPKI. Una ROA identifica qué AS puede originar un prefijo; una ASPA registra los proveedores que autoriza un titular de AS; BGPsec lleva firmas a lo largo del camino entre AS. Bruijnzeels dice que son herramientas complementarias. El certificado de clave de router es una pieza del mecanismo de firma, no otro nombre para validar el origen o detectar fugas de rutas.

La frase más reveladora del mensaje del RIPE NCC no es el anuncio. Es que el soporte en routers de hardware va rezagado y que el despliegue incremental y el rendimiento siguen siendo complicados. Una API quita trabajo de una etapa. No negocia una sesión BGPsec por el router, no protege su clave privada dentro del chasis, no enseña al vecino a leer el atributo firmado ni decide qué hacer cuando falta una ruta con firmas.

La escalera operativa se ve a simple vista: pedir el certificado; proteger e instalar la clave privada; habilitar BGPsec en routers y sesiones compatibles; enviar UPDATE firmados; y lograr que los equipos receptores los validen. Cada peldaño tiene un responsable distinto. Una respuesta correcta de la API prueba el primero. Las fuentes públicas aún no indican un endpoint de producción general ni qué implementaciones de router han completado el resto. El propio ingeniero del RIPE NCC dice que el soporte de hardware va tarde. Ese es el siguiente dato que debe llegar.

Para un operador, el avance sirve. Emitir certificados es trabajo de plano de control, y una API permite automatizarlo con otras tareas de RPKI. La prueba convincente enlazará un certificado con un router concreto, una clave protegida, un vecino en sesión BGPsec y un UPDATE que se valide de verdad. Por ahora, la API facilita una pieza del aprovisionamiento. El camino todavía no se firma solo.

Fuentes: actualización de RIPE NCC, 23 de octubre de 2026; Tim Bruijnzeels, lista RIPE Routing WG, 22 de octubre de 2026; documentación de la API BGPsec de RIPE NCC; RFC 8209; RFC 8205; Declaración de prácticas de certificación RIPE-851.