AS7007 de 1997: el filtrado de rutas como prueba deresponsi

Resumen

Límite del incidente congelado:Este artículo examina las rutas originadas por AS7007 el 25 de abril de 1997 y la posterior perturbación de alcanzabilidad resultante. No fusiona ese hecho con fugas de rutas posteriores, secuestros maliciosos o fallos no relacionados en intercambios con nombres parecidos. Los registros contemporáneos de NANOG muestran que los operadores veían su propio espacio de direcciones como rutas más específicas con AS7007 como origen. [3][4]
Reconstrucción técnica delimitada:Una cuenta posterior de APNIC describe rutas eBGP sin clases que entran en un sistema, se redistribuyen en RIPv1, pierden información de longitud de prefijo y regresan a BGP como rutas desagregadas con información de origen reescrita. [1] Es una reconstrucción explicativa sólida, no una licencia para inventar una secuencia interna de comandos exacta.
Por qué ganaron esas rutas:El encaminamiento de Internet usa coincidencia por prefijo más específico. Una ruta más específica puede atraer tráfico antes de que muchos atributos de ruta BGP sean comparados. Las rutas filtradas por AS7007, por ello, crearon una realidad operativa que chocó con la titularidad de recursos y la información de origen esperada.
La responsabilidad sigue al control:AS7007 controlaba la redistribución, la política de exportación, la validación de cambios, la monitorización y la retirada. Sus proveedores ascendentes controlaban filtros de cliente, límites de prefijo y propagación. Los peers de entrada controlaban su propia política de aceptación y respuesta de emergencia. Los usuarios finales podían reportar fallos, pero no reparar el estado de rutas interdominio.
La evidencia registral no equivale a aplicación:Los registros ASN, de direcciones, IRR y los posteriores de RPKI pueden conservar evidencia sobre los titulares esperados y orígenes autorizados. Los enrutadores aún actúan según las rutas y políticas cargadas en los sistemas en ejecución. El incidente es, por ello, un ejemplo claro de primacía del código en ejecución: la autoridad escrita importa solo cuando la política operativa la aplica.
Los controles modernos son por capas:La validación de origen de RPKI, política explícita de importación y exportación, BGP Roles, filtrado de cono de cliente, límites de prefijo, monitorización independiente y rollback probado cubren rutas de fallo diferentes. Ningún mecanismo debería presentarse como una cura retrospectiva universal.
La recuperación debe demostrarse:Desconectar o corregir el enrutador de origen no es el final de la responsabilidad. Los operadores necesitan evidencia de retiradas, limpieza de rutas obsoletas, normalización de tablas de ruta, coordinación entre peers y restablecimiento de reenvío desde múltiples puntos de observación.

El límite del evento es el 25 de abril de 1997

Una historia técnica con rendición de cuentas empieza congelando el evento. El 25 de abril de 1997, los operadores de Internet reportaron un conjunto extraordinario de rutas más específicas asociadas a AS7007, operada por MAI Network Services. Los mensajes de NANOG del día aportan evidencia contemporánea de lo que vieron los operadores: bloques de direcciones que se esperaba que se originaran en otro lugar aparecieron en prefijos más pequeños con AS7007 como origen, y el tráfico siguió esos anuncios por rutas que no podían transportarlo correctamente. [3][4]

El evento suele describirse más tarde como el "incidente AS7007" o una fuga de rutas temprana de Internet de gran impacto. Esa etiqueta es útil solo si permanece unida a la evidencia. No debe usarse como abreviatura de cualquier error de enrutamiento de la época, ni suponer intención hostil. El registro público más sólido respalda un fallo de propagación accidental con efectos severos. No respalda la afirmación de que AS7007 pretendiera interceptar tráfico o declarara con conocimiento propia titularidad sobre todos los bloques afectados.

Las historias técnicas posteriores suelen describir miles de rutas /24 y una interrupción aguda de aproximadamente dos horas. La retrospectiva de APNIC aporta una cifra aproximada de 6.000 anuncios /24 y reconstruye cómo el comportamiento de enrutamiento classful pudo haber transformado una tabla externa amplia en rutas más específicas. [1] El catálogo de incidentes de Secure Routing también registra el suceso como un fallo de enrutamiento histórico.

[2] Estas fuentes posteriores ayudan a ordenar la cronología, pero los mensajes operativos contemporáneos siguen siendo importantes porque muestran el estado de ruta visible externamente mientras el incidente se desarrollaba.

La cifra exacta de anuncios, el inicio y fin exactos observables en cada lugar y la configuración interna completa no quedan establecidos por un único documento público. Las vistas BGP dependen del punto de observación. Una ruta puede aparecer primero en un peer y después en otro, permanecer obsoleta en una tabla tras haberse retirado en otra, o quedar suprimida por un filtro que otra red no tenga. Por ello una versión defendible atribuye estimaciones numéricas y evita convertir la vista de un solo colector en un reloj universal.

