Resumen

  • La versión 05 del Internet-Draft del grupo SAVNET, fechada el 1 de octubre, distingue el aprovisionamiento del operador de la información obtenida del sistema de enrutamiento. Si un cliente aporta un prefijo BYOIP o procedente de otro proveedor, el operador debe pedirle que lo identifique y presente evidencia de que puede usarlo como origen, incluso si no hay ruta anunciada o configurada para ese prefijo.
  • El texto sigue siendo un borrador activo con intención informativa; no aprueba un RFC, no acredita un despliegue y no fija un certificado universal ni un nuevo protocolo entre sistemas autónomos. La novedad concreta es cómo enlazar el derecho de origen con el filtro que actúa en cada interfaz de acceso.

Una tabla de rutas responde a una pregunta de destino: por dónde se alcanzaría un prefijo. El filtro de direcciones de origen responde a otra: si el cliente conectado a esta interfaz puede enviar un paquete con ese origen. Es posible que ambas respuestas coincidan, pero no son equivalentes. Si una empresa está conectada por dos accesos o mantiene un prefijo oculto destinado solo al tráfico saliente, la ausencia de una ruta local no demuestra por sí sola que el paquete sea falso.

La versión anterior de la arquitectura ya reconocía las rutas asimétricas y los prefijos ocultos. También describía el agente SAV que reúne información y genera reglas. La revisión 05 no inaugura ese diagnóstico. Lo convierte en un proceso de adquisición más explícito: el operador puede aprovechar registros de clientes, asignación de direcciones o configuración; el agente también puede extraer información útil del sistema de enrutamiento. Las dos fuentes pueden combinarse. Lo que no figura en el sistema de rutas, como el permiso de un prefijo usado solo como origen, tiene que llegar por aprovisionamiento.

Ahí aparece BYOIP. El borrador dice que, para prefijos obtenidos fuera del AS, el cliente debe identificarlos y justificar su autorización para usarlos como fuentes. La autorización necesita representación aunque no se anuncie una ruta. No se desprende de ello que un ROA baste, que un registro decida todos los casos o que una ruta confiera un derecho comercial. El documento no designa un formato único de prueba. El operador de acceso conserva la responsabilidad de asociar la evidencia aceptada con el cliente y sus interfaces.

El ejemplo de la nueva versión usa un cliente C y dos interfaces, i1 e i2, en routers distintos. P1 y P2 pueden derivarse de información de enrutamiento pertinente; H no aparece ahí y debe registrarse de forma explícita. Si la información autoriza los tres prefijos, las listas SAV de ambas interfaces deben permitirlos. Cuando cambia la asignación de un prefijo o se retira el permiso de H, se actualizan las reglas afectadas. Es una demostración conceptual de dos formas de obtener datos, no un caso real ni una prueba de que cualquier red haya automatizado esa coordinación.

También hay un límite para la severidad del filtro. La revisión propone listas de prefijos permitidos, pero advierte que los datos incompletos pueden ocasionar bloqueos indebidos. La política local decide qué hacer con paquetes clasificados como inválidos y un despliegue puede comenzar con observación antes de descartar estrictamente. La arquitectura no prescribe protocolo, algoritmo ni ubicación única del agente. Datatracker la mantiene como documento de trabajo. Su utilidad para la gobernanza está en hacer verificable la cadena entre autorización, interfaz y regla instalada, sin desplazar esa decisión a una autoridad central imaginada.

Fuentes