Resumen

  • El anuncio del 17 de septiembre solicita comentarios hasta el 1 de octubre sobre el borrador interdominio SAVNET -21 para un RFC informativo.
  • Los errores de bloqueo y de permiso cambian según la relación de cliente, par o proveedor y según la visibilidad de las rutas.
  • El consenso del grupo de trabajo no certifica un mecanismo, una configuración local ni efectos medidos sobre el tráfico.

La pregunta operativa no es si un prefijo aparece en alguna tabla, sino si ese vecino podía enviar por esa interfaz un paquete con tal origen. El borrador SAVNET separa esa pregunta en tres fronteras. Una lista de control mantenida a mano puede ser precisa y costosa; una inferencia automática basada en rutas puede ser más barata y fallar cuando la topología visible no refleja la autorización real.

Para un cliente multihomed, una política de propagación limitada puede ocultar un prefijo a un proveedor aunque el cliente emita tráfico válido desde él. El retorno directo de un servidor de borde puede usar como origen una dirección anycast anunciada desde otro lugar. Rechazar todo paquete cuya ruta no apunte de vuelta a la interfaz crearía un bloqueo indebido en los escenarios del texto. Pero relajar la direccionalidad para evitarlo permite en ciertos casos que un miembro de un cono de clientes suplante el origen de otro, si la validación no se aplica más cerca del atacante. Son ejemplos analíticos, no incidentes demostrados.

En un enlace entre pares, el enrutamiento asimétrico debilita aún más la deducción por ruta inversa. En el enlace hacia un proveedor, Loose uRPF acepta un prefijo presente en la tabla de reenvío incluso cuando el tráfico que entra por ese proveedor lo suplanta. La elección no se reduce a «estricto o laxo» de manera uniforme: exige relación comercial, visibilidad, datos de autorización, mantenimiento y una forma de corregir falsos bloqueos.

La IESG anunció el último llamamiento el 17 de septiembre y pidió observaciones sustantivas antes del 1 de octubre. Según el registro del documento, sigue siendo un Internet-Draft con publicación solicitada. Se propone como RFC informativo: describe lagunas y objetivos para técnicas futuras, entre ellos precisión, costes operativos, utilidad con adopción parcial, seguridad de la información específica de SAV y convergencia de tablas. No especifica una extensión BGP ni crea por sí solo una política de filtrado obligatoria.

El informe del responsable de acompañar el documento relata dos consultas del grupo SAVNET y amplio acuerdo. Esa etapa no sustituye el juicio posterior de la IESG. Una revisión temprana de la versión 20 pidió aclarar si buscar cero bloqueos indebidos era obligación o aspiración y cómo se confiaría en diferentes tipos de información. Se refería a una versión anterior; no prueba que la versión 21 mantenga un defecto sin resolver.

Fuentes