Resumen

  • El rechazo prometido por rpki-client no llegó como un único evento el 18 de agosto: el cambio de ese día preparó la versión 9.9, pero la rama relevante siguió advirtiendo sin rechazar.
  • El último release portable continuaba siendo 9.8 el 21 de agosto; a la vez, una consola rpki-client independiente procesaba objetos AFRINIC y mostraba otros errores sin registrar la antigua advertencia sobre nombres X.509.
  • La evidencia describe una transición de compatibilidad controlada, no un corte instantáneo ni una caída. Antes de cambiar una política ROV, aviso, código, release y despliegue deben leerse como relojes separados.

Un plazo terminó convertido en cuatro relojes operacionales

El primer reloj era institucional. AFRINIC había fijado el 31 de julio de 2026 como objetivo para agotar los certificados afectados. El segundo era de software. El 19 de febrero, Job Snijders, mantenedor de rpki-client, avisó en la lista DBWG que el validador empezaría a rechazar esos certificados el martes 18 de agosto. Si el registro no llegaba a tiempo, escribió, algunos miembros podrían sufrir un impacto en su servicio RPKI. El mensaje dejó la advertencia y la fecha por escrito.

Cuando llegó el 18 de agosto, el repositorio de código registró un movimiento visible: Prepare for rpki-client 9.9 release. El commit cambió el identificador de versión de 9.8 a 9.9. Sin embargo, la lógica decisiva no cambió con él.

La función valid_printable_string() comprueba el tipo ASN.1 utilizado en el commonName. En el código exacto del commit de versión, un tipo distinto de PrintableString genera una advertencia solo cuando se ejecuta con verbosidad adicional. La instrucción return 0 que convertiría esa condición en rechazo está dentro de un bloque #if 0: el compilador no la activa.

Tampoco existía una versión portable 9.9 publicada al 21 de agosto. La lista oficial de releases seguía colocando 9.8, del 15 de abril, en primer lugar. Preparar un release no es publicarlo; publicarlo no es empaquetarlo; empaquetarlo no es desplegarlo. La fecha anunciada había pasado, pero el segundo reloj todavía no había consumado el corte.

La fecha era solo el reloj del aviso. El reloj del código había cambiado de número sin activar el rechazo; el del release no se había movido; y el del despliegue solo podía leerse en validadores independientes y paquetes downstream.

Un validador independiente mostró el cuarto reloj

La consola rpki-client independiente aportó la observación más útil del estado desplegado. Su ejecución del 21 de agosto mostraba rpki-client -c -j recuperando y validando el repositorio mundial, incluido material de AFRINIC. Desde las 08:33 UTC registró saltos de secuencia en dos manifiestos AFRINIC y, después, dos ROA AFRINIC expirados.

El registro no ocultaba los errores. Sin embargo, no mostraba la antigua advertencia sobre nombres de emisor o sujeto distintos de PrintableString. La observación es más independiente que un informe del emisor, pero sigue siendo la ausencia de un mensaje en el log de una implementación, no un censo criptográfico de cada certificado AFRINIC.

La conclusión prudente es operacional, no triunfal. El plazo pasó sin que la rama de rechazo apareciera en el código fijado, mientras un validador independiente siguió procesando material AFRINIC y expuso defectos distintos. El patrón es compatible con una reducción de la exposición heredada, pero no establece cuándo se reemitió el último objeto ni si todas las implementaciones coinciden.

El origen fue preciso; la reparación exigía renovar una cadena

RFC 6487, sección 4.5, establece cómo deben representarse los nombres de sujeto y emisor en los certificados de recursos. El atributo commonName debe usar PrintableString. Tras una actualización de su plataforma RPKI en 2022, el sistema alojado de AFRINIC emitió esos valores con UTF8String.

AFRINIC explicó en marzo de 2024 que una configuración actualizada de OpenSSL había introducido el comportamiento. La documentación de la biblioteca llevaba a una interpretación incorrecta del valor por defecto. La corrección de documentación de OpenSSL aclaró que utf8only era el valor efectivo y que nombstr restringía los tipos a los compatibles con PrintableString.

