Resumen

  • Una dirección generada criptográficamente asociaba una clave pública con el identificador de interfaz IPv6; la firma probaba el control de la clave privada, no la identidad de una persona ni la autoridad de un router.
  • El equipo aún debía validar la cadena de certificados del router hasta un ancla de confianza configurada de antemano. SEND no eliminó ese punto de partida.

Neighbor Discovery ocurre antes de que IPv6 pueda dar por sentada la red local. Los equipos resuelven direcciones de capa de enlace, buscan routers y actualizan información de alcanzabilidad. Una falsificación en esa fase puede alterar decisiones de encaminamiento o interrumpir la comunicación. RFC 4861 define esas funciones. La protección con IPsec aparecía en el diseño inicial, pero RFC 3971 señala que faltaban instrucciones detalladas y que configurar manualmente asociaciones de seguridad para tantos pares podía ser poco práctico.

SEND no respondió con una sola credencial que supuestamente resolviera cada aspecto. Separó la prueba de una dirección de la autorización de un router. Para la primera usó direcciones generadas criptográficamente (CGA). RFC 3972 obtiene el identificador de interfaz mediante un hash de una clave pública y parámetros auxiliares. El receptor recalcula el vínculo y verifica la firma correspondiente. Así puede comprobar que quien firmó controla la clave asociada a esa dirección sin consultar una autoridad certificadora.

El alcance es deliberadamente más estrecho que una identidad. RFC 3972 advierte que cualquiera puede crear una nueva CGA dentro de un prefijo de subred con su propia clave. La protección evita que ese actor firme como titular de una CGA ajena; no demuestra quién es en el mundo real, quién asignó el prefijo o si debe anunciar una ruta. Una prueba de posesión de clave no es una autorización de router.

Para autorizar al router, el host sigue otra cadena. Debe comprobar que el certificado del router llega a un ancla de confianza que ya tiene configurada. Los mensajes de descubrimiento SEND pueden ayudar a obtener la ruta de certificación, pero no convierten una raíz desconocida en una raíz confiable. Por eso, “sin infraestructura” describe el vínculo CGA entre dirección y clave; no describe toda la autorización de Router Discovery.

Las actualizaciones posteriores hicieron más explícitos los bordes. RFC 6494 estableció un perfil de certificados SEND basado en certificados de recursos. RFC 6495 añadió un tipo de nombre para campos Subject Key Identifier. Y RFC 6980 restringió la fragmentación IPv6 de mensajes ND y SEND, dado que los encabezados de fragmentación podían eludir algunos mecanismos de inspección. Son cambios en credenciales y tratamiento de paquetes; no cuantifican despliegue ni prueban un resultado de seguridad.

La historia de RFC 3971 no es que la criptografía sustituyera la confianza. Es que dejó de mezclar dos preguntas: quién controla la clave de una dirección y quién autoriza a un router. La segunda conservó un punto de control administrativo visible.