Resumen

  • RFC 5210 obtuvo el resultado esperado en AS con despliegue completo: validación en el acceso, dentro del AS y entre AS. El éxito no cubre automáticamente los tramos donde falta una de esas capas.
  • Las asociaciones de puerto, las reglas derivadas del enrutamiento y las etiquetas de alianza cambian. Un resultado sin versión ni hora es una fotografía presentada como estado permanente.
  • Impedir la suplantación no autentica a la persona. Un equipo comprometido puede atacar con su dirección legítima y superar correctamente todos los controles de fuente.

La pregunta incorrecta del centro de operaciones

Un panel muestra un paquete con tres marcas verdes. La primera procede del conmutador de acceso: la dirección IPv6 concuerda con el puerto y la asignación. La segunda procede del borde del AS: el prefijo resulta plausible en la interfaz según la tabla utilizada. La tercera llega del otro extremo de una alianza: la etiqueta temporal coincide con la época vigente.

La pregunta del operador es “¿la fuente está autenticada?”. Parece eficiente, pero comprime tres afirmaciones diferentes y borra sus condiciones. La pregunta operativa correcta es más larga: ¿qué paquete fue aceptado, por qué barreras, con qué datos de control, en qué instante y cuál fue el primer tramo no verificado?

A las 09:12 el host cambia de enlace. Una actualización de prefijos se propaga y la alianza rota su etiqueta. Durante unos segundos coexisten la versión anterior y la nueva. El panel conserva el mismo verde. Nada invalida el registro anterior; lo que desapareció es el derecho a usarlo en presente.

La escena es hipotética. No atribuye un fallo a una red, producto o fabricante. Expone una forma común de inflación semántica: convertir la aceptación de una dirección en identidad del emisor y convertir un instante en continuidad.

El alcance real del experimento

RFC 5210, publicado como Experimental en junio de 2008, documenta un prototipo de Source Address Validation Architecture. Doce universidades conectadas a CNGI-CERNET2 desplegaron AS para el banco de pruebas; seis contaban con las tres partes y podían probar la configuración completa.

Los autores ensayaron tráfico normal, cambios dinámicos y falsificación. Para el mecanismo entre AS no vecinos, las pruebas incluían añadir y retirar etiquetas, aceptar fuentes válidas, actualizar la etiqueta, proteger a un miembro nuevo y añadir o eliminar espacio de direcciones.

El resultado positivo está formulado con una condición decisiva: en un AS plenamente equipado con validación de acceso, intra-AS e inter-AS, no se reenviaron paquetes carentes de dirección fuente autenticada. No es una medición de todos los caminos de Internet ni una tasa de eficacia aplicable a sistemas actuales.

El propio RFC presenta las soluciones como experimentales y como aportación inicial, no como cierre del trabajo del IETF. También enumera límites de despliegue, seguridad, sincronización y rendimiento. Leer esos límites junto al resultado es una práctica de precisión, no una crítica al proyecto.

Primera barrera: el vínculo local

En una variante, el sistema construye dinámicamente una relación entre dirección IP, MAC y puerto de conmutador. El equipo de acceso descarta paquetes que no encajan en la pareja dirección-puerto. En otra, la autenticación de acceso entrega material de clave y cada paquete recibe una protección comprobada por el dispositivo SAVA.

La primera variante afirma que la dirección concuerda con un punto de conexión según la tabla local. La segunda añade evidencia de una sesión protegida bajo un contexto de claves. Ninguna identifica por sí sola al usuario, al proceso que generó el tráfico o a la entidad que ordenó la acción.

Además, el RFC advierte que la aproximación del prototipo no bastaría en producción. Multihoming, movilidad, cambio de interfaz, enlaces inalámbricos y failover alteran el punto de conexión. La tabla debe tener creación, caducidad, mecanismo de traslado y tratamiento de conflictos.

Segunda barrera: la plausibilidad del prefijo

La capa intra-AS adopta principios de RFC 2827 y RFC 3704. Evalúa si el prefijo fuente es compatible con la interfaz y el conocimiento de encaminamiento. Es una granularidad de red, no de host.

En topologías simétricas, una comprobación estricta puede ser útil. En redes multihomed o con caminos asimétricos, el mejor camino de vuelta no siempre coincide con la entrada legítima. Por eso existen variantes de camino factible o más flexibles. La aceptación depende del modo y de la vista de rutas.

Una regla generada ayer puede ser correcta ayer y falsa hoy sin que el algoritmo haya fallado. La prueba necesita la tabla o conjunto de caminos utilizado, su instante efectivo, la interfaz y el identificador de la regla instalada.

Tercera barrera: coordinación entre administradores

Para AS vecinos, el prototipo construye reglas que relacionan interfaces de entrada con bloques fuente. Un motor expresa la regla en AS, un servicio cartografía AS a prefijos IPv6 y los validadores reciben la proyección.

