Summary

  • El grupo de trabajo temporal de JANOG, activo del 22 de enero al 31 de julio de 2013, organizó ejercicios con certificados, ROA, validadores, cachés, transferencia RTR y observación en routers. No desplegó una política nacional de filtrado ni actuó como registro o autoridad de certificación.
  • En JANOG32 se discutieron la pérdida de una caché, la recarga de un router, los datos corruptos y el riesgo de un resultado masivo Invalid. La idea de suspender actualizaciones al rebasar un porcentaje fue una propuesta de un participante: el archivo no conserva la cifra ni acredita que se adoptara una regla.
  • Los estándares ya incluían mecanismos de continuidad. La experiencia posterior sostiene dos verdades a la vez: la validación de origen aporta beneficios de seguridad medibles, y sus dependencias deben degradarse de manera limitada, observable y reversible.

El valor de una pregunta incómoda

La escena central de esta historia no muestra a un router rechazando rutas en toda la Internet japonesa. Tampoco muestra a una autoridad nacional dictando una política común. Es una escena más modesta y, por ello, más reveladora: una sala de operadores en la que se había avanzado lo suficiente con certificados, autorizaciones de origen, cachés y routers como para preguntar qué ocurriría si, de pronto, todo pareciera inválido.

La página de la sesión de JANOG32, celebrada el 4 de julio de 2013, conserva esa inquietud en un registro editado del debate. Allí se pregunta cuántas cachés conviene conectar, qué pasa durante una recarga, cómo responder a datos corruptos y cómo impedir que un conjunto anómalo de resultados arrastre la conectividad. Un participante propuso interrumpir las actualizaciones cuando la proporción de anomalías superase cierto porcentaje. El archivo no da un valor, no recoge una votación y no documenta que JANOG, un proveedor o un operador adoptaran tal umbral.

Conviene resistir la tentación de completar el relato con una cifra inventada. Tampoco cabe convertir una intervención del público en norma, función de producto o política japonesa. El interés de la observación radica precisamente en lo que dejó abierto: cuál sería el denominador, qué variación se mediría, durante cuánto tiempo se conservaría el estado anterior y quién tendría autoridad para reanudar la distribución. Es una pregunta de diseño, no el acta de una decisión.

La página del RPKI Routing WG de JANOG acota además al protagonista institucional. Fue un grupo temporal, activo del 22 de enero al 31 de julio de 2013. Organizó dos hackatones, sesiones prácticas, un tutorial y discusión pública. JANOG convocó a una comunidad operativa, mantuvo un archivo de reuniones y alojó aquel trabajo; no asignó direcciones IP ni números de sistema autónomo, no emitió certificados de recursos en producción, no gobernó los routers de sus participantes y no reguló el tráfico de Japón.

El expediente público tampoco demuestra que el grupo temporal tuviera personalidad jurídica propia, capacidad de contratar o control financiero separado. Esa ausencia no reduce su utilidad técnica, pero sí limita las palabras con las que puede describirse su autoridad. Fue un espacio de experimentación y de intercambio, no una autoridad permanente. JPNIC desempeñaba las funciones del registro de Internet japonés; APNIC y otros registros regionales tenían responsabilidades de certificación y repositorio en sus regiones; cada operador conservaba el control de su red.

La pregunta relevante, por tanto, no era quién mandaba sobre Internet. Era cómo podía una señal respaldada criptográficamente adquirir peso en redes autónomas sin volverse quebradiza. La respuesta dependía de una cadena de actores: quien publica objetos, quien valida repositorios, quien sirve datos a los routers, quien configura esos equipos y quien decide la política BGP. Ningún eslabón podía garantizar por sí solo el resultado de extremo a extremo.

Lo que el laboratorio hizo, y lo que no hizo

El trabajo de 2013 merece atención sin necesidad de elevarlo a despliegue nacional. El informe revisado del grupo describe dos hackatones en los que los participantes probaron herramientas de RPKI, trabajaron en la construcción de cachés y conectaron la validación con un recorrido experimental hasta routers BGP. Las primeras sesiones tropezaron con problemas de entorno y defectos de software. Tras las correcciones de los desarrolladores, la segunda ronda obtuvo mejores resultados en la construcción y el uso de la caché.