El rol de la Florida Internet Exchange exige cautela. Narrativas posteriores a veces conectan el evento con infraestructura de ese intercambio o usan el nombre como marcador de localización conveniente. La evidencia pública revisada aquí no justifica atribuir el fallo completo al intercambio en sí. La tesis de responsabilidad descansa en la transformación de ruta, la exportación, la aceptación de peers y la recuperación. No requiere una alegación no sustentada sobre la propiedad del incidente por parte de una sola instalación.

Estas fronteras importan porque el diagnóstico orienta la remediación. Si el evento se llama erróneamente como un secuestro deliberado, la respuesta puede centrarse en credenciales y en detección de origen malicioso. Si se reduce a una caída genérica, la respuesta puede enfocarse solo en disponibilidad. La evidencia, en cambio, apunta a una transformación de política de rutas que escapó de una frontera interna y fue aceptada a través de varias fronteras externas.

El BGP sin clases encontró un protocolo interior classful

El mecanismo técnico es inusual y requiere explicación cuidadosa. BGP transmite información de alcanzabilidad de capa de red entre sistemas autónomos. Las rutas modernas de BGP incluyen un prefijo y una longitud, como /16 o /24, además de atributos de ruta que los operadores usan en selección y política de exportación. RFC 4271 describe el protocolo base y el proceso de decisión. [8]

RIPv1 se diseñó para un modelo classful anterior. No llevaba máscaras de subred en los anuncios de ruta. En una interpretación classful, una dirección podía tratarse según clases históricas amplias de red en lugar de la longitud de prefijo explícita presente en una ruta BGP classless. Cuando las rutas pasan entre protocolos con modelos de información distintos, la redistribución no es una copia neutra. Es una transformación.

La reconstrucción de APNIC describe rutas aprendidas por eBGP classless que se redistribuyeron en RIPv1. Dado que RIPv1 no podía preservar las longitudes classless originales, las rutas se representaron de forma que provocó desagregación. Al redistribuirse esas rutas de nuevo a BGP, los anuncios resultantes aparecieron como muchos prefijos más específicos y la información de AS-path externa original ya no se conservó igual. [1]

Ese análisis explica dos observaciones a la vez. Primero, explica el volumen de anuncios /24. Un número menor de rutas más amplias puede producir muchos prefijos más estrechos cuando la semántica de prefijo se transforma. Segundo, explica por qué AS7007 apareció como origen para espacio de direcciones que los operadores asociaban con otras redes. Si la información externa de camino se elimina durante la redistribución y la ruta se reintroduce en BGP, el sistema autónomo que la reinyecta puede volverse el origen visible.

El registro público no revela cada versión de software, objeto de enrutador, comando de redistribución, route-map o acción administrativa. Sería irresponsable convertir la reconstrucción en una transcripción terminal fabricada. La evidencia respalda una clase de mecanismo: la información se perdió o transformó al cruzar una frontera de protocolo, y las rutas transformadas se exportaron al BGP interdominio.

Esta distinción es importante para la responsabilidad. Una revisión posterior no debe detenerse en que "RIP era obsoleto" o que "la redistribución era peligrosa". Debe preguntar quién autorizó la frontera de protocolo, qué atributos se esperaba que sobrevivieran, qué conjunto de rutas de prueba se validó, qué invariant de exportación debió rechazar el resultado y qué alarma debía dispararse cuando cambia volumen, prefijo y origen.

La traducción de protocolo es un riesgo de infraestructura recurrente. Ambos protocolos pueden funcionar según su diseño mientras la composición viola la intención del sistema. Una ruta válida dentro de una representación puede volverse materialmente distinta al importarse en otra. El propietario del control debe validar la salida de la transformación, no solo la sintaxis de cada lado.

Las rutas más específicas convirtieron información incorrecta en realidad de reenvío

La selección de BGP importa, pero la especificidad de reenvío llega primero. Los enrutadores envían paquetes mediante el prefijo que coincide más específicamente en la tabla de reenvío. Una ruta /24 coincide con un rango más estrecho de direcciones que un /16 de cobertura. Cuando ambos existen, el tráfico de direcciones dentro de /24 sigue la ruta /24 aunque la ruta /16 cubridora siga disponible.

Este comportamiento facilita ingeniería de tráfico y multihoming. También hace poderosa la desagregación accidental. Si AS7007 originó miles de rutas más específicas, esas rutas podían atraer tráfico lejos de las rutas de cobertura legítimas. Internet no necesitaba creer que AS7007 poseía legalmente el espacio de direcciones. Solo necesitó que suficientes enrutadores aceptaran los anuncios e instalaran los caminos más específicos.

La distinción entre titularidad y alcanzabilidad es central. Los registros de direcciones pueden anotar qué organización recibió un bloque. Los registros de enrutamiento pueden anotar la política prevista. Sistemas RPKI posteriores permiten que un titular autorice un ASN de origen para un prefijo. Ninguno de esos registros cambia por sí solo una tabla de reenvío. La red en ejecución sigue rutas aceptadas bajo la política configurada.