Para AS no vecinos, la solución experimental forma una alianza. El borde de origen añade una etiqueta temporal; el borde de destino la busca, verifica y elimina. Un servidor mantiene miembros y los servidores de control intercambian información de prefijos y etiquetas.

Esta capa amplía la superficie organizativa. La exactitud ya no depende sólo de un router, sino de membresía, confianza, sincronización, cartografía y distribución. Aunque la alianza estaba diseñada para altas y bajas dinámicas, el banco de pruebas confirmó inicialmente la confianza fuera de línea. Esa condición debe permanecer visible.

El tiempo es parte de la regla

Las etiquetas cambian periódicamente. RFC 5210 explica que la antigua no debe aceptarse para siempre; en la prueba, la superposición tras asignar una nueva duraba cinco segundos. La continuidad se obtuvo admitiendo dos estados durante una ventana definida.

El mecanismo de vecinos también podía retrasarse frente a cambios rápidos de rutas y causar falsos positivos. Funcionó en una red relativamente estable. No hay contradicción: un mecanismo puede funcionar bien bajo la dinámica probada y requerir nuevos recibos al cambiar esa dinámica.

Por eso el estado mínimo incluye asociación y época de acceso, vista de ruta, relación entre AS, mapa de prefijos, versión generada, confirmación de distribución, huella instalada, membresía de alianza, época de etiqueta y fin de la superposición. El panel debe mostrar la primera pieza ausente o atrasada.

Trazar una dirección no descubre a una persona

Reducir la suplantación mejora la confianza con la que puede seguirse el tráfico hasta una red o punto de conexión. Esa mejora es valiosa para diagnóstico y respuesta. Pero no salta del plano de red al de identidad.

RFC 7039 advierte que las técnicas de validación pueden aportar evidencia circunstancial, no resolver la atribución a una persona ni necesariamente a un sistema final. Un servidor compartido, un proxy, un relé, una plataforma de aplicaciones o un host comprometido pueden originar tráfico con una dirección perfectamente válida.

La escalera de evidencia debe permanecer abierta. Primero se acepta una dirección en un puerto. Después se asocia un dispositivo, si existe evidencia. Luego se identifica una carga de trabajo o cuenta. Sólo con pruebas adicionales se puede hablar de organización, persona o intención. El primer peldaño no contiene los demás.

Los registros de asociaciones también tienen coste de privacidad. Pueden revelar cuándo y dónde estuvo activo un equipo. La conservación debe tener plazo, finalidad, acceso auditado y posibilidad de corregir una atribución errónea.

La dirección del atacante también puede ser correcta

RFC 5210 reconoce un límite especialmente relevante: buena parte de los ataques de denegación de servicio puede proceder de clientes de botnet con direcciones legítimas. Ni siquiera una implantación universal de mejor validación impediría esos ataques.

SAVA combate la falsificación. No certifica que el dispositivo esté sano, que el proceso tenga permiso, que el volumen sea benigno o que el usuario quiera esa acción. Un host comprometido no necesita inventar una dirección; puede abusar de la que se le asignó.

Esto cambia la respuesta. Cuando la fuente es válida pero el comportamiento es hostil, el equipo debe pasar a telemetría del endpoint, identidad de carga, cuenta, autorización y patrones de tráfico. Insistir en la barrera anti-spoofing sólo vuelve invisible la clase de incidente que quedó fuera.

Del control a la ejecución

La etiqueta ligera del prototipo era un número aleatorio compartido, no una autenticación criptográfica integral por paquete. El RFC discute el riesgo frente a un adversario en el camino y el coste de usar una función criptográfica más fuerte. Las opciones hop-by-hop de IPv6 también llevaron a rendimiento limitado con algunos routers del ensayo.

Una política registrada no demuestra que el plano de datos la aplicó. Hace falta acuse de instalación, contadores, paquetes de prueba y observación correlacionada. Si un dispositivo desvía opciones al camino lento, el control puede crear presión de capacidad. Si operaciones añade un bypass, la cobertura puede caer aunque el panel mantenga la configuración prevista.

Cómo redactar el recibo

El recibo empieza por el paquete o flujo, el instante y el punto de captura. Enumera las barreras exigidas. En acceso conserva asignación, dirección, MAC o ancla, puerto, creación, caducidad y cambio. En intra-AS conserva modo, interfaz, vista de rutas, prefijo y regla.

En inter-AS añade relación, cartografía, motor generador, versión, distribución e instalación. Para la alianza añade membresía, pares, propiedad anunciada, semilla o etiqueta, época, solapamiento y caducidad. Las versiones de hardware y software, el tratamiento de opciones y los contadores pertenecen al mismo registro.

El cierre no debe inventar identidad. Puede decir: el paquete fue aceptado por tres barreras actuales; el actor no está determinado. Si una investigación posterior aporta vínculo de endpoint, cuenta o persona, se agrega como evidencia independiente con su incertidumbre.

Fuentes