Las actividades posteriores recurrieron a entornos simplificados y máquinas virtuales preparadas. Así, los participantes podían concentrarse en emitir certificados y ROA, validar la información y observar en el router el estado resultante. El informe de actividad presentado por Taiji Kimura y el material combinado de JANOG32 corroboran esa secuencia. Son documentos de participantes dentro de una misma familia institucional, no comprobaciones independientes.

El boletín de JPNIC de noviembre de 2013 cuenta el mismo arco desde una entidad que apoyó las actividades: fallos iniciales, correcciones de los desarrolladores, una segunda prueba más fluida y adaptación del material para las sesiones prácticas. La convergencia de los relatos permite afirmar que hubo implementación y aprendizaje mediante fallos. No permite calcular una tasa de éxito ni certificar que el conjunto estuviera listo para producción.

Faltan los datos necesarios para una afirmación más ambiciosa: configuraciones completas, versiones de cada validador y router, capturas de paquetes, registros de caché, pasos de inyección de fallos, tiempos brutos y una relación que muestre quién completó cada ejercicio. Tampoco existe un denominador fiable de participantes. La expresión «mejor resultado» debe conservar su carácter cualitativo y atribuido; no puede convertirse en rendimiento medido.

La secuencia técnica también impone cautela. Emitir un certificado de recursos no equivale a crear una ROA. Construir o ejecutar una caché no demuestra que los datos llegaran correctamente por RTR. Ver un estado de validación en un router no prueba que se aplicara una política de rechazo. Cada paso revela algo distinto y deja abierta la conducta del siguiente.

No consta que el laboratorio provocara deliberadamente un episodio en el que todas las rutas apareciesen Invalid, y menos aún que lo hiciera en una red de producción. El escenario se planteó en la conversación y en el análisis de riesgos. Tampoco consta una pérdida nacional de conectividad. Confundir un fallo imaginado con un fallo ejecutado daría al relato más dramatismo y menos valor: borraría la diferencia entre anticipar una amenaza y medir sus consecuencias.

La contribución más sólida del ensayo fue obligar a cruzar fronteras que una diapositiva suele ocultar. ¿Quién publica el objeto? ¿Quién decide si la cadena es utilizable? ¿Cuánto tiempo conserva el validador datos que antes eran válidos? ¿Qué hace el router al perder una sesión? ¿La política local observa, marca, degrada o rechaza? El laboratorio no resolvió cada pregunta, pero las convirtió en problemas operativos visibles.

Del repositorio al usuario: seis estados que no deben confundirse

En RPKI, la precisión terminológica no es un lujo. Un fallo puede empezar en un repositorio y no llegar al usuario; también puede propagarse si el software, la topología y la política local lo amplifican. Agrupar todo bajo la etiqueta «falló RPKI» impide saber qué ocurrió y qué control actuó.

En el primer nivel están los objetos publicados bajo la jerarquía de certificación de recursos: certificados, listas de revocación, manifiestos y ROA. Pueden quedar desactualizados, resultar inconsistentes o ser rechazados durante la validación. Ese resultado describe objetos del repositorio. Todavía no describe el estado de una ruta BGP.

En el segundo nivel opera el software de validación de la parte usuaria —el relying party—, a menudo llamado validador o caché. Descarga y verifica los repositorios y produce VRP, registros validados que asocian un prefijo, un sistema autónomo de origen y una longitud máxima efectiva. Esa longitud siempre está presente en el VRP: si la ROA no declara un maxLength más amplio, el límite efectivo es la longitud del propio prefijo. Si una rama se rechaza o no puede actualizarse, el conjunto de VRP puede quedar incompleto o conservar datos anteriores, según el fallo y la implementación. Esto no prueba que un router haya recibido el resultado.

El tercer nivel es RPKI-to-Router, RTR: la transferencia de esos datos desde una o varias cachés hasta el router. La sesión puede interrumpirse, la caché puede reiniciarse y el router puede conservar temporalmente información o conectarse a otra fuente. RTR determina qué datos llegan, pero no decide por sí solo qué hacer con una ruta.

El cuarto nivel es el estado de validación de origen. Una ruta es Valid cuando al menos uno de los VRP disponibles que cubren el prefijo coincide a la vez con el AS de origen y la longitud anunciada. Es Invalid cuando uno o más VRP cubren el prefijo, pero ninguno coincide simultáneamente con el AS de origen y la longitud anunciada. Es NotFound cuando el conjunto validado no contiene un VRP que cubra la ruta. Ninguno de esos estados equivale automáticamente a una decisión de encaminamiento.