Durante el incidente, los operadores reportaron rutas para sus propias redes con AS7007 como origen. [3][4] Si el tráfico siguió esas rutas más específicas hacia una red incapaz de entregarlo a los destinos previstos, el resultado fue un gran agujero negro. Algunas rutas pudieron comportarse de forma distinta porque redes aplicaron filtros, prefirieron otras rutas o aún no habían recibido los anuncios. Esa variación no debilita el mecanismo; muestra que el alcance del incidente quedó determinado por la política distribuida.

El término "fuga" es más preciso que "secuestro" en este caso. RFC 7908 aportó después una taxonomía para fugas de rutas como propagación fuera del alcance previsto. [9] El evento de 1997 antecede ese estándar, y su desagregación particular no necesita forzarse en una categoría moderna para que la cuestión de responsabilidad siga clara. Las rutas escaparon del límite operativo previsto, llevaron especificidad y origen engañosos, y se propagaron con suficiente alcance para perturbar la alcanzabilidad.

Algunas discusiones de seguridad tratan cualquier ruta con origen incorrecto como evidencia de un atacante. Esa inferencia no está respaldada aquí. Los controles operativos deben detectar el estado de ruta perjudicial con independencia de intención. Un límite de número de prefijos, una comprobación de origen autorizado o una comparación de conjunto de exportación no tienen que decidir si el operador fue negligente, comprometido o malicioso antes de bloquear el anuncio.

Por eso la evidencia de ruta es valiosa. Permite a los investigadores describir qué afirmó y aceptó la red sin especular sobre motivaciones. La responsabilidad sigue los sistemas y organizaciones que controlaron esas afirmaciones y decisiones de aceptación.

La responsabilidad estaba distribuida, pero no era sin titular

El enrutamiento interdominio está descentralizado. Eso no significa que la responsabilidad desaparezca. Significa que la responsabilidad debe asignarse a los controles que cada organización podía operar.

AS7007 controlaba la frontera de redistribución interna. Controlaba si las rutas BGP externas entraban en un protocolo interior, si se preservaban atributos y semántica de prefijo, si las rutas transformadas podían regresar a BGP y qué anuncios se exportaban a los proveedores ascendentes. También controlaba aprobación de cambios, despliegue, monitorización, rollback y comunicación de incidentes.

Los proveedores ascendentes que aceptaron rutas de AS7007 controlaban una frontera distinta. Podían mantener una lista de prefijos esperados de cliente, rechazar orígenes fuera de un conjunto autorizado, limitar la cantidad de prefijos, acotar la especificidad aceptada o exigir excepción para anuncios inusuales. También controlaban si las rutas aceptadas se exportaban a peers y clientes.

Peers de entrada e redes descendentes controlaban sus propias políticas. Algunas pudieron tener filtros que contenían partes del evento. Otras probablemente confiaron de forma amplia en la relación ascendiente. Su responsabilidad no era idéntica a la del originador, porque no crearon las rutas transformadas. Pero la aceptación de rutas sigue siendo un acto operativo.

Operadores de servicios críticos y redes empresariales controlaban la resiliencia alrededor del sistema de enrutamiento. Podían monitorizar el estado externo de rutas, usar proveedores diversos, retener comunicación fuera de banda y probar si la supuesta diversidad de caminos compartía las mismas dependencias ascendentes. Esos controles podían reducir impacto o mejorar la detección, pero no corregir el estado global de rutas en la fuente.

Los usuarios finales y clientes ordinarios tenían casi nulo control práctico. Podían reintentar, cambiar de red de acceso donde hubiera alternativas o reportar fallos. No podían inspeccionar cada camino BGP, cambiar filtros de proveedor ni forzar retiradas. Culpar a los usuarios por no reencaminar alrededor del evento confunde exposición con responsabilidad.

La división de control sugiere un hallazgo por capas:

La red de origen tenía el deber principal de evitar que una transformación interna se convirtiera en un reclamo externo.
Los ascendentes directos tenían un fuerte deber de contención porque conocían la relación con cliente y podían definir rutas esperadas.
Otras redes tenían un deber general de mantener políticas de importación defendibles y monitorizar anomalías.
Los operadores de servicios tenían un deber de continuidad de entender dependencias de rutas y detectar fallos externos.
Los proveedores de evidencia pública tenían un rol de observación, no de control operativo de producción.

Este modelo evita dos errores. Evita colocar todas las consecuencias en un solo ingeniero que pudo ejecutar un cambio dentro de un sistema débil. También evita afirmar que Internet está demasiado descentralizado para rendir cuentas. La pregunta relevante es siempre el control práctico: quién podía prevenir, contener, detectar, retirar o verificar.