Modificar la configuración corrigió las nuevas emisiones. No reescribió lo que ya estaba firmado y publicado. Para eliminar la deuda había que regenerar claves de las autoridades de certificación alojadas afectadas y volver a emitir los objetos dependientes. AFRINIC planteó realizar el mantenimiento por lotes para reducir inconsistencias en los puntos de publicación y proteger a los miembros con muchos certificados de entidad final.

La diferencia importa porque la seguridad de enrutamiento no se ejecuta en un pizarrón. El perfil técnico puede ser inequívoco y, aun así, la migración necesita ordenar operaciones que afectan a claves, manifiestos, ROA y cachés de validadores. La conformidad solo es útil si el camino hacia ella no destruye innecesariamente la continuidad que pretende proteger.

El escenario de 6.000 anuncios no fue un parte de daños

En noviembre de 2025 quedaban 988 objetos con nombre de emisor no conforme y 657 con nombre de sujeto no conforme, según el recuento publicado por Snijders. Su cálculo era claro: eliminar entonces la excepción habría reducido temporalmente los VRP únicos bajo el trust anchor de AFRINIC de 21.027 a 19.480. Aproximadamente 6.000 anuncios BGP habrían pasado de ROV valid a not-found mientras se reemitían los ROA.

Era una estimación condicional. No describía rutas que ya hubieran cambiado de estado. Tampoco equiparaba not-found con invalid: una ruta sin VRP pierde esa evidencia de origen, pero no se convierte por definición en una ruta rechazada o inalcanzable.

Ese cuidado resulta aún más importante después del 18 de agosto. No se ha identificado un informe público que confirme una caída de 6.000 anuncios desde valid a not-found. La fuente que planteó el riesgo muestra una consecuencia potencial de retirar la tolerancia con objetos pendientes; la observación actual muestra que esos objetos dejaron de ser visibles antes de que el código estricto entrara en funcionamiento.

Presentar el escenario como un incidente no solo sería incorrecto. Impediría reconocer el valor de la presión ejercida por el escenario: hizo cuantificable el coste de mantener la deuda y, al mismo tiempo, el coste de eliminar la excepción demasiado pronto.

La convergencia correcta ocurre primero en los objetos

Un registro puede pedir a los mantenedores que toleren una desviación durante una migración. Esa tolerancia solo es defendible si tiene un final medible. Un mantenedor puede exigir la aplicación literal del perfil. Esa exigencia solo es operacionalmente responsable si la capa emisora ha tenido una oportunidad concreta de reparar objetos vivos.

La secuencia observable preserva ambas obligaciones. La consola independiente procesaba objetos AFRINIC sin mostrar la antigua advertencia, mientras rpki-client mantenía por ahora la excepción en el código fijado. El retiro posterior podrá hacerse tras confirmar el resultado con varias implementaciones, en lugar de utilizar anuncios de miembros como prueba de producción.

Esto no convierte la excepción en una buena característica permanente. Un validador que aplica reglas distintas según el emisor acumula complejidad, zonas difíciles de auditar y resultados menos previsibles. La meta sigue siendo una regla común. La diferencia está en retirar la tolerancia después de reparar el registro compartido, no antes.

Falta un acta final, no una historia alarmista

La evidencia pública no identifica el momento exacto en que se reemitió el último objeto ni proporciona una matriz independiente de validadores. En enero, AFRINIC había planteado publicar instrucciones, usar sus canales de comunicación y abrir un helpdesk; una respuesta observó que faltaba un plazo razonable. La conversación acredita el plan, no todos sus resultados.

También es necesario mantener fechada la afirmación sobre el software. El código del commit del 18 de agosto no rechaza el tipo incorrecto y el release portable más reciente al 21 de agosto es 9.8. Un commit posterior puede cambiar esa situación, y los paquetes instalados pueden divergir del árbol principal.

La conclusión prudente no necesita exageración: una fecha no cierra una migración. La Primacía del Código en Ejecución de Lu Heng aporta la jerarquía adecuada: el cambio se vuelve real mediante implementación, validación, despliegue y adopción. El 21 de agosto, esos cuatro relojes describían una brecha de compatibilidad administrada, no el interruptor único prometido en febrero.