Valid no comprueba el camino completo de sistemas autónomos ni obliga a aceptar el anuncio. Invalid tampoco demuestra por sí solo un ataque: puede deberse a una longitud máxima mal configurada, una migración legítima no reflejada aún o un origen realmente no autorizado. NotFound significa que falta una autorización validada que cubra la ruta; no significa, por definición, que el operador vaya a descartarla.

El quinto nivel es la política local. Allí el operador decide si solo observa un estado, lo etiqueta, reduce su preferencia, introduce una excepción o rechaza la ruta, a veces de forma distinta según el tipo de vecino. El sexto nivel es la conectividad del usuario: si los paquetes llegan a su destino. Afirmar una interrupción exige medir rutas seleccionadas, tráfico, duración y población afectada. Una etiqueta de validación no sustituye esas observaciones.

El análisis contemporáneo de Tomoya Yoshida recorría buena parte de esta cadena. Consideraba la dependencia de una caché externa, la pérdida de RTR, la recarga del router, los datos corruptos y la necesidad de mantener filtros ordinarios. También advertía que una ruta Valid no es, por ese solo hecho, una ruta que deba aceptarse. ROV aporta una señal sobre el origen; no reemplaza la política de importación ni protege el camino AS completo.

Los mecanismos de continuidad ya estaban en el protocolo

Cuando un archivo comunitario conserva una pregunta lúcida, resulta tentador atribuirle también la invención de la respuesta. La cronología lo impide. RFC 6810 se publicó en enero de 2013, meses antes de JANOG32. Ya permitía conectar un router a una o más cachés y especificaba retención de datos, conexión a una caché alternativa y comportamiento de reinicio y actualización. El grupo temporal no inventó esos mecanismos.

El RFC, sin embargo, tampoco garantizaba una recuperación segura en cualquier red. Una norma describe el comportamiento esperado; no demuestra que todos los productos lo implementen de igual modo, que un operador lo configure correctamente o que dos cachés pertenezcan a dominios de fallo independientes. Dos instancias en el mismo centro de datos pueden duplicar equipos sin diversificar el riesgo. Dos implementaciones distintas pueden consumir el mismo material defectuoso. Conservar datos ayuda durante una interrupción breve, pero también puede prolongar información obsoleta.

La diferencia entre norma y práctica se hizo más explícita en RFC 7115, publicado en enero de 2014. La guía situó la acción sobre el estado de validación en la política local y recomendó predecir, medir y vigilar el efecto de cualquier cambio antes de endurecerlo. En lugar de ordenar el rechazo universal, proponía una evolución cautelosa: observar, comparar, introducir preferencias relativas y decidir con conocimiento de las relaciones BGP propias.

RFC 7115 apareció después de JANOG32, pero no hay base para presentarlo como fruto de aquella reunión. Procede del IETF y constituye una explicación alternativa de por qué operadores distintos terminaron adoptando prácticas parecidas. También recuerda que una recomendación de buenas prácticas no demuestra que una red concreta la siguiera.

La autoridad de la señal no era, pues, un interruptor central. La jerarquía RPKI permite comprobar que una autorización procede de la cadena correspondiente a los recursos. Su autoridad operativa depende además de que el repositorio publique de forma coherente, el validador produzca un conjunto fiable, RTR lo entregue, el router lo procese y la política local proteja sin amplificar un error. La criptografía resuelve una parte del problema; la operación decide cuánto daño puede causar el fallo de cualquiera de las demás.

JANOG merece crédito por exponer problemas de implementación, reunir a operadores y conservar el debate. Ese crédito no debe absorber el trabajo normativo del IETF ni las decisiones de registros, desarrolladores y redes. Su papel más defendible fue confrontar el estándar con software, equipos y dudas concretas, no erigirse en origen único de los controles.

El registro ofrece datos; el operador decide la ruta

Tras el cierre del grupo temporal, JPNIC mantuvo entornos de prueba y servicios vinculados a RPKI. La sesión de JANOG35.5 sobre el entorno de prueba documenta que, el 3 de marzo de 2015, JPNIC inició un servicio ligado a los recursos realmente asignados que figuraban en el registro. Permitía vincular la certificación a esos datos registrales. La propia descripción advertía, sin embargo, que la configuración del router BGP debía hacerse por separado.

