Fuga de ruta de Cox 2025: contención RPKI como prueba

Resumen

El análisis de APNIC de los registros de actualización BGP encontró que AS22773 apareció como origen de 4.651 rutas IPv4 adicionales el 1 de mayo de 2025. El punto de observación no rechazó intencionalmente las rutas inválidas RPKI, lo que hizo visibles allí las rutas que un hablante que rechaza inválidas excluiría. [1]
Las incorporaciones se produjeron en dos grandes oleadas. APNIC registró alrededor de 3.365 rutas entre las 16:45 y las 16:50 UTC aproximadamente, y luego alrededor de 1.141 entre las 17:50 y las 17:55. Los retiros generalizados también llegaron en dos etapas, alrededor de las 21:30 a 21:45 y 22:30 a 22:40. Estos son tiempos de recepción en un observador, no marcas de tiempo de un cambio interno de Cox. [1]
De las 4.651 rutas adicionales, 4.644 habrían sido inválidas según RPKI para un hablante validador. Siete no estaban cubiertas por un ROA válido. Ese resultado demuestra una gran diferencia de contención entre un punto de observación no validador y una red que rechaza rutas inválidas, sin probar lo que cada red aceptó o exportó. [1]
Un ROA proporciona autorización para que un AS origine un prefijo, y la Validación de Origen de Ruta evalúa el par prefijo-origen observado frente a los datos de autorización validados. ROV no autentica cada AS en la ruta, prueba la relación comercial detrás de un anuncio, ni establece que una ruta fuera operativamente intencionada. [8][10][11]
El daño confirmado es a la integridad del enrutamiento. Los orígenes erróneos ingresaron a la información BGP retenida por el observador y permanecieron disponibles para redes que no rechazan rutas inválidas. El registro proporcionado no establece una interrupción visible para el usuario, desvío de paquetes, interceptación, pérdida de clientes, acción regulatoria o daño monetario. [1][8]
La contención por redes posteriores no excusa al origen. Cox controló la creación de rutas, redistribución, política de salida, revisión de despliegue, monitoreo, retiro y divulgación. Los titulares de recursos controlaron la precisión de los ROA, mientras que los pares y proveedores de tránsito controlaron por separado los filtros de importación, ROV y decisiones de propagación.
La cifra entonces actual de APNIC de que los ROA cubrían aproximadamente el 95.06% del conjunto de prefijos IPv4 anunciados por Cox es un contexto de adopción útil, no una prueba de la configuración exacta el 1 de mayo ni una explicación de la validez de cada ruta filtrada. Las vistas actuales de APNIC Labs, RIPEstat y Cloudflare Radar no deben leerse hacia atrás como instantáneas históricas. [1]-[3][5][6]
Las comprobaciones de origen en el lado de exportación, los Roles BGP, el mecanismo Solo-para-Cliente, los filtros explícitos de prefijos y AS-path, y las defensas orientadas a la ruta como Peerlock representan diferentes clases de control. Sus registros de estándares e investigación muestran lo que los operadores pueden implementar, pero no establecen qué controles tenía Cox o algún vecino habilitados durante este evento. [12]-[17]
La evidencia pública puede respaldar una conclusión de contención solo si sus límites permanecen visibles. Un solo observador no validador muestra la recepción en esa ubicación. No muestra la aceptación vecino por vecino, la selección de ruta, la exportación posterior, el flujo de tráfico, el alcance global, ni la hora exacta y la causa de una corrección interna.
Un registro de responsabilidad creíble agregaría un inventario de prefijos previstos, pruebas semánticas de política de exportación, alarmas de origen anómalo, evidencia de despliegue escalonado, datos de rechazo de vecinos, instantáneas ROA históricas, tiempos de retiro exactos y una explicación posterior al evento del desencadenante, propiedad y reparación. Hasta que exista esa evidencia, la fuga accidental y la contención material por ROV siguen siendo conclusiones probables, mientras que la causa raíz, el impacto en el usuario y la remediación siguen siendo desconocidos.

El contraste es la evidencia

El hecho más importante en este evento no es simplemente que miles de rutas aparecieron con un origen inesperado. Las fugas de rutas a menudo se describen a través de las rutas que se propagaron, los servicios que fallaron o las organizaciones que luego explicaron un error de configuración. El registro proporcionado para el 1 de mayo de 2025 es diferente. Proporciona un contraste observacional controlado entre un punto de vista BGP que retuvo intencionalmente rutas inválidas y el conjunto de rutas que permanecerían utilizables bajo una política que las rechaza.

El análisis de APNIC de Geoff Huston informó 4.651 rutas IPv4 adicionales con AS22773 como origen observado. Luego evaluó esos pares prefijo-origen frente a los datos de autorización RPKI. Del conjunto completo, 4.644 habrían sido clasificadas como inválidas por un hablante con conocimiento de RPKI. Siete no tenían cobertura ROA válida. [1] Esos números no muestran que cada red validadora se comportara de manera idéntica, pero identifican un límite técnico claro: casi todo el conjunto observado era susceptible de rechazo por validación de origen porque el registro de autorización no permitía que AS22773 lo originara.

Eso es evidencia de control positiva. Los datos de autorización existían independientemente del evento. Las redes podían obtenerlos y validarlos de forma independiente. Cada red podía entonces aplicar su propia política de enrutamiento al estado de validez resultante. Una red que rechaza rutas inválidas no necesitaba que Cox identificara el error, publicara una autopsia o solicitara que cada ruta fuera filtrada. El desajuste entre el origen observado y la autorización publicada era comprobable por máquina.

La misma evidencia también define lo que no se puede afirmar. El observador de APNIC estaba deliberadamente configurado para no descartar las rutas simplemente por ser inválidas. Por lo tanto, su vista no puede presentarse como la vista de una red validadora típica. Inversamente, la clasificación no prueba que cada red que afirma realizar ROV tuviera datos actualizados, aplicara el rechazo a cada sesión, o impidiera que cada ruta fuera seleccionada o exportada. El resultado es un contrafáctico de política sólido, no un censo global.