El modelado de exportación debe probar el conjunto de rutas generadas

Una regla escrita que diga "no anunciar prefijos de otras redes" no basta. El sistema necesita una representación verificable por máquina del conjunto esperado de exportación y una comparación frente a las rutas que la configuración realmente genera.

Para un cliente o red de borde, un modelo de exportación puede definir:

los prefijos que la red está autorizada y prevista para originar;
la cantidad máxima de rutas en estados normal y de emergencia;
longitudes de prefijo permitidas;
qué rutas pueden anunciarse hacia cada relación;
si rutas aprendidas de cliente, peer y proveedor pueden re-exportarse;
qué AS paths y comunidades son esperados;
qué excepciones existen, quién las aprobó y cuándo expiran.

La configuración generada debería probarse antes del despliegue. Una prueba no debe limitarse a confirmar que existe una route-map. Debe introducir rutas representativas en la política y examinar los anuncios resultantes. Si rutas classless atraviesan una representación classful o con pérdidas, la prueba debe comparar longitud, origen y trayecto antes y después de la transformación.

El evento AS7007 ilustra un invariante de alto valor: un proceso de enrutamiento no debe exportar una ruta más específica para un prefijo externo salvo que esa ruta esté explícitamente autorizada. Otro invariante podría limitar la diferencia entre el número esperado y el generado. Un salto desde un conjunto ordinario de anuncios de cliente a miles de /24 debería detener el despliegue aunque cada ruta sea sintácticamente válida.

Los límites de prefijos aportan una segunda capa. Un proveedor ascendente puede configurar un máximo de prefijos aceptados desde un cliente. Un umbral razonable incluye margen operativo pero permanece lo suficientemente bajo como para detectar una fuga mayor. Ese umbral debería ser específico por relación. Un proveedor de tránsito, una red de contenidos y un cliente de acceso pequeño tienen conjuntos de prefijos normales distintos.

Los límites por sí solos no bastan. Una fuga puede causar daño grave y, aun así, quedar por debajo de un máximo generoso. Un cliente puede anunciar la cantidad esperada de rutas pero con prefijos erróneos. Por ello los límites deben combinarse con autorización de prefijo y origen.

Los filtros de cliente pueden derivarse de registros, contratos, IRR y datos RPKI, pero esas fuentes tienen huecos. Un sistema defendible registra qué fuente autorizó cada ruta, cuándo se actualizó y cómo se gestionan conflictos. Las excepciones de emergencia deberían ser explícitas y temporales, no atajos invisibles.

RFC 7454 aporta guía operativa de seguridad para BGP, incluyendo filtrado y límites de prefijo. [13] MANRS presenta prácticas relacionadas como acciones de operador. [14] BITAG y NIST también describen controles de seguridad de enrutamiento y realidades de despliegue. [15][16] Estos documentos deben informar un sistema de control, no reemplazar la evidencia de que el control está activo en la sesión relevante.

La evidencia más fuerte es un registro de pruebas: el conjunto de rutas esperado, el generado, la decisión de política para cada diferencia, la lista de excepciones aprobadas, el resultado canario y la observación de ruta en vivo tras el despliegue.

La doctrina de Heng.lu separa registros y ejecución

El incidente AS7007 es un caso directo de control de red para la doctrina de Heng.lu. Los recursos numéricos requieren unicidad, registros precisos, historial de transferencias, metadatos de seguridad y continuidad operativa. Esos registros son esenciales, pero el registro es un libro mayor y custodio de evidencia, no un controlador soberano de enrutadores en ejecución.

Un registro ASN puede identificar AS7007. Los datos del registro de direcciones pueden identificar titulares esperados de los prefijos que aparecieron bajo AS7007. Un objeto IRR puede describir la política de origen prevista. Una ROA puede autorizar un ASN para originar un prefijo. Estas son superficies de evidencia.

La capa de realidad es la ruta aceptada por un enrutador e instalada para reenvío. El 25 de abril de 1997, la verdad operacional no era solo lo que decían los registros. Era que rutas más específicas con AS7007 como origen fueron aceptadas y propagadas, y el tráfico las siguió.

Esto no vuelve irrelevantes los registros. Sin registros, un peer tiene evidencia menos fiable para construir filtros y un investigador menos evidencia para identificar anomalías. El punto es que un registro se vuelve protección operativa solo cuando la política lo consume, las excepciones son controladas y el despliegue se verifica.

La primacía del código en ejecución también se aplica a procedimientos escritos. Un procedimiento puede exigir revisión entre pares y filtrado de prefijos. Si una configuración generada elude el filtro, el sistema en ejecución define el resultado. Una auditoría que revise solo el procedimiento reportará un control que no constriñó el incidente.

La doctrina se traduce en tres requisitos prácticos:

Libro mayor exacto:Los registros de recursos y política deben identificar prefijos, orígenes y operadores responsables previstos.
Política aplicada:Enrutadores y route servers deben convertir esa evidencia en decisiones de importación y exportación.
Continuidad operacional:Monitorización y rollback deben mostrar que el estado erróneo puede eliminarse y restaurarse la alcanzabilidad correcta.

El artículo no convierte esos principios en una defensa de un registro, gobierno o producto concreto. La evidencia es más estrecha. El incidente muestra que los registros de unicidad y titularidad no previenen daños cuando la política de enrutamiento acepta un estado operativo contradictorio.

Quitar la redistribución BGP, la especificidad de prefijo, el origen AS, los filtros de peer y la retirada de hechos destruiría la tesis del artículo. Por eso no se trata de una historia corporativa genérica con terminología de red añadida después. Es un análisis de responsabilidad de infraestructura de red.

RPKI, RFC 8212 y BGP Roles resuelven problemas distintos

Las discusiones modernas de seguridad de enrutamiento suelen preguntar si RPKI habría prevenido un incidente histórico. La respuesta responsable es condicional.

La validación de origen de ruta compara un prefijo observado y un ASN de origen con autorizaciones de origen de ruta (ROA). RFC 6811 define los estados de validación usados por enrutadores. [12] Si un prefijo tiene una ROA válida que autoriza otro origen y AS7007 anuncia una ruta más específica en conflicto, la ruta puede clasificarse como inválida, según cobertura del prefijo y longitud máxima.

Muchas reclamaciones de origen con estilo AS7007 habrían sido más fáciles de identificar y rechazar en un entorno RPKI totalmente cubierto y correctamente configurado. Esa es una mejora operativa relevante. No prueba que cada ruta del incidente de 1997 hubiera sido rechazada.

La cobertura importa. Una ruta sin una ROA de cobertura no se declara inválida solo porque un observador la considere sospechosa. Las configuraciones de longitud máxima también importan. Una autorización de cobertura puede hacer inválida una ruta más específica si supera la longitud permitida, pero una autorización demasiado amplia puede permitir especificidad perjudicial. La política de despliegue también importa porque una red puede calcular el estado de validación sin rechazar rutas inválidas.

La validación de origen tampoco reconstruye intención de relación. Una ruta con origen autorizado puede seguir filtrándose desde cliente a proveedor o peer en violación de la política de exportación esperada. RFC 7908 describe varias formas de fuga donde el origen puede ser legítimo pero la propagación es incorrecta. [9]

RFC 8212 cambia la postura por defecto de eBGP al exigir políticas explícitas de importación y exportación. [10] Eso reduce propagación accidental causada por un aceptar-todo implícito. No garantiza que una política explícita sea correcta. Un operador puede escribir una política permisiva, autorizar una transformación insegura o asociar el objeto de política equivocado.

RFC 9234 introduce BGP Roles y un atributo OTC para ayudar a identificar y prevenir ciertos fugas según relación. [11] Atiende propagación con conocimiento de relaciones. No sustituye validación de origen, pruebas de política generada, límites de prefijo o rollback.

Los enfoques por customer cone infieren o mantienen el conjunto de rutas esperadas de un cliente y sus descendentes. Los filtros tipo peerlock y control de rutas restringidas para grandes redes constriñen ciertos caminos. La investigación ha mostrado que despliegues parciales pueden aportar protección útil, aunque también exponen límites y complejidad operacional. [17]

La lección por capas es:

RPKI y validación de origen de ruta abordan el origen autorizado.
IRR y datos de registros apoyan los registros esperados de prefijos y políticas.
RFC 8212 exige políticas explícitas.
BGP Roles y OTC abordan prevención de fugas con conocimiento de relación.
Filtros de cono de cliente y ruta constriñen propagación.
Los límites de prefijo constriñen volumen.
El modelado de configuración detecta defectos de política generada.
Monitorización independiente detecta desviaciones en estado ejecutado.
Rollback y coordinación restauran servicio.

Tratar un solo control como respuesta completa genera una nueva brecha de responsabilidad. Los operadores deben declarar qué modos de fallo cubre un control, qué ocurre cuando faltan datos, cómo se revisan las excepciones y cómo se prueba el control contra una falla representativa.

La recuperación no terminó cuando se desconectó el enrutador de origen

La evidencia contemporánea más reveladora trata la recuperación. Una disculpa publicada en NANOG describió la dificultad para limpiar rutas erróneas incluso después de desconectar el enrutador de origen. [4] Esa observación convierte la recuperación de una narrativa de apagado simple en un problema de estado distribuido.

Las rutas BGP se propagan por muchos sistemas autónomos. Cuando el origen retira una ruta o cae una sesión, los vecinos procesan el cambio, actualizan sus caminos seleccionados y anuncian los cambios resultantes. Temporizadores, amortiguación de route flap, estado de sesión, comportamiento de implementación y política local pueden afectar la velocidad con que normalizan tablas.