La explicación técnica de JPNIC detalla la validación en caché, la transferencia al router y la operación distribuida de repositorios. Es una publicación del organismo que ofrecía el servicio, no una auditoría externa de adopción. No aporta un denominador de redes japonesas que activaron ROV, las políticas que eligieron ni los incidentes que pudieron evitar.

El reparto de funciones es inequívoco. JPNIC podía vincular la certificación con la información registral, operar sus superficies de repositorio y publicar orientación. No podía decidir por cada red si una ruta Invalid se observaba, perdía preferencia o se descartaba. JANOG podía albergar el intercambio entre técnicos, pero el servicio no se convertía por ello en un servicio de JANOG. El operador conservaba el control de sus cachés, sesiones RTR, filtros, excepciones y acciones de encaminamiento.

Por eso, el paso de 2013 a 2015 debe describirse como continuidad de una superficie experimental y registral, no como despliegue nacional. La disponibilidad de un servicio no demuestra su adopción; la adopción de un validador no demuestra filtrado; y el filtrado en una red no establece una política común para Japón.

Externalizar la validación o usar una caché pública puede reducir carga operativa, pero añade una dependencia. Ejecutar cachés locales ofrece control sobre versiones, registros y reinicios, pero exige mantenimiento. Ninguna opción es segura por definición. La elección depende de la diversidad geográfica y de software, los procedimientos de actualización, la observabilidad, la capacidad de reversión y el tiempo durante el cual los routers conservarán datos.

Cuando la producción sustituyó la épica por cifras

Los despliegues japoneses posteriores permiten comprobar si las preguntas de 2013 seguían siendo pertinentes; no demuestran que aquella reunión los causara. Los operadores pudieron aprender de los RFC, de proveedores, de otros registros regionales, de incidentes internacionales o de pruebas propias. Incluso citar una reunión anterior acredita memoria institucional, no descendencia técnica. La comparación válida es entre mecanismos y resultados acotados.

En una presentación de IIJ sobre AS2497, el operador describió un despliegue gradual entre marzo y diciembre de 2020. Cada router se conectaba a dos cachés situadas en lugares distintos de Japón y basadas en implementaciones diferentes. IIJ empezó observando y probando en red activa antes de ampliar el rechazo por grupos de pares y proveedores de tránsito.

La instantánea inicial contenía unas 3.000 rutas Invalid, alrededor del 0,3 % de la tabla completa. El despliegue comunicado alcanzó diez nodos y menos de 2.000 pares BGP. Esos números convierten una afirmación general en una superficie que otros operadores pueden interrogar: topología de caché, etapas, orden de aplicación y escala aproximada.

También deben conservarse sus límites. Son cifras publicadas por el propio operador, no una auditoría de configuraciones, rutas o interrupciones. Dos cachés por router no revelan todos los dominios de fallo. Dos implementaciones no garantizan independencia de los datos. Menos de 2.000 pares no equivale a usuarios protegidos. La presentación demuestra cómo IIJ dijo haber desplegado ROV, no cómo respondieron todas las redes japonesas.

En julio de 2022, una prueba distinta examinó el temor a que una recarga se prolongase de forma excepcional. El informe de JPNIC sobre el experimento de JANOG50, publicado el 17 de agosto, describe un entorno simulado con una tabla cercana a 800.000 rutas. En esas condiciones, el reinicio del router no resultó materialmente distinto de un reinicio BGP ordinario. También se discutieron redundancia, vigilancia, tratamiento gradual de Invalid y ventajas de las cachés locales.

El resultado es una contraprueba importante: bajo aquel entorno, el temor a una demora extraordinaria no se materializó. No es una garantía universal. El número de rutas es aproximado y el informe no publica todos los tiempos brutos, versiones ni configuraciones. Otros routers, cachés, políticas y modos de fallo podrían comportarse de otra manera. El hallazgo rebaja una preocupación concreta; no clausura el problema.

La página del experimento de JANOG52 muestra que en julio de 2023 todavía se comparaban implementaciones de caché y formas de tratar rutas Invalid. Que la pregunta siguiera abierta no implica fracaso. Una configuración segura no es una respuesta eterna: debe volver a probarse cuando cambian los datos, el software, la topología o la política.

Dos incidentes reales y dos límites de impacto

Los incidentes muestran por qué la taxonomía importa. El caso de JPNIC de 2022 se presta a una frase rotunda, pero errónea: «todas las rutas se volvieron inválidas». Eso no es lo que documenta el aviso de JPNIC.