La distinción importa para la responsabilidad. Si el evento se describe solo como una fuga que fue "detenida por RPKI", la frase oculta los actores y decisiones que produjeron el resultado. Los titulares de recursos tenían que publicar autorizaciones precisas. Los repositorios y validadores RPKI tenían que poner a disposición datos utilizables. Los operadores tenían que elegir validar y rechazar. Los monitores tenían que preservar una vista no validadora para que se pudiera observar la diferencia. Mientras tanto, la red originante aún tenía que controlar lo que originaba y exportaba.

La contención surgió de capas independientes, no de un escudo automático.

Ese resultado en capas es el nexo directo con la infraestructura de red del artículo. Elimine el origen BGP, los datos ROA y la política de rechazo local, y tanto el evento como la comparación de evidencia desaparecen. La cuestión de la responsabilidad no está ligada al enrutamiento como analogía. Se deriva de quién controlaba los anuncios, quién controlaba los objetos de autorización, quién controlaba la aceptación, y quién retuvo suficiente evidencia para probar la afirmación de contención.

Un evento de dos etapas visto desde un punto de vista

La línea de tiempo comienza con el observador, no con un cambio interno asumido. APNIC informó una primera gran adición de aproximadamente 3.365 rutas entre las 16:45 y las 16:50 UTC. Una segunda adición de aproximadamente 1.141 rutas siguió entre las 17:50 y las 17:55. Los retiros amplios aparecieron más tarde en dos etapas, con los cambios más grandes alrededor de las 21:30 a 21:45 y 22:30 a 22:40. [1]

Esas cifras deben permanecer en sus contextos informados. Los dos recuentos de intervalos son observaciones amplias de cambio, mientras que 4.651 es el recuento del análisis para el conjunto de rutas adicionales a lo largo del evento. No deben forzarse a una nueva descomposición aritmética ni usarse para inferir una tercera etapa no documentada. La declaración defendible es que el observador vio dos oleadas dominantes de adiciones, un conjunto total de 4.651 orígenes adicionales, y dos oleadas dominantes de retiros.

El tiempo de recepción tampoco es tiempo de acción. Un colector BGP registra las actualizaciones después de que han pasado a través de relaciones de enrutamiento y decisiones de política para alcanzarlo. La primera actualización visible a las 16:45 UTC no es prueba de que un operador de Cox, un sistema de automatización o un enrutador cambiaron de estado exactamente a las 16:45. El último retiro visible alrededor de las 22:40 no es prueba de que la reparación interna terminó en ese momento. La línea de tiempo pública mide cuándo un observador recibió información de enrutamiento.

Esa precaución no hace que la línea de tiempo sea débil. La forma es operativamente importante. Miles de orígenes llegaron dentro de un intervalo corto, otro gran conjunto llegó aproximadamente una hora después, y la eliminación amplia ocurrió varias horas después de las primeras observaciones. La secuencia es consistente con una exportación no intencionada y una corrección posterior, que es la razón por la cual el análisis proporcionado trata una fuga accidental como probable. No es evidencia de intención maliciosa, y no identifica el cambio que produjo los anuncios.

Las dos oleadas invitan a preguntas de control sin responderlas. ¿Se activaron dos rutas de política por separado? ¿Una configuración afectó a diferentes grupos de rutas en diferentes momentos? ¿El monitoreo detectó la primera oleada antes de la segunda? ¿Los retiros fueron escalonados por necesidad técnica, por dispositivos separados o por grupos de política separados? Nada en el registro proporcionado elige entre esas posibilidades. Un relato responsable puede identificar las preguntas porque las marcas de tiempo las hacen medibles, pero no puede convertirlas en hallazgos.

Los retiros también muestran corrección en la vista de enrutamiento, no remediación duradera. Eliminar un anuncio erróneo es necesario. No establece por qué se creó el anuncio, si la configuración responsable se revirtió, si se agregó una protección, si quedó una ruta similar en otro lugar, o si una reparación probada evitó la recurrencia. Un registro posterior al evento necesitaría conectar los retiros observados con la evidencia de cambio interno.

Aquí es donde la observación independiente apoya la responsabilidad. El operador controla sus registros internos y registros de cambios. Los monitores externos controlan evidencia separada de lo que les llegó y cuándo desapareció. Cuando esos registros se comparan, pueden probar declaraciones sobre detección, respuesta y propagación. Sin el registro externo, el público tendría solo la línea de tiempo que el origen eligiera divulgar. Sin registros internos, el observador puede describir la visibilidad de la ruta pero no la causa raíz.

Qué significan las 4.644 clasificaciones inválidas

BGP proporciona información de alcanzabilidad entre sistemas autónomos. La línea base del protocolo describe cómo los hablantes intercambian información de enrutamiento y usan atributos, incluida una ruta AS, para tomar decisiones de enrutamiento. No prueba, por sí mismo, que el origen al final de una ruta recibida estuviera autorizado por el titular del espacio de direcciones. [9]

RPKI agrega una capa de autorización separada. Una Autorización de Origen de Ruta establece que un AS está autorizado para originar un prefijo cubierto. Las especificaciones de validación de origen describen cómo un hablante BGP puede comparar un prefijo y un AS de origen observados con datos de autorización validados y asignar un resultado de validez. [10][11] En este evento, esa comparación fue decisiva: el observador vio AS22773 como el origen, mientras que el estado de autorización hizo que 4.644 de las 4.651 rutas adicionales fueran inválidas para un hablante validador. [1]

Inválido es un resultado preciso, pero no es un veredicto completo sobre la ruta. Dice que el par prefijo-origen observado entra en conflicto con el estado de autorización validado. No prueba por qué ocurrió el conflicto. Una mala exportación, una ruta de redistribución no intencionada, una política local obsoleta u otro evento operativo pueden producir el desajuste. El registro público aquí no identifica cuál de ellos lo hizo.