La fuente original puede dejar de emitir rutas erróneas mientras información obsoleta permanece en otro sitio. Un peer puede retener temporalmente un camino, un route reflector puede procesar cambios a otro ritmo, o un operador puede necesitar reiniciar una sesión para limpiar estado inesperado. Informes públicos desde un punto de observación no pueden probar que todos los enrutadores convergieron.

Un registro de recuperación con responsabilidad debería incluir:

cuándo el origen dejó de generar o exportar las rutas erróneas;
cuándo cada ascendente directo observó las retiradas;
si las sesiones se reiniciaron y por qué;
si el amortiguamiento de route flap o mecanismos contra rutas obsoletas afectaron la limpieza;
cuándo los colectores dejaron de ver los orígenes erróneos;
cuándo los orígenes y rutas de cobertura legítimos recuperaron visibilidad esperada;
cuándo las pruebas de reenvío alcanzaron destinos previstos;
cuándo peers principales confirmaron tablas normalizadas;
qué rutas permanecieron anómalas y por cuánto tiempo;
quién declaró servicio restablecido y con qué evidencia.

El incidente también muestra por qué los planes de rollback necesitan validación del estado de rutas. Restaurar una configuración previa no basta si las rutas erróneas permanecen instaladas más allá de la fuente. Un checklist de rollback debe incluir retiradas esperadas, comparación de tablas y confirmación independiente.

El BGPStream de CAIDA vuelve accesibles datos históricos y en vivo de enrutamiento para análisis. [18] Los colectores de rutas son valiosos para confirmación independiente, pero son muestras. Un proceso de recuperación maduro combina datos internos de RIB y FIB, informes directos de peers, colectores públicos y pruebas de encaminamiento.

La comunicación de recuperación debe separar contención en la fuente de restauración global. "El enrutador se desconectó" es un hito de contención. "Todos los peers directos dejaron de ver las rutas erróneas" es un hito de propagación. "Puntos de observación independientes ya no ven las rutas y el reenvío es normal" es evidencia más cercana a la restauración.

Esa estructura evita cierres prematuros. También ayuda a que las organizaciones midan la parte de recuperación que controlan directamente y la parte que depende de coordinación.

La evidencia de rutas públicas es fuerte pero incompleta

El registro público de un evento de enrutamiento de 1997 es inusualmente útil, pero aún tiene límites. Los mensajes de NANOG aportan observaciones directas de operadores y una disculpa. [3][4] Los reportes contemporáneos capturan escala y sorpresa de la interrupción. [5] Cuentas técnicas posteriores explican la interacción de protocolos. [1][2][6] Las normas y guías describen los controles que los operadores pueden aplicar. [8]-[17]

Ninguna fuente pública revela toda la tabla de enrutamiento privada, diferencias de configuración, ticket de soporte o log de decisiones. La evidencia no puede identificar el primer dispositivo exacto que aceptó cada ruta ni el número exacto de usuarios afectados. Tampoco puede mostrar qué filtros actuaron silenciosamente y evitaron mayor propagación.

La reconstrucción histórica también sufre deriva terminológica. En 1997, los operadores describían el incidente con el lenguaje y herramientas disponibles entonces. Cuentas posteriores usan fugas de ruta, secuestro, desagregación y validación de origen con sentidos marcados por estándares posteriores. Un artículo riguroso no debe hacer parecer que un operador de 1997 seguía o violaba un estándar que aún no existía.

Los estándares modernos son lecciones para el diseño actual de control, no requisitos retroactivos de cumplimiento. RFC 4271 se publicó después del evento, aunque documenta el modelo maduro de BGP-4. RFC 7908, RFC 8212 y RFC 9234 llegaron mucho después. [8]-[11] Ayudan a explicar clases de fallo y capas de prevención, pero no prueban que AS7007 o sus ascendentes hubieran estado obligados contractualmente a desplegarlos en 1997.

La evidencia respalda varias conclusiones de alta confianza:

AS7007 originó una gran cantidad de rutas más específicas para espacio de direcciones asociado a otras redes.
El estado de ruta causó una disrupción de alcanzabilidad sustancial.
El evento fue accidental según el registro disponible.
La redistribución de interno a externo fue central en la reconstrucción técnica posterior.
La aceptación y propagación entre peers amplió el impacto.
La retirada y limpieza no fueron instantáneas.

Respalda varias conclusiones de confianza moderada:

La redistribución classless a classful explica de forma plausible la desagregación y el origen reescrito.
Un filtro directo de ascendente o un límite de prefijo podría haber contenido gran parte del conjunto de rutas.
Un modelado de exportación más sólido habría expuesto una diferencia mayor entre anuncios esperados y generados.

Quedan incógnitas importantes:

la secuencia de configuración exacta;
la topología completa de dispositivos y software;
el estado de filtros de cada peer directo;
la cronología completa del incidente;
la titularidad de decisión y aprobación;
el efecto total por red y geografía;
la remediación implementada tras el suceso.

