Resumen

  • OpenBSD 8.0, publicada el 20 de octubre, afirma que rpki-client ahora aplica correctamente las restricciones de anclas de confianza a los certificados de router BGPsec.
  • El filtro local puede limitar los recursos que acepta un validador. La publicación del ancla y la aceptación de otros validadores siguen siendo decisiones separadas.

Una valla que por fin llega al certificado de router

La página de OpenBSD 8.0 lo resume en una línea: «Properly apply constraints to rpki-client(8) BGPsec Router certs». El registro detallado de cambios repite la corrección. La versión salió el 20 de octubre.

La precisión importa. Un validador puede tener una función de restricciones y aun así tratar de forma distinta una familia de certificados. El certificado de router BGPsec vincula una clave con el uso de BGPsec y con recursos de Internet. La nota de OpenBSD confirma que rpki-client aplica ahora el control de restricciones a ese tipo de certificado. No relata un incidente ni identifica una red afectada. La evidencia pública es una corrección de código.

La modificación se conecta con el borrador de SIDROPS de la IETF, «Constraining RPKI Trust Anchors». La versión -02 propone que cada parte que valida RPKI (RP) defina localmente qué espacio de recursos espera que firme un ancla de confianza (TA). El RP compara las direcciones IP y los números AS de un certificado de entidad final con la lista permitida. Si alguno queda fuera, rechaza el objeto firmado para su propia validación.

«Todos los recursos» es una autorización enorme

El borrador dice que los cinco registros regionales de Internet (RIR) presentan todos los recursos como subordinados a sus certificados TA durante la operación normal. Esa amplitud reduce el riesgo de invalidación por inconsistencias transitorias, sobre todo cuando se transfieren recursos. También deja al validador ante una autoridad firmante más amplia que las tenencias actuales del registro.

El archivo local añade otra decisión en el lado del RP. Cada .constraints corresponde al .tal con el mismo nombre. El operador puede permitir prefijos, rangos de direcciones y números AS, y recortar excepciones con entradas deny. La denegación prevalece; cualquier recurso sin una entrada allow queda denegado por defecto. Así, el operador no tiene que enumerar todo Internet para excluir un bloque.

El formato es sencillo y su error es tajante. Si el archivo contiene una equivocación, el borrador exige que el RP rechace el archivo entero y no compruebe con él los certificados de entidad final. Hasta corregirlo, esa capa local deja de aportar su filtro. Sintaxis, distribución y mantenimiento pasan a formar parte del control de seguridad.

El método cubre objetos cuyos perfiles exigen extensiones explícitas de recursos IP o AS: ROA, ASPA, RSC y certificados de router BGPsec. Los manifiestos y los TAL firmados aparecen entre los ejemplos que quedan fuera porque usan recursos heredados. La regla limita la validación que hace un RP; la publicación del registro y la política de enrutamiento viven en otros puntos del sistema.

El código se adelantó al cierre de la norma

El -02 es un Internet-Draft activo, todavía no un RFC. Datatracker muestra el estado de SIDROPS como “Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC”. El propio documento indica que su apéndice de implementaciones se retirará antes de publicar un RFC.

La función ya está en software. El apéndice informa de que rpki-client la implementa en C y la activa por defecto desde 2023; también enumera implementaciones en Rust y Go. Sus autores dicen que las tres produjeron los mismos resultados con las pruebas de OpenBSD. La IETF aclara que no verificó los datos aportados por quienes escribieron el borrador: el registro acredita implementaciones reportadas y un conjunto de pruebas común, no una auditoría independiente de interoperabilidad. El manual de OpenBSD describe los archivos .constraints por ancla y las reglas locales allow y deny.

La corrección de 8.0 enseña cómo una función existente puede dejar una ruta de certificado con otro tratamiento. El registro público no identifica las versiones anteriores afectadas ni el camino de código exacto; esos datos cambiarían el tamaño de la exposición. Sí establece que OpenBSD corrigió en 8.0 la aplicación de restricciones a los certificados de router BGPsec. Por eso la prueba de una función debe recorrer cada clase de objeto; el nombre de la opción no demuestra su cobertura.

Seis meses para distribuir un archivo pequeño

El borrador pide a quienes distribuyen las restricciones con un sistema operativo o un paquete de terceros que calculen seis meses hasta que el usuario se actualice. Las políticas de transferencia y las tenencias de recursos evolucionan. La lista local debe seguir el alcance que dice aplicar. Una allow antigua puede rechazar un recurso que ya sea legítimo; una política ausente o incompleta puede aceptar más de lo que su operador quería.

La estrategia del NRO para 2026–2028 incluye la entrega de un documento sobre restricciones de anclas de confianza. El programa RPKI del NRO ya había fijado para 2025 una consulta comunitaria sobre la configuración de las anclas. Ese trabajo institucional avanza mientras el código cambia. OpenBSD 8.0 ofrece una evidencia distinta: una corrección reciente en un validador con restricciones locales.

La pregunta útil para una red es concreta: ¿el archivo expresa el espacio deseado?, ¿corresponde al TAL correcto?, ¿se conserva y actualiza con el paquete?, ¿se carga sin errores?, ¿se comprueba en todos los certificados que usa el operador? La línea de OpenBSD impide relegar la última pregunta a la letra pequeña.

Fuentes