Inválido tampoco autentica la ruta AS completa. Una ruta puede tener un origen que está autorizado mientras se propaga de una manera que viola las relaciones comerciales previstas. También puede tener un origen no autorizado incluso si la ruta visible contiene números AS reales. ROV responde a la pregunta de autorización de origen. No prueba que cada relación de tránsito, segmento de ruta o decisión de exportación fuera legítima.

Ese límite es por qué las siete rutas no cubiertas importan. No compartían la misma base de ROA válida para una clasificación inválida. La ausencia de esa cobertura de autorización no las hace demostrablemente legítimas, y no prueba que las redes las aceptaran o usaran. Significa que este mecanismo de contención particular no podía rechazarlas en la misma base inválida. Diferentes filtros, política de ruta o decisiones del operador tendrían que asumir la carga de control.

La cifra de 4.644 es, por lo tanto, evidencia de precisión de autorización fuera del propio sistema de exportación del origen con fugas. Los titulares de recursos habían publicado información que permitía a una red validadora distinguir un origen AS22773 no autorizado de uno autorizado. El valor de esa información se hizo visible precisamente porque el evento de origen fue incorrecto. Una ruta correcta y una ruta incorrecta pueden verse similares a nivel de la sintaxis BGP ordinaria; RPKI proporciona a la política una entrada de autorización verificable externamente.

APNIC también informó una cobertura ROA entonces actual de aproximadamente el 95.06% para el conjunto de prefijos IPv4 anunciados por Cox. [1][2] Esa cifra pertenece al registro, pero no debe confundirse con la clasificación de 4.644. La métrica de cobertura de Cox describe el contexto de autorización para los prefijos que Cox anunció. El conjunto filtrado involucró a AS22773 apareciendo como origen para rutas adicionales cuyo estado de autorización en gran medida no permitía ese origen. La contención dependía de los datos de autorización de los titulares de recursos relevantes y de la política de validación de cada red receptora.

La vista RPKI asociada de APNIC Labs puede proporcionar contexto de comportamiento, mientras que el registro RDAP de ARIN establece el contexto de registro para AS22773. [3][4] RIPEstat y Cloudflare Radar ofrecen contexto de enrutamiento adicional para el ASN. [5][6] Ninguna de esas superficies actuales debe usarse como sustituto de una instantánea histórica del 1 de mayo. El estado del panel puede cambiar a medida que cambian las rutas, las autorizaciones y los métodos de medición. El hallazgo del evento se basa en el análisis histórico y sus datos de actualización observados, no en leer un gráfico actual hacia atrás.

La contención es un contrafáctico de política, no una afirmación de alcance global

La frase "RPKI contuvo la fuga" solo es defendible cuando sus términos son explícitos. El punto de observación de APNIC retuvo rutas inválidas. Un hablante que usa el mismo estado de autorización validado y una política que rechaza rutas inválidas excluiría 4.644 rutas del conjunto utilizable. El contraste observado demuestra lo que la política de rechazo podría contener. No enumera cada red que aplicó esa política.

Esta diferencia separa recepción, clasificación, aceptación, selección y propagación. Un enrutador puede recibir una actualización de un vecino y clasificar su estado de origen. La política local determina entonces si esa actualización permanece elegible. Una ruta rechazada puede aún estar presente en un registro de diagnóstico aunque no sea seleccionada para reenvío o anunciada a otros. La evidencia de APNIC se refiere a rutas retenidas por un observador no rechazador y la clasificación que recibirían bajo validación. No es telemetría de paquetes.

Como resultado, el análisis no prueba que el tráfico fuera desviado hacia AS22773. No prueba que un cliente experimentara pérdida, latencia o falla de alcanzabilidad. No prueba interceptación. Tampoco prueba que ningún usuario se viera afectado. Esos resultados requieren mediciones de tráfico, declaraciones de redes afectadas o evidencia de servicio que no está en el registro proporcionado.

La misma disciplina se aplica a la propagación. La recepción de un observador prueba que los anuncios cruzaron suficientes límites de política para llegar a ese observador. No establece alcance global. No identifica cada vecino que aceptó las rutas, cada upstream que las exportó, cada servidor de rutas que las retransmitió o cada red que las rechazó. Una reproducción con múltiples colectores podría producir un mapa de propagación más amplio, pero esa evidencia no se proporciona aquí.

La metodología de monitoreo RPKI del NIST es relevante porque las mediciones de validación dependen de datos, punto de vista, sincronización y método de clasificación. [7] Una conclusión de validez histórica debe vincular la vista de ruta al estado de autorización utilizado en ese momento. Una verificación de validez actual puede ser informativa pero puede no reproducir lo que los validadores sabían durante el evento. Esa es la razón por la cual las instantáneas ROA históricas son parte de la evidencia faltante.

La guía práctica del NIST explica la arquitectura y los riesgos de integridad del enrutamiento que la validación de origen está diseñada para abordar. [8] Puede apoyar la conclusión de que los orígenes no autorizados crean un problema de control y que ROV proporciona una defensa práctica. No puede convertir el evento de Cox en un evento probado de interrupción o pérdida. Las clases de daño generales no son hallazgos de daño específicos del evento.

La conclusión más sólida es más estrecha y más útil. La fuga llegó a un observador deliberadamente no validador. Casi todos los pares prefijo-origen adicionales eran incompatibles con los datos de autorización validados. Por lo tanto, un operador que rechaza rutas inválidas tenía una base concreta y localmente ejecutable para evitar que esas rutas ingresaran a su conjunto de rutas utilizable. La evidencia respalda un potencial de contención material y una probable contención real, mientras que el resultado exacto red por red sigue siendo desconocido.

El daño confirmado es a la integridad del enrutamiento

