Resumen

  • RIPE NCC está adaptando su panel RPKI a OpenID Connect y ha empezado a sustituir las claves actuales de la API por credenciales basadas en OIDC e integradas en RIPE NCC Access.
  • La misma página cuenta que una baliza RPKI no se implantó porque la API disponible permitía editar ROA para todo el espacio de RIPE NCC. Ese límite operativo, no la etiqueta del protocolo, es el criterio que debe guiar la migración.

La seguridad de una credencial suele narrarse como una sucesión de mejoras: un inicio de sesión común, segundo factor, caducidad, revocación y mejor auditoría. Todo ello importa. Sin embargo, en una interfaz capaz de publicar autorizaciones de origen, falta una pregunta más incómoda: ¿cuánta infraestructura puede alterar esa credencial cuando funciona exactamente como fue diseñada?

RIPE NCC aún no ha contestado públicamente con detalle para su nueva solución. Su planificación de RPKI para el cuarto trimestre de 2026, actualizada el 17 de septiembre, dice que el panel pasará a OpenID Connect mediante RIPE NCC Access. También ha comenzado el trabajo para reemplazar las claves actuales de la API por claves basadas en OIDC, gestionables desde el contexto RPKI. La implementación y las fechas se explicarán con mayor precisión en una próxima reunión RIPE. El proyecto figura como «en curso».

La integración puede corregir problemas reales. RIPE NCC Access exige autenticación de dos factores. Las reglas publicadas para las claves de API fijan una vida máxima de un año, las vinculan a una cuenta concreta y prevén desactivarlas cuando la cuenta se deshabilita o el usuario pierde su función de mantenedor. Es más fácil gobernar un secreto cuando su propietario y su ciclo de vida son visibles.

OIDC, no obstante, es una capa de identidad sobre OAuth 2.0. Sirve para verificar la autenticación y entregar atributos del usuario. No define automáticamente qué conjunto de prefijos puede modificar un proceso ni separa una consulta, una simulación, un cambio pendiente y una publicación efectiva.

Incluso dentro de OAuth hay límites diferentes. El indicador de recurso señala ante qué servidor protegido debe ser válido un token. El ámbito expresa qué acceso se solicita. Las recomendaciones modernas piden restringir la audiencia. Después queda un tercer límite, propio del servicio: a qué LIR, certificado, ASN o prefijos se aplica la acción autorizada.

La propia planificación de RIPE NCC muestra por qué no conviene mezclar esos niveles. La comunidad solicitó una baliza de enrutamiento cuya validez RPKI pudiera cambiar para facilitar la investigación. RIPE NCC afirma que no pudo añadirla porque la API que habría usado permitía editar ROA para todo el espacio de RIPE NCC. Consideró esa capacidad inaceptable y estudiará una alternativa con el equipo RIS.

No es correcto convertir esa observación en una acusación contra el diseño OIDC aún incompleto. La API de la baliza es otro caso y la documentación no dice que las futuras credenciales de miembros vayan a compartir su alcance. Sí aporta una regla de decisión: una identidad bien autenticada no compensa una superficie de modificación excesiva.

El objeto que se modifica merece precisión. Una ROA es un objeto firmado que autoriza a un sistema autónomo a originar uno o varios prefijos, con una longitud máxima opcional. En el servicio alojado, RIPE NCC maneja configuraciones con un AS de origen, un prefijo y una longitud máxima; después firma, publica y renueva los objetos. La API actual permite añadir o borrar varias ROA en una única llamada.

También existen mecanismos que anticipan un diseño más seguro. El servicio rechaza con 403 la creación sobre un prefijo que el solicitante no posee. El panel permite preparar cambios, revisar los anuncios afectados y aplicar el conjunto de forma atómica. La API puede estimar el efecto de una ROA hipotética antes de crearla. La migración debería conservar esa capacidad y hacer explícito quién puede cruzar cada umbral.

La cadena completa no termina al publicar. Primero se autentica una identidad; después se valida la audiencia del token, la clase de acción y el límite de recursos. Luego el servicio acepta o rechaza la mutación. Más tarde aparece un objeto en el repositorio, lo recupera un validador, una red aplica —o no— validación de origen según su política y, finalmente, se observa un resultado BGP. Confundir esas pruebas convierte una herramienta de identidad en una promesa que no puede cumplir.

Este análisis usa como lente editorial las notas de Heng Lu sobre especificación inicial mínima, capas de realidad y problemas de agencia. La aplicación al RPKI favorece una autoridad inicial estrecha y decisiones futuras localizadas en el recurso afectado. No es una política atribuida a RIPE NCC.

Fuentes