Entre el 26 de enero y el 2 de febrero de 2022, un disco lleno impidió publicar nuevas versiones de la lista de revocación y del manifiesto. A medida que esos objetos quedaron obsoletos, casi todas las ROA emitidas por JPNIC se volvieron inválidas en la capa de objetos del repositorio. Las rutas BGP afectadas aparecieron como NotFound: al faltar autorizaciones utilizables en el conjunto validado, no había un VRP disponible que las cubriera. El aviso no dice que todas las rutas BGP adquirieran el estado Invalid.

JPNIC informó de que un usuario detectó el problema y de que la recuperación fue manual. No publicó un recuento de rutas afectadas, instancias de validación, operadores, volumen de tráfico o usuarios sin servicio. El mecanismo y las fechas están documentados; el impacto de extremo a extremo no. Tampoco existe fundamento para atribuir el incidente a JANOG: el origen fue un problema de capacidad y publicación en la infraestructura de JPNIC.

El post mortem de RIPE NCC ofrece una comparación externa. El 7 de enero de 2021, una inconsistencia entre certificados padre e hijo hizo que algunas implementaciones estrictas rechazaran todos los certificados de recursos de RIPE. RIPE NCC informó de 327 instancias de parte usuaria afectadas y anunció cambios para publicar de forma atómica.

El denominador vuelve a ser decisivo. Las 327 eran instancias, no operadores, rutas, usuarios ni interrupciones. El texto señalaba que el incidente pudo causar cortes, pero no midió cuántos ocurrieron. Tampoco se trató de un caso japonés. Su valor para esta historia es demostrar una clase de fallo: una inconsistencia de publicación puede eliminar una parte muy amplia del conjunto validado, y el resultado depende de cómo interprete los objetos cada implementación.

Ambos incidentes muestran que duplicar cachés no resuelve por sí solo un defecto compartido aguas arriba. También muestran que una anomalía de repositorio no fija automáticamente la política del router. El efecto final atraviesa datos retenidos, validación, RTR y reglas locales. La respuesta no es privar de autoridad a la validación, sino impedir que una incertidumbre en una capa se convierta sin examen en una consecuencia irreversible en la siguiente.

La contraprueba más importante: RPKI sí aporta seguridad

Una historia centrada en fallos corre el riesgo de convertir la prudencia en pretexto para no desplegar. La evidencia independiente se opone a esa lectura. El estudio revisado por pares «RPKI Is Coming of Age», publicado en 2019 a partir de datos longitudinales globales, concluyó que las configuraciones erróneas, comunes en los primeros años, se habían vuelto mucho menos frecuentes. Sus autores sostuvieron que RPKI había alcanzado una madurez compatible con un uso más estricto.

El estudio no mide adopción japonesa, no atribuye resultados a JANOG y no afirma que la tecnología esté libre de fallos. Sí respalda una explicación alternativa importante: parte de los defectos iniciales pudo corresponder a una fase inmadura de herramientas y prácticas, no a una fragilidad permanente del modelo. A medida que mejoran los validadores, las interfaces, las alertas y los procesos de corrección, disminuye el coste de usar ROV y aumenta su utilidad frente a anuncios de origen no autorizados.

La experiencia publicada sobre NTT añade una comprobación operativa. En diciembre de 2022, un caso de estudio de APNIC describió vigilancia continua de anuncios inválidos en IPv4 e IPv6 y una reducción del 86,84 % mediante software y procedimientos. La cifra procede de un caso de estudio del ecosistema RPKI, no de un conjunto de datos auditado de forma independiente. No puede presentarse como efecto de JANOG32.

Aun con esas reservas, el caso muestra algo que una narrativa de cautela no debe omitir: investigar causas, avisar a las partes responsables y corregir procesos puede reducir anuncios inválidos de forma sustancial. La seguridad de origen tiene un beneficio concreto. Una ROA correcta permite detectar que un AS no autorizado origina un prefijo o que una longitud excede lo autorizado.

Ese beneficio es limitado, pero no menor. ROV no detiene todas las fugas, no valida el camino AS y no sustituye los filtros de clientes o pares. Precisamente por eso debe evaluarse por lo que sí hace. Posponerlo indefinidamente por miedo a sus dependencias también tiene un coste: deja a la red sin una señal verificable frente a ciertos secuestros y errores de origen.