El análisis de riesgos a menudo se debilita cuando un mecanismo dramático se utiliza para respaldar una afirmación de impacto no respaldada. Eso es innecesario aquí. El evento tiene un daño confirmado incluso sin evidencia de una interrupción: la información de enrutamiento fue contaminada por miles de orígenes adicionales que el sistema de autorización identificó en gran medida como inválidos.

La integridad del enrutamiento importa porque los operadores dependen de los anuncios recibidos para decidir dónde son alcanzables los prefijos. Un origen erróneo crea exposición en cada red que lo recibe sin una regla de rechazo efectiva. La exposición no es idéntica al desvío de tráfico, pero es la condición previa que puede hacer que una ruta incorrecta esté operativamente disponible.

El observador no validador demuestra esa exposición directamente. Su política preservó los anuncios, mostrando que la propagación BGP ordinaria podía llevarlos hasta ese punto. Una red con visibilidad comparable pero sin rechazo de inválidos podría haberlos retenido como candidatos. Si los seleccionó o exportó dependería de sus otras rutas y políticas. La evidencia pública no resuelve esas decisiones posteriores.

Este límite evita tanto la subestimación como la exageración. Llamar al evento inofensivo porque una gran parte de Internet puede haber aplicado ROV ignoraría la contaminación observada y las siete rutas sin la misma cobertura de autorización. Llamarlo una interrupción importante inventaría un resultado. La declaración de impacto correcta es que los orígenes adicionales de AS22773 crearon exposición a la integridad del enrutamiento, mientras que los ROA precisos y la política ROV local proporcionaron una capa de contención medible.

La calificación del impacto debería reflejar la importancia del control en lugar de una pérdida de clientes asumida. El evento probó una salvaguarda de enrutamiento de Internet contra un gran conjunto de orígenes erróneos. También mostró la exposición residual de las redes no validadoras y las rutas no cubiertas. Ese es un evento de infraestructura significativo aunque las fuentes proporcionadas no establezcan una víctima nombrada o consecuencia financiera.

El éxito posterior no transfiere el deber del origen

El error de responsabilidad más importante sería tratar el filtrado exitoso posterior como un permiso para que una red originante dependa de sus vecinos. ROV es valioso porque las redes independientes pueden protegerse a sí mismas. Esa independencia no cambia quién controló la creación y exportación de los orígenes incorrectos.

Cox controló los sistemas y políticas que hicieron que AS22773 apareciera como origen. El registro público no revela el mecanismo interno, pero las categorías de control son claras: creación de rutas, redistribución de rutas, política de salida, despliegue de cambios, monitoreo, escalamiento, retiro y divulgación. Cada categoría permanece con el operador incluso cuando otra red rechaza el resultado.

Un inventario de prefijos previstos es la primera unidad de evidencia. Un operador debería poder declarar qué prefijos puede anunciar cada AS de origen y cada contexto de exportación. Ese inventario debe ser utilizable para la generación y prueba de políticas, no solo documentado después del evento. Un cambio que haría que un AS originara miles de prefijos adicionales debe compararse con el conjunto previsto antes de que llegue a una sesión externa.

Las pruebas semánticas son diferentes de verificar si una configuración se analiza correctamente. Una política sintácticamente válida aún puede exportar las rutas incorrectas. La prueba relevante pregunta qué anunciaría la política resultante después de la redistribución de rutas, las transformaciones locales y las reglas específicas de la sesión. Una prueba debería fallar cuando el resultado efectivo excede el límite de prefijo y origen previsto.

El despliegue escalonado es otro control del lado del origen. Una política que cambia la elegibilidad de rutas a través de muchas sesiones no debería necesitar el sistema de enrutamiento global para revelar su significado. La implementación limitada, la inspección de diferencias de rutas y las condiciones de parada automática pueden exponer un cambio grande en el conjunto de orígenes antes de que llegue a cada salida afectada. El registro proporcionado no establece si Cox usó tales controles.

El monitoreo debe buscar cambios semánticos, no solo la salud del dispositivo. Un enrutador puede estar disponible y una sesión BGP puede permanecer establecida mientras las rutas enviadas a través de él son incorrectas. Una alarma de origen anómalo puede comparar el conjunto originado actual con una línea base aprobada. Un umbral de cambio máximo puede requerir revisión cuando aparecen miles de rutas. Los monitores independientes pueden confirmar lo que escapó de la propia telemetría de la red.

La evidencia de respuesta conecta entonces la detección con el retiro. La eliminación observada en dos etapas proporciona marcas de tiempo externas. El registro interno de Cox podría mostrar cuándo se detectó la anomalía por primera vez, quién fue el propietario de la decisión, qué sesiones o políticas se cambiaron, por qué el retiro ocurrió en dos oleadas amplias y qué comprobaciones confirmaron la finalización. Sin ese registro, el público puede ver la corrección en la alimentación de rutas pero no la ruta de control detrás de ella.

La divulgación es parte de la responsabilidad operativa porque el origen posee hechos que los externos no pueden recuperar solo de BGP. Una explicación posterior al evento no necesita exponer configuraciones sensibles. Puede identificar la clase de control que falló, la escala de la exportación no intencionada, la fuente de detección, la secuencia de corrección, las salvaguardas agregadas y la evidencia utilizada para probarlas. Ninguna autopsia de Cox está presente en el registro proporcionado, por lo que ninguno de esos detalles puede afirmarse.

La precisión de los ROA pertenece a los titulares de recursos

El evento también muestra por qué los datos de autorización son un control operativo, no un metadato de registro decorativo. Los 4.644 resultados inválidos fueron posibles porque los titulares de recursos relevantes habían proporcionado autorización que no permitía a AS22773 como origen. Su acción de control ocurrió antes de la fuga, y las redes posteriores podían consumirla sin coordinarse con Cox durante el evento.

