Resumen
- MP_ADDADDR anuncia una dirección junto con un Address ID, pero ese estado blando no es por sí mismo una ruta de datos admitida.
- MP_JOIN debe emplear el identificador de conexión del par, el Address ID, un nonce nuevo y el intercambio definido para asociar el subflujo a la conexión inicial y comprobar la alcanzabilidad de la dirección anunciada.
- MP_HMAC autentica las opciones correspondientes mediante HMAC-SHA256 truncado a los 160 bits más a la izquierda. Cada opción protegida necesita su propio MP_HMAC inmediatamente después.
- Un fallo HMAC en MP_ADDADDR o MP_REMOVEADDR se ignora silenciosamente; un fallo HMAC en MP_JOIN cierra el subflujo que se estaba intentando establecer. Un MP_HMAC que no puede asociarse con una opción se ignora conforme a la regla exacta de la RFC; no se debe inventar un rechazo específico de la operación por una mera colocación incorrecta.
La continuidad de identidad comienza con MP_KEY y el identificador de conexión. El subflujo posterior transporta ese identificador, un Address ID generado por el emisor y un nonce de 32 bits. El Address ID debe mapear de forma única a la dirección de origen del emisor dentro de la conexión, debe seguir siendo útil aunque un dispositivo intermedio reescriba la dirección, permite relacionar MP_JOIN con MP_ADDADDR y no puede reasignarse mientras algún extremo lo siga utilizando.
La validación HMAC no demuestra que la dirección sea benigna, globalmente alcanzable o propiedad del par. MP_ADDADDR es estado blando autenticado: puede descartarse, las direcciones de difusión o multidifusión deben ignorarse y la RFC indica que, después de fallar una combinación de dirección y puerto, no deberían repetirse los intentos salvo que el anuncio se refresque. Esto último es una recomendación de la RFC, no un presupuesto universal de reintentos.
Para Theo March, la decisión práctica consiste en separar la autenticidad del control de la admisión de una ruta. Su análisis puede considerar la frescura de los nonces, la continuidad del identificador, la adyacencia exacta entre cada opción y su MP_HMAC, el ciclo de vida del Address ID, la finalización bidireccional de MP_JOIN y las heurísticas de reintento. Son criterios analíticos o de implementación, no nuevas obligaciones de la RFC. La RFC tampoco fija un planificador universal, un algoritmo de control de congestión acoplado, un umbral de telemetría ni un presupuesto de reintentos.
Fuentes
- RFC 9897 — Datagram Congestion Control Protocol (DCCP) Extensions for Multipath Operation with Multiple Addresses
- RFC 4340 — Datagram Congestion Control Protocol (DCCP)
- RFC 2104 — HMAC: Keyed-Hashing for Message Authentication
- RFC 6234 — US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)
- RFC 4086 — Randomness Requirements for Security
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
