Resumen

  • La revisión 01 propone DOWNGRADE como comunidad BGP conocida y transitiva para que, durante congestión, el tráfico hacia un prefijo marcado reciba menor precedencia y se descarte antes que el resto.
  • La etiqueta no demuestra que un dominio aceptó la petición, instaló el clasificador, usó una cola Lower-Effort, conservó el DSCP, sufrió congestión ni entregó muestras útiles a la víctima.
  • La medida requiere capacidad residual, autorización del prefijo, evidencia de plano de datos y retirada oportuna; de lo contrario puede convertirse en un blackhole blando difícil de detectar.

El blackholing remoto resuelve una parte del ataque destruyendo la otra. Cuando el volumen contra una dirección ahoga enlaces compartidos, descartar todo lo destinado a la víctima puede salvar a los demás usuarios. También completa la indisponibilidad que el atacante buscaba y deja al defensor con menos datos para saber cuándo levantar el filtro.

La propuesta DOWNGRADE cambia el orden de pérdida. El prefijo sigue anunciado, pero su tráfico pasa a una clase que debería perder primero cuando aparece congestión. Si existe capacidad libre, algunos paquetes continúan. Ese resto puede mantener una función básica o mostrar que el ataque sigue vivo. No es una garantía de servicio: es una posibilidad condicionada por cada dominio de tránsito.

La revisión 01 se publicó el 24 de septiembre de 2026 como trabajo del grupo GROW. El registro de Datatracker la mantiene como Internet-Draft activo y el anuncio oficial no afirma más que su disponibilidad. El encabezado apunta a una categoría Informational. No es un RFC ni una prueba de adopción.

IANA ya registró un nombre común. Tras la solicitud del autor, el registro de comunidades conocidas asignó 0xFFFF000A a DOWNGRADE. El número elimina una ambigüedad de coordinación, no una de ejecución. El propio texto ilustra la distancia: la sección IANA presenta el valor definitivo, mientras sus configuraciones de ejemplo aún contienen TBD. No son recetas listas para producción.

El RFC 1997 define Communities como un atributo opcional y transitivo. Un router puede usarlo para aceptar, preferir o distribuir rutas y puede modificarlo según política local. Por tanto, el emisor no controla a distancia una cola. Declara una propiedad deseada; el receptor conserva la autoridad para validar al vecino, aceptar el prefijo y decidir el efecto.

El borrador espera que la política de ruta alimente un clasificador de reenvío. Los paquetes hacia el prefijo deben entrar en una clase de menor precedencia y, bajo congestión, descartarse antes que cualquier otro tráfico. Al salir a otro dominio deberían llevar el DSCP Lower-Effort 000001 del RFC 8622. Los servidores de rutas de un punto de intercambio deberían propagar la comunidad, y los operadores no deberían retirarla, para que la reducción ocurra más cerca de las fuentes.

Sin embargo, un route server solo mueve información de control. El RFC 7947 no lo convierte en salto de reenvío. Puede distribuir correctamente la comunidad entre cientos de sesiones sin haber clasificado un solo paquete. Esa visibilidad confirma propagación, no tratamiento.

Lower-Effort tampoco significa un mínimo asegurado. El RFC 8622 permite rendimiento muy bajo y hasta inanición completa. Cuando un dominio carece de cola LE, debería mapear los paquetes al comportamiento predeterminado y conservar el marcado. Así el aviso sobrevive, pero el tráfico recibe un trato mejor del solicitado y puede competir con Best Effort. Si otro equipo borra el DSCP, el dominio siguiente pierde la intención. Si alguien marca indebidamente tráfico legítimo, la misma herramienta causa una degradación de calidad.

La observabilidad debe verificarse por separado. Que salgan muestras de una cola no prueba que crucen todos los cuellos posteriores ni que alcancen el sensor correcto. Una tasa cero junto a la víctima puede indicar fin del ataque, inanición aguas arriba, blackhole intermedio o fallo de telemetría. Una tasa pequeña puede ser insuficiente para medir composición, intensidad o recuperación de la aplicación.

El borrador reconoce una restricción económica del enlace: hace falta capacidad sin usar. La prioridad reparte escasez; no fabrica ancho de banda. Si la congestión sucede antes del punto que clasifica, o el tráfico superior consume todo lo disponible, DOWNGRADE no conserva nada. Tampoco elimina la fuente del ataque.

Aquí se separa del BLACKHOLE del RFC 7999 y del RTBH descrito por el RFC 5635. BLACKHOLE pide descarte total y contención de propagación. DOWNGRADE busca propagación amplia y una probabilidad no nula de entrega. Ambos son avisos sujetos a autorización del prefijo, pero la prueba de uno no demuestra el resultado del otro.

Una operación auditable conserva diez eslabones: prefijo y dueño del incidente; speaker autorizado; vecinos que aceptaron; route servers que conservaron; política que creó la clase; estado instalado de FIB y clasificador; cola y planificador; DSCP en fronteras; congestión, descartes y muestras; llegada y canarios en la víctima. Después añade la retirada y la recuperación de entrega ordinaria. Cada eslabón responde una pregunta distinta.

La primacía del código en ejecución de Heng Lu coloca el comportamiento del paquete por encima del registro. Las capas de realidad separan atributo, cola y resultado. La especificación inicial mínima limita la coordinación común al vocabulario indispensable y deja la ejecución bajo responsabilidad local.

DOWNGRADE es una opción valiosa porque intenta no confundir mitigación con desaparición. Para merecer esa diferencia, debe demostrar el estado intermedio. La comunidad inicia una petición; la cola decide qué sobrevive.

Fuentes