Eso produce un modelo de responsabilidad distribuida. Un titular de recursos controla si sus ROA describen con precisión los arreglos de origen autorizados. Un servicio RIR y el sistema de publicación RPKI más amplio apoyan la disponibilidad del material firmado. Las partes confiadas validan los datos. Los operadores de red deciden cómo el estado de validación afecta la política de enrutamiento. Ninguna parte controla toda la cadena.

La precisión es esencial porque un error de autorización puede crear un modo de falla diferente. Una autorización excesivamente estrecha, obsoleta o incorrecta puede hacer que un anuncio legítimo sea clasificado como inválido. Ese resultado inverso está fuera del evento de este artículo, pero explica por qué la adopción de RPKI debe incluir coordinación de cambios y pruebas. La evidencia positiva aquí proviene de datos de autorización que distinguieron los orígenes erróneos; no es una afirmación de que cada ROA sea siempre correcto.

Las siete rutas no cubiertas identifican el residual. Donde ninguna autorización válida cubre una ruta, una política de rechazo de inválidos carece de la misma base para bloquear el origen. Eso no traslada la responsabilidad fuera del operador de origen. Muestra que la cobertura del titular de recursos y los controles de exportación del lado del operador resuelven diferentes partes del problema.

La evidencia histórica es, por lo tanto, parte de la gobernanza de los ROA. Un panel actual no puede mostrar concluyentemente qué autorización existía cuando se observó una actualización. Los titulares de recursos, repositorios y monitores deben preservar instantáneas que permitan a un revisor posterior reproducir la clasificación de validez en el momento relevante. En este evento, una instantánea histórica capaz de probar los recuentos de 4.644 y siete fortalecería el registro.

La política del vecino es una superficie de control separada

Los pares y proveedores de tránsito controlaron lo que sucedió después de que los anuncios salieron de AS22773. Sus controles incluían filtros de prefijos, filtros AS-path, política ROV, límites de prefijos máximos, alertas de cambios anómalos y reglas de exportación posterior. El hecho de que el origen fuera responsable de las rutas incorrectas no hace que las decisiones del vecino sean irrelevantes. Un vecino puede restringir o amplificar un error del origen.

ROV es la evidencia más clara del lado del vecino en este caso. Una red que rechaza rutas inválidas tenía una razón directa para excluir 4.644 pares prefijo-origen. Esa política protegió a la red y limitó las rutas disponibles para propagación posterior. También redujo la dependencia de una lista mantenida manualmente de cada prefijo que se esperaba que Cox originara.

Sin embargo, ROV por sí solo no resuelve cada fuga. La taxonomía de fugas de rutas reconoce que los anuncios pueden escapar de una relación prevista incluso cuando el origen en sí está autorizado. [12] En tal caso, un par prefijo-origen puede pasar ROV mientras que la ruta viola una expectativa de exportación. Este evento produjo un gran conjunto inválido, por lo que la validación de origen fue inusualmente efectiva. Ese éxito no debe generalizarse a cada fuga de ruta.

El filtrado explícito de prefijos sigue siendo relevante para las siete rutas no cubiertas y para la defensa en profundidad. La guía de MANRS coloca tanto el filtrado de prefijos como el de AS-path en el conjunto de controles del operador. [15] Un proveedor que tiene una visión confiable de lo que un cliente puede anunciar puede rechazar rutas fuera de ese límite. Las reglas de AS-path también pueden detectar relaciones o contenidos de ruta que no deberían llegar desde una sesión determinada.

Los controles de prefijo máximo son útiles pero incompletos. Un umbral puede detectar un cambio repentino en el recuento de rutas, pero un recuento por sí solo no prueba que cada ruta esté autorizada o prevista. Un umbral alto puede permitir un error grande; un umbral bajo puede interrumpir un cambio legítimo. El diseño más sólido combina barreras basadas en recuento con políticas conscientes de la autorización y la relación.

La evidencia del vecino haría medible la afirmación de contención. Cada vecino directo podría informar cuántas de las rutas adicionales recibió, cuántas clasificó como inválidas, cuántas rechazó, si alguna fue seleccionada y si alguna fue exportada. La divulgación agregada podría preservar la confidencialidad comercial mientras muestra el resultado del control. No hay datos vecino por vecino en el registro proporcionado.

La asignación de responsabilidad es, por lo tanto, asimétrica pero compartida. Cox retuvo la responsabilidad principal de prevenir orígenes erróneos y corregirlos. Los vecinos retuvieron la responsabilidad de proteger sus propios dominios de enrutamiento y limitar la propagación. Los titulares de recursos retuvieron la responsabilidad de autorizaciones precisas. El éxito de una capa es evidencia de que los controles en capas funcionan, no una razón para que otra capa desaparezca.

Las salvaguardas de exportación y relación abordan diferentes clases de fallas

El registro de estándares proporciona clases de control adicionales sin probar su implementación. RFC 8893 aborda la validación de origen RPKI en el contexto de exportación y dirige la atención al origen efectivo después de las transformaciones de enrutamiento local de una red. [13] Eso importa porque una ruta puede cambiar de significado dentro de un operador antes de la exportación. Una verificación que ocurre en solo un punto de ingreso puede no evaluar el resultado prefijo-origen que un vecino externo recibirá realmente.

Para AS22773, la pregunta relevante es si el prefijo y el origen efectivos exportados se compararon con un límite aprobado y autorizado antes de que las actualizaciones salieran de la red. La evidencia pública no puede responderla. El estándar muestra que la validación del lado de exportación es una opción de control reconocida; no establece las capacidades del enrutador de Cox, la configuración o la aplicación el 1 de mayo.

RFC 9234 proporciona un control orientado a la relación a través de Roles BGP y el mecanismo Solo-para-Cliente. [14] Estos mecanismos ayudan a las redes a expresar roles de sesión e identificar anuncios que no deben propagarse en ciertas direcciones. Abordan una dimensión diferente de la autorización de origen: si la propagación de una ruta es consistente con la relación representada por la sesión.

