Resumen

  • La revisión 03 de Current Options for Securing Global Routing, borrador del grupo GROW fechado el 2 de octubre, añade «Impact of the Configuration Paradigm». Distingue entre preparar y confirmar una transacción atómica y ejecutar cada orden en el momento de introducirla. Sigue siendo un Internet-Draft, no un RFC aprobado.
  • El ejemplo empieza con action permit y solo después añade set large-community add 65536:0:0. Si la nueva regla precede a otra que rechaza rutas recibidas de un proveedor ascendente, ese intervalo puede permitir anunciarlas a pares. Es una hipótesis técnica del texto, no una fuga atribuida a una red real.

Un expediente de cambio suele enseñar dos fotografías: configuración anterior y configuración final. La versión 03 de draft-ietf-grow-routing-ops-sec-inform obliga a mirar la película intermedia. Un dispositivo que confirma el conjunto de órdenes como una transacción no alcanza necesariamente los mismos estados que otro que aplica cada línea de inmediato. El Datatracker identifica el documento como borrador activo del grupo GROW, en estado IESG I-D Exists, destinado a ser informativo. No le atribuye el rango de estándar vigente.

La escena de la nueva sección es concreta. Una route-map recibe primero una acción de permiso. Más tarde se añade una Large Community con el valor 65536:0:0. Si antes de la regla de rechazo de rutas aprendidas de redes ascendentes aparece ese permiso, el filtro temporal puede dejar salir rutas hacia pares. No hace falta que la configuración terminada sea permisiva para que haya existido una fase permisiva. Tampoco se deduce que el valor de la comunidad autentique a nadie o que, por sí mismo, impida la fuga: es un elemento del ejemplo del borrador.

Conviene leer la revisión contra la anterior. La versión 02 ya explicaba, al hablar de coherencia de filtros de prefijos, que una actualización no atómica puede aceptar brevemente prefijos indeseados y que un trabajo incompleto puede dejar reglas inconsistentes. La aportación de la versión 03 no es descubrir desde cero ese peligro. Es formular la semántica de confirmación como factor general y demostrarlo con una secuencia de route-map y exportación BGP. El borrador pide a los operadores comprender las diferencias entre enfoques, pero no convierte una receta específica de despliegue en mandato universal.

RFC 8212 introduce una defensa distinta: en EBGP exige políticas explícitas de importación y exportación y rechazo por defecto cuando falta una política. El propio RFC advierte que esa regla no protege frente a una configuración explícita equivocada. Una orden de permiso ejecutada prematuramente sí constituye una política explícita. Por tanto, citar el rechazo por defecto o mostrar el archivo final no demuestra qué anuncios vio el vecino durante la edición.

El control que falta suele ser de evidencia, no de sintaxis. Hay que separar la aceptación de una orden, la activación de la política completa y el conjunto de rutas que recibió el par. Preparar una política íntegra de reemplazo antes de enlazarla puede ser útil si la plataforma lo permite, pero el acto de cambiar la referencia necesita su propia prueba: una sola orden tampoco garantiza atomicidad. Simular pasos, comprobar el estado instalado y observar anuncios son inferencias operativas razonables; ni GROW ni RFC 8212 afirman que ese conjunto de pruebas sea una obligación nueva.

La portada del borrador delimita su alcance: inventario no exhaustivo, sin medir la eficacia de cada técnica ni prescribir una implementación particular. No hemos encontrado en estas fuentes un incidente, un fabricante culpable o una tasa de exposición. Lo que sí queda definido es la unidad de análisis para autorizar una modificación: todos los estados alcanzables de la política de exportación, no solo la última línea del ticket.

Fuentes