Resumen

  • Un dominio interno envió muchos prefijos hacia el backbone de centros de datos. Todos llevaban una comunidad BGP asignada legítimamente a ese dominio y superaron la route-map de entrada; después, los routers de agregación agotaron la memoria y reiniciaron sus demonios de enrutamiento.
  • Daria Shantalova propone separar identidad del prefijo, autorización en cada frontera y comprobación continua del estado real de producción.
  • La presentación afirma que en meses se eliminaron casi todas las infracciones observadas, pero no publica una cifra inicial, el remanente exacto ni una serie fechada.

El pase era válido. La puerta preguntó lo equivocado.

El detalle incómodo del incidente que Daria Shantalova presentó en RIPE 93 es que las rutas llegaron con una etiqueta correcta. Un dominio interno vecino anunció muchos prefijos hacia el Express Backbone que conecta centros de datos. Cada ruta llevaba una comunidad BGP asignada a ese dominio. La route-map de entrada reconoció la comunidad y permitió el anuncio.

Las rutas se propagaron por la malla interna de BGP. Los routers de agregación de los centros de datos recibieron el conjunto completo; el demonio de enrutamiento agotó la memoria disponible y se reinició. Las fuentes públicas no indican cuántos prefijos o routers fueron afectados ni cuánto duró el episodio. Sí explican el fallo: el filtro comprobaba que la comunidad correspondiera al dominio emisor, pero no si cada prefijo podía cruzar desde allí al backbone.

Una comunidad reconocida identifica algo sobre la ruta. No concede una autorización general a todo prefijo que la lleve. El control había confundido una etiqueta de identidad con un permiso de paso.

El límite de volumen no responde qué ruta está autorizada

Cada salvaguarda responde una pregunta distinta. El máximo de prefijos pregunta cuántas rutas llegan. Una lista de prefijos permitidos pregunta cuáles pueden entrar por una frontera. Un filtro de comunidades comprueba si reconoce una etiqueta o debe conservarla. Se pueden combinar; ninguno hace el trabajo de los otros. RFC 7454 trata por separado el filtrado de prefijos, el límite de volumen y el tratamiento de comunidades. RFC 4271 define cómo BGP intercambia información de alcance y toma decisiones de ruta.

El diseño de Shantalova empieza por la identidad: cada prefijo recibe una sola comunidad BGP ID con su dominio de origen y el alcance de propagación permitido. Una comunidad ausente, errónea, duplicada o contradictoria se cuenta como infracción. Después, un registro interno de rutas enlaza cada prefijo con el dominio y la comunidad previstos. A partir de él se generan filtros entrantes para cada frontera entre dominios. La tercera capa compara continuamente los RIB de producción con ese registro. Detecta prefijos no registrados, comunidades que faltan o no coinciden y diferencias frente a la intención; luego genera alertas.

La secuencia importa: identificar, autorizar y verificar. El registro conserva lo que debería ocurrir; el RIB muestra lo que los routers aceptaron. Una exportación de configuración hecha una sola vez no demuestra que ambos sigan alineados.

“Casi todas” necesita un denominador

El resumen de RIPE dice que el equipo eliminó «casi todas» las infracciones observadas en unos meses y atribuye a la aplicación automatizada la prevención de recurrencias. Las diapositivas no incluyen el total inicial, el residuo exacto, una cronología de infracciones ni cuántas fronteras quedaron cubiertas. Una serie fechada de antes y después, junto con la cobertura de implementación, permitiría medir qué parte del cambio fue limpieza y cuál automatización.

La conclusión práctica no es añadir otro filtro y cerrar el ticket. Cada control necesita una responsabilidad concreta y una comparación visible con el estado real. Cuando una etiqueta válida se trata como permiso completo, el sistema puede aplicar con perfecta coherencia una autorización que nunca verificó.

Fuentes: sesión y resumen de RIPE 93; transcripción oficial; diapositivas originales; RFC 4271; RFC 7454.