Esa distinción importa porque un operador puede producir al menos dos clases amplias de errores. Puede originar un prefijo que no está autorizado a originar, lo que ROV puede identificar cuando existe autorización. O puede propagar una ruta con un origen autorizado más allá de su relación prevista, lo que puede requerir controles de ruta y relación. Un diseño de enrutamiento robusto trata estas como comprobaciones complementarias.

La guía de filtrado de MANRS hace explícita la expectativa operativa al incluir controles de prefijo y AS-path en lugar de reducir la seguridad del enrutamiento a una bandera de validez. [15] El marco de medición del Observatorio MANRS también reconoce las fugas de rutas y las redes que habilitan la propagación como fenómenos medibles. [16] La medición no asigna responsabilidad legal, pero puede mostrar si un operador origina, acepta o propaga repetidamente información de enrutamiento anómala.

La investigación de Peerlock proporciona evidencia de que las defensas orientadas a la ruta pueden restringir la propagación de fugas de rutas. [17] Su relevancia aquí no es que Peerlock estuviera necesariamente implementado por Cox o sus vecinos. El registro proporcionado no dice eso. La investigación demuestra que los operadores tienen opciones de control más allá de ROV cuando la ruta o la relación, en lugar de la autorización de origen, lleva la advertencia.

Estas clases de control no deben colapsarse. ROV verifica la autorización de origen. Los filtros de prefijos comparan los anuncios con un conjunto permitido. Los filtros AS-path inspeccionan el contenido de la ruta. Los Roles BGP y OTC comunican expectativas de relación. La política de estilo Peerlock restringe las rutas que involucran redes protegidas. Los límites de prefijo máximo detectan cambios de escala. El monitoreo compara el comportamiento observado con las líneas base. Cada uno captura un subconjunto diferente de fallas.

La observación es tanto una función de control como de evidencia

La decisión del observador de APNIC de no rechazar rutas inválidas puede parecer contraria a la política defensiva normal. En un sistema de medición, sirvió un propósito diferente. Al retener anuncios que una red de producción podría descartar, el observador preservó evidencia de lo que se estaba emitiendo y propagando. [1]

Esa función de evidencia es esencial. Si cada punto de vista público rechazara las mismas rutas antes de registrarlas, la comunidad de enrutamiento podría saber que la defensa funcionó localmente pero perdería visibilidad de los anuncios incorrectos en sí mismos. Una alimentación deliberadamente no validadora puede exponer el origen, los prefijos, la sincronización y el patrón de retiro necesarios para comprender el evento.

Las redes de producción y los sistemas de medición tienen, por lo tanto, objetivos válidos diferentes. Un operador de producción puede rechazar rutas inválidas para proteger el tráfico y reducir la propagación. Un monitor puede retenerlas en una vista analítica aislada para hacer observables las anomalías. La elección del monitor no es evidencia de que las redes de producción deban aceptar las rutas.

Múltiples superficies de observación mejoran la confianza. ARIN RDAP proporciona contexto de registro para AS22773. [4] RIPEstat puede proporcionar contexto de ASN y enrutamiento independiente. [5] Cloudflare Radar ofrece otra vista de enrutamiento. [6] APNIC Labs ofrece cobertura ROA y contexto de comportamiento RPKI. [2][3] NIST describe una metodología para el monitoreo de RPKI. [7] Sin embargo, los recuentos y la línea de tiempo específicos del evento provienen del análisis de APNIC, y los paneles actuales no pueden reemplazar ese registro histórico.

Un diseño de monitoreo responsable preserva tanto las actualizaciones de rutas como los datos de autorización utilizados para clasificarlas. Registra la identidad del colector, la política, la base del reloj y la frescura de los datos. Distingue las rutas recibidas de las rutas seleccionadas. También retiene suficiente información para recomputar el resultado cuando cambia el software de validez o los datos de origen.

El mismo diseño debería soportar alarmas rápidas. Un nuevo origen para miles de prefijos es un evento observable. Los titulares de recursos pueden monitorear su propio espacio de direcciones en busca de orígenes no autorizados. Un operador de origen puede monitorear su conjunto anunciado en busca de crecimiento inesperado. Los vecinos pueden monitorear actualizaciones aceptadas y rechazadas. Los servicios independientes pueden comparar vistas y alertar cuando la propagación cruza límites esperados.

El registro proporcionado no muestra quién detectó la anomalía de AS22773 primero o si la observación externa precedió a la detección interna. Ese hecho afectaría materialmente el análisis de responsabilidad. Si Cox detectó el evento a partir de sus propios controles semánticos, la evidencia apoyaría la observabilidad interna. Si los externos lo detectaron primero, el caso para un monitoreo más fuerte del lado del origen sería más directo. El registro actual deja esa secuencia desconocida.

La responsabilidad sigue a cinco propietarios de control

El evento puede asignarse entre cinco propietarios prácticos sin pretender que cada uno tuviera igual poder.

Cox y AS22773 controlaron el origen y la exportación.Esto incluye qué rutas ingresaron a un conjunto originado o redistribuido, qué políticas las hicieron elegibles para sesiones externas, cómo se revisaron los cambios, cómo se detectó el crecimiento anómalo, cómo se ejecutaron los retiros y qué divulgó la empresa después. El origen observado convierte esta en la superficie principal de prevención y explicación.

Los titulares de recursos controlaron la precisión de la autorización.Sus ROA permitieron a las redes validadoras identificar la mayoría de los orígenes de AS22773 como inválidos. También controlaron si los prefijos no cubiertos permanecían fuera de esta capa. Su responsabilidad es mantener la autorización alineada con los arreglos de enrutamiento legítimos y preservar la evidencia de cambios.

Los pares y proveedores de tránsito controlaron la aceptación y la propagación.Cada red eligió si validar, si rechazar rutas inválidas, qué filtros de prefijos y ruta aplicar, qué umbrales hacer cumplir y si exportar una ruta recibida a otros. Sus elecciones determinaron el alcance del evento más allá del origen.

