Resumen

  • draft-sriram-savnet-intrasav-solution-00 propone que clientes y AS local declaren qué prefijos pueden rutarse o usarse como origen en cada interfaz, y que un gestor construya las listas correspondientes.
  • Su garantía de cero bloqueos y permisos indebidos depende de que la configuración sea completa. La revisión 00 no ofrece todavía una prueba de distribución, commit o medición en el punto que procesa el paquete.

El prefijo s no aparece en la tabla de rutas. Aun así, el cliente está autorizado a responder desde él en un diseño Direct Server Return. Un filtro derivado de la FIB puede concluir que el paquete es falso; un permiso local explícito sabe que la ausencia de anuncio es intencional.

Ese avance resuelve una ambigüedad real. También traslada la pregunta: ¿cómo sabe el operador que la declaración correcta, para el cliente correcto y la interfaz correcta, es la que está ejecutando el router ahora mismo?

La cuestión llega con la revisión 00 de IntraSAV - A Solution for Intra-Domain Source Address Validation, subida el 1 de octubre de 2026. Es un Internet-Draft individual en I-D Exists, con estado previsto Best Current Practice. No es adopción de SAVNET, RFC, acción de IANA, producto implementado ni resultado de campo. Solo si fuese aprobado actualizaría BCP 38 y BCP 84.

La FIB responde sobre alcance, no sobre permiso

El filtrado de origen lleva décadas lidiando con una tensión. El uRPF estricto compara la interfaz de llegada con la ruta de retorno y puede bloquear tráfico legítimo cuando existe asimetría o multihoming. El uRPF laxo comprueba que exista alguna ruta y evita parte de esos cortes, pero pierde la relación con la interfaz y permite más suplantación. Las ACL manuales conservan precisión hasta que cambia un prefijo y nadie actualiza la lista.

La declaración de IntraSAV cambia la fuente de verdad. Un cliente BYOIP informa al AS local de los prefijos que piensa anunciar, usar como origen o ambas cosas. El AS añade sus propios requisitos por interfaz. Un Configuration Manager, quizá con un SAV Agent, consolida los datos y programa una allowlist en cada interfaz relevante de los routers CE.

El ejemplo usa dos clientes. El primero registra {p, q} y anuncia ambos. El segundo registra {r, s}, anuncia r y reserva s para originar tráfico. Por eso la interfaz 1 recibe {p, q} y la 2 recibe {r, s}. La lista expresa una autorización que la ruta por sí sola no puede representar.

La mejora encaja con el diagnóstico del borrador SAVNET intra-dominio: la información de forwarding describe alcance, no necesariamente el derecho a usar una dirección de origen. Los prefijos ocultos, la asimetría y los servicios especiales hacen que convertir FIB en política de autorización produzca falsos positivos o falsos negativos.

Una coincidencia de ROA no instala una regla

Los propietarios deberían crear ROAs que autoricen al AS local como origen. Para el uso local, sin embargo, el borrador da precedencia a la configuración del AS sobre el ROA. También pide comparar ambas vistas y alertar de inconsistencias, pues redes remotas pueden usar el ROA para construir reglas inter-dominio.

Cada registro responde a un ámbito. El ROA comunica autorización de origen. La configuración local vincula cliente, prefijo, interfaz y modo de uso. Que coincidan no demuestra que el cliente haya aprobado el último cambio, que el puerto siga bajo su control o que la lista esté activa en el plano de datos. Que no coincidan tampoco dice automáticamente cuál está mal; activa una investigación y una decisión local.

La revisión indica que el Configuration Manager autentica al cliente, pero no define cómo. Faltan el protocolo de alta, alcance de credencial, aprobación, revocación, protección contra repetición e identidad de transacción. La libertad de diseño local es compatible con una especificación inicial mínima. La ausencia de un recibo no lo es cuando se quiere atribuir un corte o demostrar un permiso.

La condición de completitud necesita su propio control

La frase más contundente del texto asegura cero improper blocks y cero improper admits siempre que el gestor disponga de información completa. Dentro de la abstracción, el razonamiento funciona: si la lista contiene todos y solo los orígenes autorizados para ese puerto, clasifica correctamente cada miembro del conjunto modelado.

Pero el borrador no define cómo se certifica «completa». No hay generación, vigencia, inventario de interfaces, transacción atómica, acuse del router ni rollback. Tampoco describe una actualización concurrente, una partición del controlador, un reinicio o el traslado de un cliente entre puertos.

Así aparece una brecha temporal. El gestor calcula la generación 12; un CE mantiene la 11. El agente recibe la configuración, pero el hardware conserva otra tabla. El permiso antiguo continúa tras una baja, o el nuevo prefijo solo de origen se bloquea durante el despliegue. El algoritmo sigue siendo correcto para su entrada y el efecto sigue siendo erróneo para el paquete.

El término cero necesita un denominador operativo. Hay que enumerar las vinculaciones autorizadas, identificar la generación esperada y la comprometida, etiquetar paquetes legítimos y suplantados y medir las cuatro salidas: permitir y bloquear correctamente, permitir y bloquear indebidamente. El éxito de una tarea en el controlador no sustituye esas observaciones.

La lista agregada cambia la garantía

El texto abre además una idea que marca como pendiente de discusión. Un ASBR podría usar la unión {p, q, r, s} si la topología local garantiza que todos esos orígenes son los esperados en su interfaz. Puede ser atractivo cuando actualizar un ASBR resulta más viable que actualizar todos los CE.

La misma sección advierte que esto probablemente exceda el alcance del problema salvo que el ASBR atienda directamente hosts o clientes sin AS. La unión conserva pertenencia al dominio, pero borra la asignación fina. Un paquete con origen s puede pasar en la frontera aunque llegue desde el cliente equivocado. La defensa agregada no equivale al control por interfaz.

Tampoco el porcentaje de puertos configurados prueba el beneficio incremental. Para eso se necesitan rutas de ataque, tráfico legítimo de referencia, excepciones y contadores antes y después. Una cobertura del 70% puede cerrar los bordes de mayor riesgo o dejar abierta precisamente la entrada más explotable.

Hacer visible la versión que decidió sobre el paquete

La cadena operativa debe separar autenticación de cliente; autorización de prefijo e interfaz; aceptación de configuración versionada; comprobación de ROA; cálculo; entrega; commit o rechazo; contadores; evaluación etiquetada; y resultado de seguridad y servicio. Cada eslabón puede funcionar sin prestar su prueba al siguiente.

El marco de Heng Lu permite mantener local la decisión y el diseño del gestor. Lo que exige es una evidencia reproducible de ejecución. Un digest de configuración, una generación por interfaz y un acuse de commit no convierten al controlador en autoridad global; permiten comprobar si la intención local llegó a la máquina correcta.

IntraSAV mejora la verdad de entrada al registrar explícitamente prefijos que la ruta no revela. La disciplina de despliegue debe conservar esa mejora hasta el puerto y el contador. Solo entonces la lista completa deja de ser una suposición del modelo y se convierte en un hecho operativo.

Fuentes