Resumen

  • La arquitectura de RFC 5269 separa la clave CGA/SEND que respalda una afirmación sobre la dirección fuente, un par independiente que solo transporta el secreto y la clave compartida que autentica el FBU.
  • Verificar el MAC autoriza una mutación de forwarding para la previous care-of CGA en el router anterior. No autentica ubicación, attachment, NCoA, entrega, persona, aplicación ni un binding Mobile IPv6 posterior.

El incidente que se evita es un desvío, no una duda abstracta

Antes de que un nodo móvil cambie de enlace, Fast Mobile IPv6 puede preparar el tratamiento de los paquetes todavía dirigidos a su dirección anterior. El FBU es la orden que pide al previous access router cambiar ese reenvío. Si cualquier vecino pudiera emitirla, un atacante podría apropiarse del tráfico de otra estación sin tener que romper el plano de datos.

RFC 5269 prepara una clave compartida y exige un authorization MAC sobre el FBU. El PAR busca la asociación correspondiente a la care-of CGA antigua y solo modifica el forwarding si el autenticador es válido. Sin clave coincidente, la orden no produce el cambio.

La protección es fuerte precisamente porque su objeto es limitado. El MAC no ve la asociación de capa de enlace, no ejecuta DAD sobre una NCoA y no observa que el nuevo access router haya liberado paquetes almacenados. Tampoco informa si una aplicación continuó funcionando. Llamar al resultado «handover autenticado» sustituye una decisión comprobable por una conclusión que el protocolo nunca calculó.

La separación de claves es la separación de afirmaciones

La primera credencial es el par CGA/SEND. El nodo envía RtSolPr desde su care-of CGA y adjunta parámetros CGA y una firma SEND. Validarla permite al router aceptar que el solicitante está autorizado para reclamar esa dirección fuente en el intercambio.

La segunda credencial nace exclusivamente para transportar el handover key. Aunque usa el algoritmo y los parámetros públicos de SEND, debe ser un par diferente. La especificación prohíbe reutilizarlo para otras operaciones de cifrado o para firmas. La clave pública entra en Handover Key Request Option; la privada nunca sale del móvil y abre la respuesta.

La tercera es el secreto compartido generado o recuperado por el access router. El router lo cifra para esa clave pública dedicada y lo devuelve en Handover Key Reply Option. Más tarde, ese secreto produce el MAC del FBU.

Una columna genérica mobilityKey borraría la diferencia entre firmar una reclamación de dirección, desenvolver un secreto y autorizar un tipo de mensaje. También borraría quién creó cada objeto, dónde puede usarse, qué evento obliga a rotarlo y qué autorización se pierde si queda expuesto.

Primero se valida; después se reserva estado

RtSolPr transporta la clave pública dedicada, la preferencia de Algorithm Type para el FBU, las opciones CGA y Signature de SEND y un nonce. El router debe completar la validación SEND antes de provisionar nada. Si falla, no añade una Handover Key Reply, no genera una clave y no altera el registro legítimo que ya pueda existir para la dirección.

La secuencia también contiene un ataque de agotamiento. Crear aleatoriedad, cifrarla y mantener una entrada de caché cuesta memoria y CPU. El router no debe pagar ese coste antes de comprobar al originador. Incluso las solicitudes autenticadas necesitan límites de tasa y disciplina sobre estados pendientes: una firma válida no convierte una carga masiva en carga gratuita.

Para reconstruir el comportamiento hacen falta dos recibos: resultado de SEND y decisión de admisión. Si el registro solo conserva «firma válida» no explica una denegación por capacidad; si conserva solo «clave entregada» no demuestra que la validación precediera a la asignación.

El móvil también autentica al router que entrega el secreto

Una solicitud aceptada permite que el router devuelva la clave ya asociada a la CGA o cree una nueva. El PrRtAdv incluye el secreto cifrado, HK-LIFETIME, el Algorithm Type escogido y el nonce que recibió.

El acceso no queda autenticado porque el texto cifrado se pueda abrir. El router necesita una credencial apropiada para SEND, firma la respuesta con su clave certificada y permite descubrir el certificado. Si la ruta de certificación no está en caché, CPS y CPA ofrecen el mecanismo de obtención. El móvil verifica la firma y el trust anchor; si no puede vincular la clave de firma a un router certificado, descarta el mensaje.

Después compara el nonce. Ese valor une respuesta y solicitud y selecciona el par privado correcto cuando hay varias operaciones en curso. Una respuesta sin nonce reconocido debe terminar allí, no recorrer las claves locales hasta encontrar una que descifre.