Los vendedores e implementadores de estándares controlaron las salvaguardas disponibles.El comportamiento del enrutador, el lenguaje de políticas, la integración de validación, las comprobaciones de origen efectivo, los Roles BGP y el soporte de OTC moldean lo que los operadores pueden hacer cumplir de manera confiable. La disponibilidad no es implementación, y la implementación no es configuración correcta. El registro público no establece ninguna de las dos para Cox.

Los monitores independientes controlaron la observabilidad pública.Sus alimentaciones de rutas, instantáneas de autorización y métodos analíticos determinan si las afirmaciones de contención pueden probarse. Un monitor puede mostrar que una ruta llegó y cómo se clasificó en ese punto de vista. No puede proporcionar el desencadenante interno de Cox ni el resultado del tráfico.

Esta asignación evita dos errores comunes. El primero es la simplificación de una sola parte, en la que cada aceptación posterior se trata como una acción del origen. Las redes toman decisiones de política independientes, por lo que el control de la propagación es compartido. El segundo es la dilución de la responsabilidad, en la que el control compartido se convierte en deber de nadie. Los vecinos de Cox podían contener un error, pero solo Cox controlaba si AS22773 lo emitía.

La carga de la evidencia debe seguir esos poderes. Cox podría divulgar evidencia de exportación prevista y corrección. Los titulares de recursos y los servicios RPKI podrían preservar el historial de autorización. Los vecinos podrían divulgar datos agregados de rechazo y propagación. Los vendedores podrían documentar las salvaguardas admitidas y el comportamiento probado. Los monitores podrían publicar observaciones reproducibles. Ningún actor necesita acceso al sistema interno de todos los demás actores para probar la parte que controló.

La divulgación debería hacer reproducible el resultado de control

Una divulgación sólida posterior al evento comenzaría con el conjunto de rutas observado y separaría el hecho de la inferencia. Identificaría cuántos prefijos adicionales se originaron, qué contextos de exportación estuvieron involucrados, cuándo el operador detectó el cambio por primera vez y cuándo comenzaron las acciones correctivas. Reconciliaría sus marcas de tiempo internas con los tiempos de recepción y retiro externos.

La siguiente sección identificaría el desencadenante sin exagerar la culpa. Una regla de redistribución, un cambio de automatización, una entrada de sesión de cliente, una acción de mantenimiento o una configuración humana son todas categorías posibles. El registro proporcionado no establece una. Una divulgación debería nombrar la ruta real y explicar por qué la revisión existente o las barreras de protección no la detuvieron.

La evidencia de control debería seguir. El operador podría mostrar que la política reparada produce solo un conjunto de prefijos aprobado, que los orígenes efectivos se verifican antes de la exportación, que un gran aumento en el conjunto de rutas desencadena una parada, y que el despliegue escalonado impide que un cambio equivalente llegue a todas las sesiones externas. Los resultados de las pruebas son más útiles que una declaración general de que los procedimientos mejoraron.

La evidencia de contención debe permanecer separada. Cox podría solicitar informes agregados de vecinos directos que muestren el rechazo inválido y cualquier aceptación residual. Los colectores independientes podrían reproducir el evento. Los datos ROA históricos podrían reproducir las clasificaciones de 4.644 y siete. Estos registros cuantificarían lo que los controles externos lograron sin reescribirlos como prevención del lado del origen.

La evidencia de impacto también debe mantenerse acotada. La telemetría de tráfico podría mostrar si los paquetes siguieron alguna ruta errónea. Los registros de servicio podrían mostrar si la alcanzabilidad o el rendimiento cambiaron. Las redes afectadas podrían informar incidentes. En su ausencia, el operador no debe implicar que un ROV exitoso significa que no ocurrió ningún efecto, y los críticos no deben reclamar una interrupción simplemente porque se observó una fuga.

Finalmente, la remediación debe vincularse a pruebas de recurrencia. Un retiro de ruta finaliza el evento visible. No prueba que la condición responsable no pueda repetirse. Un relato duradero identificaría el control agregado, el escenario utilizado para probarlo, el alcance del despliegue y la métrica continua que revelaría una regresión.

No se incluye dicha divulgación de Cox en el registro proporcionado. Esa ausencia no prueba que Cox no investigara o reparara el problema internamente. Significa que la evidencia pública no puede evaluar esas acciones. La responsabilidad se detiene en el límite de lo que se puede mostrar.

Mapa de evidencia y límites de las afirmaciones

El registro fuente respalda diferentes afirmaciones con diferentes fortalezas. Mantener esos roles separados evita que un documento de estándares o un panel actual se use como prueba del evento.