La responsabilidad es más sólida cuando esos niveles de confianza permanecen visibles. Sobreactuar los alcances haría el artículo más fácil de criticar y menos útil como estándar de auditoría.

Una agenda verificable de remediación

El registro público no establece qué controles implementó MAI Network Services ni cada ascendente después del incidente. La respuesta correcta es definir evidencia que demostraría que ahora la ruta de fallo está controlada.

1. Congelar exportaciones esperadas

Para cada sesión eBGP, conservar un conjunto de exportación esperada versionado. El conjunto debe incluir prefijo, máxima especificidad, origen, restricciones de camino, relación y excepciones aprobadas. Debe generarse desde registros de autoridad más intención operacional explícita.

Evidencia: commit del repositorio, registro de aprobación, marcas temporales de fuentes de datos, propietario de excepción y vencimiento.

2. Probar transformaciones de protocolo

Cuando rutas se mueven entre BGP, un IGP, un sistema estático u otra representación, probar si la longitud de prefijo, origen, camino y atributos de política sobreviven como se prevé. Rechazar transformaciones con pérdidas a menos que el conjunto de rutas resultante esté explícitamente acotado.

Evidencia: rutas de entrada representativas, rutas de salida generadas, resultados de invariantes y pruebas negativas.

3. Comparar anuncios generados y esperados

Antes de desplegar, calcular la diferencia de rutas. Detenerse si el conjunto generado introduce prefijos no autorizados, más específicos no previstos, cambios de origen o incremento de recuento fuera del límite aprobado.

Evidencia: diff previo al despliegue y resultado de condición de parada.

4. Aplicar filtros directos de cliente

Los ascendentes deberían filtrar las rutas de cliente contra un conjunto esperado, aplicar límites de prefijo por relación y registrar cada excepción. Datos de registro y RPKI pueden informar el conjunto, pero conflictos no resueltos deberían fallar de forma segura o requerir revisión explícita.

Evidencia: política activa, pruebas de anuncios aceptados y rechazados, historial de refresco y lista de excepciones.

5. Desplegar política explícita de relación

Cada sesión eBGP debería tener política explícita de importación y exportación. Donde sea viable, BGP Roles y controles sensibles a relación deberían alinear la configuración con la relación operacional real. La configuración debería rechazar ausencia o inconsistencias de rol en lugar de aceptar implícitamente un valor amplio.

Evidencia: inventario de sesiones, mapeo de roles, asociación de política y prueba de conformidad.

6. Monitorizar desde fuera de la red

Monitorizar origen, especificidad, camino, volumen de ruta y alcanzabilidad desde puntos de vista independientes. Las alertas deben vincular anomalías de ruta con pruebas de reenvío para que los equipos distingan una actualización visible de un evento con impacto en usuarios.

Evidencia: consultas a colectores, cronología de alertas, resultados de sondas y vinculación de incidentes.

7. Definir paradas automáticas de despliegue

Un despliegue debe detenerse cuando el recuento de rutas, el origen inesperado, el volumen de más específicas, la visibilidad entre peers o la degradación de reenvío exceden un umbral definido. La parada no debería depender únicamente de que un humano vea quejas públicas.

Evidencia: política canaria, umbral, activador y parada ejecutada.

8. Ejecutar retirada y limpieza

Realizar pruebas seguras en laboratorio o entornos aislados que muestren que una ruta defectuosa se retira, convergen sesiones, se detecta estado obsoleto y las sondas independientes vuelven a normalidad. El ejercicio debe incluir comunicación entre peers y acceso fuera de banda.

Evidencia: marcas temporales de retiro en origen, recepción por peer, normalización de tablas y recuperación de reenvío.

9. Conservar evidencia del incidente

Retener actualizaciones de ruta, diferencias de configuración, entradas de modelado de política, registros de aprobación, alertas, comandos, mensajes entre peers y chequeos de recuperación. La sincronización temporal debe hacer secuenciable la cadena de evidencia.

Evidencia: paquete inmutable de incidente con hashes y controles de acceso.

10. Verificar remediación frente a la clase de fallo original

No cerrar la remediación con una afirmación genérica de mejora de monitorización. Recrear una representación segura de la transformación classless a classful o una desagregación no autorizada equivalente y mostrar dónde la cadena de control actual la detiene.

Evidencia: diseño de prueba, punto de fallo esperado, resultado observado y revisión independiente.

Esta agenda es deliberadamente neutral en cuanto a producto. No exige un proveedor, registro o servicio de seguridad particular. Exige que un operador demuestre que la política esperada es precisa, la política en ejecución la hace cumplir, las anomalías detienen despliegue y la recuperación es visible de forma independiente.

Las preguntas de gobernanza deben seguir la ruta

Los consejos, reguladores, compradores de servicio y auditores no necesitan operar BGP para hacer preguntas útiles. Deben seguir la ruta a través de la cadena de control.

