Resumen

  • El IESG abrió el 17 de septiembre de 2026 la consulta final sobre la revisión 21 del planteamiento interdominio de SAVNET, con plazo hasta el 1 de octubre. El destino propuesto es un RFC informativo; aún no lo es.
  • El documento analiza tanto el bloqueo indebido de tráfico legítimo como el permiso indebido a direcciones falsificadas. El router que aplica la tabla SAV no puede reconocer por sí mismo todos esos fallos.
  • La respuesta de un cliente o par afectado puede iniciar la investigación. Dejar constancia de la reclamación y de la regla corregida es una propuesta de este artículo, no un procedimiento estandarizado por el borrador.

Una regla de validación de dirección de origen tiene una apariencia definitiva: acepta o descarta un paquete en una interfaz concreta. Pero el resultado solo es tan bueno como la información utilizada para formar la tabla. En su documento de problemas y requisitos, el grupo SAVNET pregunta qué ocurre cuando esa información no representa todas las rutas por las que un origen legítimo puede llegar. La consulta final del IESG hace visible una dificultad de gobierno que no cabe en el contador de paquetes descartados.

El texto estudia prefijos cuya propagación se limita deliberadamente y prefijos ocultos que sirven como origen, incluidos escenarios de anycast con devolución directa. La ausencia de una ruta visible para el filtro no convierte automáticamente en ilícito un origen. Si el sistema equipara ambas cosas, puede cortar tráfico permitido. El remedio fácil tampoco es abrirlo todo: cuando una técnica relaja la restricción sobre la dirección de entrada, puede dejar pasar más paquetes con direcciones suplantadas.

Ambos errores importan, y una implantación parcial no ofrece protección completa frente a la suplantación dentro del conjunto de clientes de un operador.

Lo novedoso para la gestión cotidiana está en la sección 6. El router de frontera no posee un detector interno capaz de saber si su propia decisión fue un falso bloqueo o un falso permiso. La noticia puede llegar en forma de problema comunicado por una red descendente o un par. Esa comunicación no sustituye a la comprobación técnica; obliga a relacionar una observación externa con la interfaz de entrada, la versión de la tabla SAV y los datos que produjeron la entrada sospechosa. La autoridad para filtrar y la prueba de que el filtro se equivocó están distribuidas.

El borrador pide a las futuras soluciones mayor precisión, menor trabajo manual para actualizar datos, utilidad incluso si otros aún no adoptan SAV, protección de información específica que se intercambie y una convergencia razonable. No crea, por ello, una API de incidencias entre sistemas autónomos ni un acuerdo obligatorio de tiempos de respuesta. Tampoco informa de un fallo ocurrido en un operador concreto. Es un documento de análisis y requisitos, no una certificación de que un producto resuelve el problema.

Una práctica interna podría poner fecha y responsable al circuito de corrección. Daniel Kade propone registrar qué vecino notificó el síntoma, qué clase de tráfico y prefijo se investigó, qué tabla y fuentes estaban vigentes, quién decidió modificar o conservar la regla y cómo se verificó el cierre. La reclamación debe ser delimitada: los detalles de paquetes o de acuerdos comerciales no tienen por qué circular indiscriminadamente. El objetivo no es dar por cierta cada queja; es evitar que una decisión local se defienda solo porque la máquina fue coherente con una tabla incompleta.

La revisión 21 está fechada el 19 de julio. El hito del 17 de septiembre fue la apertura de Last Call y el plazo de comentarios acaba el 1 de octubre. Nada de ello equivale a publicación definitiva como RFC ni a implantación. La pregunta pendiente no es si habrá otro eslogan contra la suplantación, sino si el operador que puede cambiar el filtro recibirá a tiempo evidencia suficiente para saber cuándo debe hacerlo.

Fuentes