El debate maduro no enfrenta seguridad y disponibilidad como si fueran alternativas. Pregunta qué arquitectura permite obtener el beneficio de origen sin convertir un fallo común en un descarte masivo. Vigilar antes de aplicar, corregir ROA legítimas, probar la recuperación, introducir excepciones controladas y conservar una vía de reversión hacen posible una política más firme. El fallo acotado no es una excusa contra ROV; es una condición para desplegarlo con confianza.

Diversidad, vigilancia y control local

La orientación japonesa posterior reunió muchos de esos controles. La directriz JPNIC-01324, vigente desde el 13 de noviembre de 2024 y actualizada el 27 de marzo de 2026, recomienda vigilar procesos y recursos de las cachés, comprobar la recuperación de las descargas y comparar periódicamente los conjuntos de varias instancias. También aconseja introducir la política de forma gradual y probar reversión, reinicio y reconexión.

La directriz contempla respuestas locales —incluido SLURM— cuando una desconexión supera el tiempo de retención o un dato autoritativo todavía no refleja una situación legítima. Es una recomendación institucional, no una medición de cumplimiento general. Deriva de estudios de 2022 y 2023 y de consultas posteriores; no prueba que el grupo de 2013 causara su contenido.

Las excepciones locales requieren la misma disciplina que la política principal. Pueden ganar tiempo mientras se corrige una ROA, pero una excepción permanente y silenciosa erosiona la seguridad que pretendía proteger. Debe quedar documentada, someterse a revisión y desaparecer cuando se corrige el objeto autoritativo. Revertir no significa abandonar el control, sino evitar que el usuario pague durante el diagnóstico.

La topología de los servicios también cambió. En enero de 2025, una presentación de JPIX informó de puntos de caché en regiones AWS de Tokio y Osaka, accesibles por IPv4 e IPv6 mediante TCP 323. La divulgación permite identificar superficies de conexión y muestra una alternativa regionalizada. No demuestra diversidad completa de rutas de acceso, disponibilidad, número de clientes ni independencia entre ambas regiones.

En diciembre de 2025, JPNIC anunció el cierre de su prueba de caché pública, iniciada en 2015. Entre los motivos que atribuyó a la decisión estaban la preocupación por crear un punto de concentración, el descenso del uso y la existencia de orientación y alternativas ofrecidas por operadores o puntos de intercambio. La retirada del servicio no demuestra que esas alternativas sean suficientes o infalibles.

Sí refleja una evolución del problema: la comodidad de una caché central puede convertirse en dependencia común. Las cachés locales ofrecen control sobre versiones, memoria, registros y mantenimiento; los servicios compartidos pueden reducir la carga de equipos pequeños y aportar una fuente externa. Una arquitectura resistente puede combinar ambos, siempre que el operador conozca qué fallos comparten y ensaye la desaparición de cada fuente.

La diversidad debe medirse, no suponerse. Separar ubicaciones y programas reduce la posibilidad de que un incendio, reinicio o defecto de una implementación elimine todas las fuentes. No protege contra un manifiesto defectuoso descargado por todas ellas, una cadena inconsistente o una política errónea replicada en todos los routers. Comparar los conjuntos de VRP es tan importante como contar cachés: la coincidencia puede indicar normalidad o un error común aguas arriba.

El atractivo —y el peligro— de un porcentaje

La propuesta de 2013 de detener actualizaciones al rebasar un porcentaje anómalo parte de una intuición razonable: ante un cambio extremo, conservar temporalmente un estado conocido puede ser mejor que distribuir un desastre. Sin embargo, una cifra global puede crear una falsa impresión de objetividad. Una actualización masiva legítima podría activar el freno; un atacante podría intentar provocarlo para congelar VRP obsoletos; un cambio pequeño en términos porcentuales podría ser crítico para una región concreta.

El registro de JANOG32 no permite evaluar falsos positivos, falsos negativos, ventana temporal, línea base, denominador ni procedimiento de recuperación. Ni siquiera conserva la cifra sugerida. No se encontró una regla adoptada por JANOG, una función de proveedor ni un umbral numérico aplicado en producción japonesa. La ausencia de un registro público no prueba que nadie experimentara en privado; impide presentar el mecanismo como hecho o política.