Los consejos deberían preguntar qué cambios pueden alterar anuncios públicos, cómo se prueban exportaciones generadas, quién puede aprobar excepciones y qué tan rápido se puede ejecutar rollback. Deberían recibir resultados de ejercicios, no solo documentos de política.

Los proveedores transitivos deberían preguntar si los filtros de cliente derivan de evidencia actual, cuántas sesiones tienen límites de prefijo, qué sesiones aceptan excepciones amplias y si esas excepciones expiran. Un control aplicado a la mayoría de clientes puede dejar expuesto el sesión de mayor riesgo.

Compradores empresariales deberían preguntar si los proveedores duales son operativamente independientes, si la monitorización externa cubre prefijos críticos y si la comunicación del incidente distingue fallo de enrutamiento de fallo de aplicación. La diversidad contractual no es lo mismo que diversidad de ruta.

Los auditores deberían muestrear políticas de sesión reales, conjuntos de rutas generadas y observaciones de ruta. Deberían trazar un registro o evidencia de RPKI desde un registro o IRR hasta una decisión de enrutador y probar qué ocurre cuando los datos faltan o entran en conflicto.

Los reguladores deberían evitar definir la responsabilidad del enrutamiento como despliegue de una sola tecnología. Exigir la creación de ROAs puede mejorar la seguridad de origen, pero no demuestra filtrado consciente por relación, validación de cambios o recuperación. Las obligaciones basadas en evidencia pueden pedir que los operadores documenten controles adecuados a su rol y los prueben.

Los revisores de incidentes deberían separar causa raíz, condiciones contribuyentes, disparador, detección, respuesta y recuperación. "Error humano" no es causa raíz suficiente. No explica por qué el sistema generó miles de rutas inesperadas, por qué peers las aceptaron, por qué la monitorización no detuvo la propagación o por qué la limpieza siguió siendo difícil.

El objetivo de gobernanza no es hacer que cada cambio de ruta sea libre de riesgo. Es asegurar que las organizaciones con control práctico puedan mostrar cómo reducen, contienen y reparan el riesgo que su posición en la red crea.

La prueba de responsabilidad es la ejecución observable

El incidente AS7007 de 1997 sigue siendo importante porque condensa en un solo evento varias obligaciones de infraestructura de red. Una frontera interna de protocolo transformó información de ruta. La salida transformada cruzó una frontera externa de política. Rutas más específicas cambiaron la realidad de reenvío. Múltiples redes aceptaron y propagaron esos reclamos. La recuperación exigió retirada distribuida y coordinación.

El registro público no justifica una afirmación de intención maliciosa ni una secuencia exacta de comandos no documentada. Justifica, sí, una conclusión operacional fuerte: la titularidad esperada de recursos y la intención escrita de enrutamiento no constriñeron el estado de ruta en ejecución.

La responsabilidad estaba por capas. AS7007 controló la transformación y la exportación. Los ascendentes directos controlaron la aceptación y contención de cliente. Otras redes controlaron política de importación. Operadores de servicio controlaron monitorización y resiliencia externas. Los usuarios finales sufrieron consecuencias sin control de enrutamiento significativo.

Los mecanismos modernos mejoran el entorno de control solo cuando sus límites son explícitos. RPKI puede ayudar a rechazar orígenes no autorizados. RFC 8212 puede eliminar la postura implícita de eBGP. BGP Roles y OTC pueden ayudar a limitar fugas por relación. Los límites de prefijo pueden detectar volumen anómalo. Los filtros de cliente pueden limitar rutas esperadas. El modelado puede comparar exportaciones generadas con la intención. La monitorización y el rollback pueden contener y reparar fallos.

La doctrina de Heng.lu ofrece un estándar final conciso. Los registros y registros de política preservan evidencia responsable, pero no gobiernan el plano de reenvío. El código en ejecución, la política configurada y rutas aceptadas determinan lo que hace Internet. La continuidad operacional requiere que el estado erróneo pueda detectarse, eliminarse y verificarse de forma independiente.

Un registro de remediación creíble, por tanto, mostraría el conjunto de exportación esperado, pruebas de política generada, filtros de cliente directo, límites de prefijo, detección de anomalía en vivo, cronología de retiro, confirmación entre peers y recuperación de reenvío. Debería reproducir la clase de fallo original de forma segura y mostrar qué control la detiene hoy.

La pregunta duradera del 25 de abril de 1997 no es si los operadores de hoy saben que las fugas de rutas son peligrosas. Es si pueden probar que un conjunto transformado, no autorizado y altamente específico no cruza sus fronteras sin ser detectado, y si pueden probar la recuperación cuando eso ocurre. Esa es la prueba de responsabilidad en Internet que AS7007 dejó visible.

La fuga de AS7007 de 1997 convirtió el filtrado de rutas en una prueba de responsabilidad