El recibo completo contiene la solicitud original, la prueba CGA, la firma SEND, la decisión del router, el camino de certificado, la firma de PrRtAdv, el nonce repetido, la selección de algoritmo, el par privado y la vida útil. El éxito de descifrado aislado no identifica por sí solo al emisor ni a la política aplicada.

El índice correcto es una relación de varias partes

El access router asocia la shared handover key con la CGA del nodo, el algoritmo y su caducidad. El nodo móvil, al construir un FBU, elige según el router anterior y la care-of CGA anterior de aquel enlace. El Home Address Option del FBU lleva precisamente esa CGA para que el PAR recupere el registro.

Esto evita que una clave válida para una relación se aplique a otra. Un equipo puede guardar material de varios routers, volver a una red visitada o emitir solicitudes superpuestas. La identidad abstracta del dispositivo no basta. Tampoco basta «router actual», porque la orden se dirige al router anterior.

Por eso los metadatos no son decoración: AR, CGA, generación, algoritmo, expiración y propósito forman parte de la autoridad. Un MAC puede ser matemáticamente válido y operacionalmente ajeno si el sistema hizo una unión incorrecta entre tablas.

Negociar un algoritmo también deja evidencia

El nodo propone un tipo de algoritmo. Si el router lo admite, debe devolverlo; si no, la alternativa debe tener fuerza equivalente o mayor. El valor de la respuesta es el que se emplea para el autenticador.

Al recibir ofertas de varios routers, el móvil puede mantener más de una clave. Si ningún algoritmo es compatible, puede volver a solicitar. Lo que no debe hacer es reaccionar a la presión de un router comprometido reduciendo su preferencia inicial y facilitando un bidding-down.

El dato valid=true no conserva esta decisión. Un registro auditable incluye preferencia, selección, versión de política y algoritmo realmente ejecutado. Así una modificación futura de la política no reinterpreta silenciosamente autenticadores históricos.

El tiempo local no renueva una autorización remota

La recomendación para el par de transporte es un máximo de doce horas o diez handovers, lo que ocurra antes. El secreto compartido tiene por defecto doce horas, expresadas como 43.200 segundos.

El router genera una clave aleatoria con la fuerza necesaria y una asignación única por clave pública CGA. Sus valores no deben correlacionarse entre sí ni con las claves CGA. Puede conservarla mientras termina el binding Mobile IPv6 normal, porque otro movimiento rápido puede ocurrir antes.

Si el nodo regresa y reconstruye la misma care-of CGA, el router puede reenviar el mismo secreto no caducado. Pero el nodo no puede convertir una copia todavía presente en memoria en «autorización renovada». Debe recibir la clave de nuevo. Tenerla, verla dentro del plazo, saber que el router quizá la guarda y obtenerla otra vez son estados distintos.

El nodo debería eliminarla después de completar el binding normal en el nuevo router. El PAR la elimina al expirar el forwarding o HK-LIFETIME. El límite efectivo es el primero que cierre la relación, no el temporizador más cómodo para la implementación.

Purpose-built significa que la autoridad no se recicla

La clave compartida no cifra tráfico de usuario y no constituye una sesión de aplicación. No identifica a un abonado, empleado o persona. No valida la NCoA prevista, no reemplaza Return Routability ni Binding Update de Mobile IPv6 y no demuestra que un correspondent node haya aceptado nada.

RFC 5568 sustituyó a RFC 5268 como especificación base de FMIPv6 y mantiene la referencia a RFC 5269 para la clave usada por el autenticador del FBU. La extensión debe implementarse contra esa base vigente; adoptar formatos antiguos sería un problema distinto de la autenticación.

Mejoras posteriores de SEND pueden endurecer certificados o distribución de trust anchors. Eso aumenta la confianza en quién firmó una respuesta, pero no expande el acto autorizado. Una prueba reforzada conserva el mismo predicado.

El código ejecutado muestra una cadena, no un sello

Aplicar la Running-Code Primacy de Lu Heng obliga a enumerar lo que ocurrió: se reclamó una CGA, se verificó SEND, se recibió una clave pública dedicada, firmó un router certificado, coincidió un nonce, se creó una relación en caché, se eligió un algoritmo, se validó un FBU y se modificó forwarding.

Las reality layers mantienen separados posesión, autorización y resultado. Poseer una clave privada permite una operación criptográfica; SEND acepta una reclamación de dirección; el certificado sitúa al router en un modelo de confianza; el nonce relaciona mensajes; el MAC autoriza la orden. Ninguno observa por sí mismo el nuevo enlace ni el éxito de servicio.

Un estado sigue siendo verificable si puede retroceder hasta la generación de clave, su propósito, los sujetos, el mensaje y los límites temporales. Si la trazabilidad acaba en «autenticado», la abstracción ya no puede volver al hecho que la hizo cierta.

Fuentes