La cuestión reapareció bajo otra forma en la propuesta de JANOG58 sobre fiabilidad de cachés, presentada el 16 de julio de 2026. El resumen describía un «VRP breaker» capaz de pausar la distribución al detectar anomalías o conjuntos incompletos que pudieran producir falsos Invalid. En la fecha de consulta, el 20 de julio, no había presentación completa, método, resultado de despliegue ni validación independiente disponibles públicamente. Era una propuesta asociada a una solicitud de patente pendiente, no un sistema probado.

Entre 2013 y 2026 hubo nuevos RFC, cambios de software, despliegues de operadores e incidentes de registros. No existe una cadena documental que demuestre que la segunda propuesta descienda de la primera. La relación defendible es temática: en dos momentos públicos de JANOG se preguntó cómo evitar que un conjunto de VRP anómalo se distribuyera sin freno. Afirmar herencia técnica exigiría documentos de diseño, decisiones explícitamente atribuidas y resultados comparables.

Un interruptor automático también amplía la superficie de ataque. Para ser un control y no una causa adicional de fallo, tendría que publicar su línea base, permitir inspección, limitar el tiempo de congelación, alertar de inmediato y ofrecer una salida manual gobernada. Habría que probarlo con cambios legítimos y hostiles, distintos tamaños de tabla y varias implementaciones. Nada de eso puede darse por demostrado a partir de un resumen de programa.

Qué significa degradarse sin cortar

Fallar de forma segura no significa declarar Valid cualquier error ni aceptar indefinidamente anuncios no autorizados. Significa que cada capa responde de manera proporcional y observable. El repositorio publica de forma coherente y alerta antes de que caduquen objetos críticos. El validador explica qué rama rechaza y conserva datos cuando el protocolo y la política lo permiten. RTR dispone de alternativas y tiempos conocidos. El router expone los cambios. La política local puede avanzar por etapas y retroceder sin improvisación.

También significa separar una anomalía estadística de un veredicto operativo. Un aumento de rutas Invalid exige investigación, pero puede tener causas distintas: una longitud máxima mal definida, un cambio de origen durante una migración, una ROA caducada, una publicación incompleta o un anuncio hostil. Una alarma que solo muestra un porcentaje y una luz roja desplaza el riesgo desde los datos hacia la automatización.

Retener información tiene asimismo dos caras. Conserva continuidad durante una interrupción breve, pero puede prolongar un conjunto ya obsoleto. La retención necesita límites conocidos, métricas de edad y una estrategia de salida. Cambiar inmediatamente a otra caché solo ayuda si la alternativa no comparte el mismo defecto. La redundancia útil se define por sus dominios de fallo, no por el número de procesos.

Por último, cualquier evaluación necesita un criterio de impacto. El estado de una ROA, la cantidad de VRP ausentes y el número de rutas Invalid son indicadores técnicos. El objetivo es preservar la integridad del origen y la conectividad legítima. Después de un incidente, los operadores y registros deberían publicar denominadores suficientes: rutas, instancias de validación, redes, tráfico y usuarios afectados. Sin ellos puede repararse el mecanismo, pero no calcularse el daño ni compararse una mejora.

Los registros de 2013 no contienen esos denominadores. Tampoco muestran el número exacto de participantes que completaron cada prueba, un ensayo deliberado de «todo Invalid», un umbral adoptado ni una línea causal hasta los despliegues posteriores. Los incidentes de JPNIC y RIPE NCC carecen de medidas completas de usuario. Estas lagunas no son detalles que la prosa deba rellenar; forman parte de la respuesta.

Una herencia temática, no una genealogía demostrada

La experiencia de 2013 no necesita ser el comienzo de todo para resultar importante. El grupo temporal reunió a personas que emitieron certificados y ROA, trabajaron con cachés, trasladaron datos por RTR y observaron estados en routers. Los defectos iniciales mostraron herramientas inmaduras; la segunda ronda y las sesiones simplificadas permitieron continuar. La discusión de julio convirtió la pérdida de caché, la recarga, la corrupción de datos y los estados masivos en preguntas públicas.

Al mismo tiempo, RFC 6810 ya había especificado retención y cachés alternativas, y RFC 7115 situó la decisión en la política local. JPNIC desarrolló su superficie registral y de servicio. IIJ describió su despliegue. NTT publicó resultados de monitorización. JPIX ofreció puntos de caché. Los incidentes de RIPE NCC y JPNIC revelaron fallos reales de publicación. Cada uno aporta una ruta independiente hacia las prácticas actuales.