Ref.	Función de la evidencia	Uso admitido	Límite
[1]	Análisis del evento de APNIC	Fecha, origen observado, recuentos de rutas, línea de tiempo de dos oleadas, observador no validador y comparación de contención inválida	Un punto de vista analítico no prueba la aceptación global, el resultado del tráfico, el desencadenante interno de Cox ni la remediación
[2]	Panel ROA de APNIC Labs	Contexto de cobertura ROA para AS22773, incluida la cifra entonces actual del 95.06 % reportada con el análisis	Un panel cambiante no es una instantánea histórica completa de cada prefijo filtrado
[3]	Vista RPKI de APNIC Labs	Contexto sobre el comportamiento RPKI medido asociado con AS22773	El comportamiento actual no puede probar la política el 1 de mayo de 2025
[4]	RDAP de ARIN	Contexto de registro de ASN para AS22773	La identidad del registro no prueba la causa operativa ni la intención
[5]	Visión general AS de RIPEstat	Contexto independiente de enrutamiento y ASN	Los datos de visión general actual no reconstruyen la propagación del evento
[6]	Vista de enrutamiento de Cloudflare Radar	Contexto de enrutamiento independiente adicional	Un panel presente no es un mapa de aceptación vecino por vecino histórico
[7]	Metodología de monitor RPKI del NIST	Cómo la medición de validación RPKI depende de los datos y la metodología	La metodología no es prueba específica del evento
[8]	Guía práctica de integridad de enrutamiento del NIST	Arquitectura ROV y clases de daño general asociadas con orígenes no autorizados	El riesgo general no prueba una interrupción, desvío o pérdida de Cox
[9]	RFC 4271	Línea base del protocolo BGP	El intercambio BGP por sí solo no establece la autorización de origen
[10]	RFC 6483	Semántica de validación ROA	La validación de autorización no establece la ruta completa ni la intención operativa
[11]	RFC 6811	Validación de origen de prefijo BGP	La validación de origen no reemplaza los controles de relación y ruta
[12]	RFC 7908	Taxonomía de fugas de rutas	La taxonomía no identifica el desencadenante interno específico en AS22773
[13]	RFC 8893	Validación de origen del lado de exportación y control de origen efectivo	El estándar no prueba que Cox implementara o configurara correctamente el mecanismo
[14]	RFC 9234	Roles BGP y salvaguardas Solo-para-Cliente	La disponibilidad en un estándar no prueba la implementación en las sesiones del evento
[15]	Guía de filtrado de MANRS	Filtrado de prefijos y AS-path como controles del operador	La guía no establece el cumplimiento histórico por parte de Cox o un vecino
[16]	Marco del Observatorio MANRS	Conceptos de medición de fugas de rutas y habilitadores de propagación	Un marco de medición no asigna culpa legal específica del evento
[17]	Investigación de Peerlock	Evidencia de que las defensas orientadas a la ruta pueden restringir la propagación de fugas	La investigación sobre implementación y efecto no muestra que Peerlock se usara en este evento

Este mapa conduce a una jerarquía clara. La fuente [1] contiene los hechos del evento. Las fuentes [2] a [7] proporcionan medición, identidad y contexto, con límites temporales. Las fuentes [8] a [17] explican la arquitectura de control, los estándares y las defensas disponibles. Ninguna de las últimas puede sustituir una autopsia de Cox o una reconstrucción del evento con múltiples colectores.

Evidencia que cambiaría el análisis

Varios tipos de nueva evidencia podrían alterar materialmente la conclusión.

Una autopsia de Cox podría identificar el desencadenante, la ruta de política responsable, la fuente de detección, la secuencia de retiro y la reparación. Podría fortalecer la conclusión de que el evento fue accidental, o mostrar que algunas rutas se generaron intencionalmente en un contexto acotado. También podría revelar que una categoría de control asumida no estuvo involucrada.

Una reproducción con múltiples colectores podría cuantificar la propagación real. Podría mostrar que las rutas llegaron a muchas redes no validadoras, o que la aceptación fue mucho más limitada de lo que sugiere la recepción de un observador. Los registros de vecinos directos podrían identificar dónde funcionó el rechazo inválido y dónde no.

Las instantáneas ROA históricas podrían reproducir o revisar las clasificaciones de 4.644 inválidas y siete no cubiertas. Debido a que los datos de autorización cambian, un archivo limitado en el tiempo es más probatorio que una consulta actual. Cualquier revisión de esos recuentos cambiaría el límite de contención medido.

La telemetría de tráfico, el monitoreo de servicios o las declaraciones de redes afectadas podrían probar o refutar el daño visible para el usuario. La evidencia de que el tráfico siguió las rutas adicionales movería el análisis más allá de la exposición de la integridad del enrutamiento. La evidencia de que las rutas nunca fueron seleccionadas estrecharía el impacto. Ninguno de los dos resultados está disponible aquí.

Finalmente, la evidencia de que las rutas fueron autorizadas, originadas deliberadamente o confinadas a un entorno de prueba acotado desafiaría la caracterización de fuga en sí. El patrón actual hace probable una exportación no intencionada, pero la probabilidad no es un sustituto de la evidencia interna.

Hasta que aparezca uno de esos registros, la conclusión disciplinada es estable. Se observó que AS22773 originaba 4.651 rutas IPv4 adicionales. Casi todas tenían un desajuste de autorización que un hablante que rechaza inválidos podría hacer cumplir. El evento demuestra la capacidad de contención RPKI material y el valor de los ROA precisos, mientras deja sin resolver el alcance global, el efecto del tráfico, el desencadenante, la intención y la reparación.

La contención es la prueba de una capa, no la prueba de un sistema

El evento del 1 de mayo proporciona a los operadores de red una rara comparación medible. El observador no validador preservó miles de rutas. Los datos RPKI clasificaron 4.644 de ellas de una manera que permitió a las redes validadoras rechazarlas localmente. Esa es una fuerte evidencia de que la autorización de origen puede convertir un error de enrutamiento en una condición de política contenible.

No es evidencia de que RPKI valide la ruta completa, que todas las redes rechazaron los anuncios, que las siete rutas no cubiertas fueran inofensivas, o que los controles de origen y exportación puedan delegarse a los vecinos. Tampoco prueba una interrupción del cliente, interceptación, pérdida o violación regulatoria.

El resultado de responsabilidad sigue al control. Cox controló lo que AS22773 originó y exportó. Los titulares de recursos controlaron la precisión de la autorización. Los vecinos controlaron la aceptación y la propagación. Los vendedores controlaron las salvaguardas utilizables. Los monitores controlaron la evidencia independiente. Cada capa puede probar su propia acción, y ninguna capa puede usar el éxito de otra para borrar su deber.

El cierre más creíble sería, por lo tanto, medible: un inventario de prefijos previstos, semántica de exportación probada, alarmas de origen anómalo, despliegue escalonado, datos de rechazo de vecinos, instantáneas de autorización históricas, tiempos de retiro reconciliados y una explicación pública de la causa y la reparación. La contención RPKI ya ha mostrado lo que una capa puede probar. La pregunta sin respuesta es si los otros propietarios de control pueden producir evidencia de igual precisión.

Fuentes

Acceso verificado: 2026-07-25