El archivo disponible no permite afirmar que JANOG32 causara esa secuencia. Sí permite hablar de convergencia. Cuanto mayor es el poder de ROV para influir en la selección de rutas, más importan la diversidad, la observación, la introducción gradual, la reparación de datos y la reversión. La autoridad de la señal no procede solo de la criptografía, sino también de que los operadores conozcan su procedencia y detecten su deterioro antes de que una incertidumbre se convierta en un agujero en la tabla.

Para demostrar una genealogía directa harían falta registros de decisiones de operadores, documentos de diseño que atribuyeran controles concretos al trabajo de 2013 y resultados comparables antes y después. Para evaluar un freno porcentual harían falta una métrica, un denominador, una ventana, pruebas frente a cambios legítimos y hostiles, y tiempos de recuperación. Para estimar los incidentes harían falta medidas de tráfico y usuarios. Ninguno de esos datos puede sustituirse con semejanzas retrospectivas.

Conclusión: una señal fuerte debe saber dudar

La pregunta más fértil del ensayo de 2013 no fue si RPKI funcionaba durante una demostración. Fue qué debía ocurrir cuando la señal destinada a aumentar la confianza parecía perderla. JANOG hizo visible la pregunta al convocar una experiencia temporal y conservar el debate. No asignó recursos, no certificó la Internet japonesa, no ordenó filtros y no adoptó un número mágico.

El conjunto de la evidencia ofrece una respuesta menos espectacular y más útil. La validación de origen merece desplegarse porque reduce una clase real de riesgo y porque la tecnología y las prácticas han madurado. Pero su poder necesita límites: publicación coherente, validadores observables, cachés diversas, retención con una edad conocida, pruebas de reinicio, introducción gradual, excepciones temporales y políticas reversibles.

Las distinciones técnicas son también límites al poder. Una ROA inválida como objeto no equivale a una ruta Invalid; una ruta NotFound no equivale a un rechazo; un estado Valid no santifica una ruta; una pérdida de datos no demuestra una interrupción. Cada paso exige una observación y una decisión propias.

Un sistema de confianza merece autoridad cuando distingue la evidencia de su ausencia, una anomalía de un ataque y la suspensión de una actualización de la suspensión de Internet. La prudencia no consiste en mantener ROV fuera de producción. Consiste en desplegarlo de manera que un control averiado no obtenga permiso automático para convertirse en daño.

Fuentes consultadas

Metadatos editoriales

Campo Valor
Título SEO RPKI: validar el origen sin amplificar un fallo
Descripción SEO Los ensayos de JANOG en 2013 hicieron visibles los límites operativos de RPKI. Estándares, despliegues e incidentes muestran cómo validar el origen sin convertir una anomalía en desconexión.
Palabra clave principal seguridad ante fallos de RPKI
Slug janog-rpki-validacion-origen-fallo-seguro
Título Open Graph RPKI con frenos: la pregunta operativa que dejó JANOG
Descripción Open Graph Una investigación sobre repositorios, validadores, RTR y política local, y sobre la diferencia decisiva entre un objeto inválido, una ruta NotFound y una interrupción.
Título de Twitter/X Cómo dar autoridad a RPKI sin amplificar el fallo
Descripción de Twitter/X Del laboratorio de JANOG en 2013 a los incidentes y despliegues posteriores: por qué la validación de origen necesita controles observables y reversibles.
Texto alternativo de imagen Ilustración editorial del flujo RPKI entre varios repositorios, dos validadores situados en dominios de fallo distintos y un router; una actualización anómala queda en pausa mientras el tráfico legítimo continúa por una ruta separada.
Pie de imagen Dos cachés solo aportan resiliencia si su software, sus ubicaciones y los datos de los que dependen no comparten el mismo punto de fallo.
Descripción de accesibilidad Ilustración horizontal de arquitectura de red. A la izquierda aparecen repositorios de certificados; en el centro, dos validadores comparan conjuntos de VRP y aíslan una diferencia; a la derecha, un router mantiene el tráfico mientras la actualización se revisa. No representa una instalación ni un incidente real de JANOG, JPNIC, IIJ, NTT o JPIX.
Procedencia visual Ilustración editorial original basada en la arquitectura descrita por RFC 6810 y RFC 7115 y en los registros públicos de pruebas, despliegues e incidentes citados; no reproduce una persona, sala, equipo o configuración reales.

Registro de fuentes de publicación