Resumen

  • MP_JOIN usa el Token del receptor para encontrar una conexión MPTCP ya existente; los HMAC, los nonces y la política del receptor resuelven por separado la admisión del subflujo.
  • Una dirección adicional selecciona una posibilidad de transporte. No acredita propiedad de ruta, identidad humana, autorización de aplicación ni resultado de una operación.

Para una aplicación, MPTCP pretende seguir pareciéndose a TCP: un flujo de bytes fiable y ordenado. Para el sistema de red, en cambio, la conexión se compone de varios subflujos TCP, cada uno con su propio cinco-tupla. Esa doble descripción, expuesta por RFC 6182, evita una simplificación peligrosa. Que una conexión tenga más de un subflujo no significa que haya una sola prueba para todo lo que ocurre en ellos.

RFC 6182 trató las direcciones múltiples como una señal práctica de posibles caminos, no como demostración de rutas independientes. También exigió compatibilidad con TCP común, con los intermediarios ya presentes y con usuarios que compiten en cuellos de botella compartidos. La promesa no era que cada camino añadido ganaría capacidad; era que la arquitectura no debía destruir las obligaciones de coexistencia.

Antes de unir, hay que crear el material de unión

La primera conexión realiza una negociación MP_CAPABLE sobre el SYN, el SYN/ACK y el ACK. RFC 8684 define en esa secuencia la capacidad MPTCP de la conexión y las claves que después participan en la autenticación de subflujos adicionales. Si esa negociación necesaria no llega completa, el resultado especificado es TCP normal de un solo camino. No existe una obligación de forzar una versión multipath a través de un par o un middlebox que no la conserva.

Esa regla de retorno delimita la evidencia. Ver una opción en un paquete no prueba que un camino posterior la mantenga. Tampoco prueba quién usa la aplicación, qué permiso tiene, a quién pertenece una dirección o cómo se comportará una ruta en el futuro.

La historia documental tiene el mismo límite. RFC 6824 presentó MPTCP v0 en 2013 como protocolo Experimental: material para examen, implementación y evaluación, no una norma de Internet. RFC 8041 reunió en 2017 experiencia operacional fechada. RFC 8684 sustituyó v0 en 2020 con una especificación Standards Track y atribuye sus aclaraciones y cambios sobre todo a la experiencia de despliegue. Este recorrido permite hablar de revisión informada por la práctica; no permite inferir cuota actual, configuración de un producto ni beneficio universal.

El Token resuelve una búsqueda local

Cuando ya existe la conexión, un host puede iniciar otro subflujo. El SYN inicial MP_JOIN lleva el Token del receptor, un nonce recién elegido por el emisor y un Address ID. Con SHA-256 en v1, el Token es el truncamiento de 32 bits altos del hash de la clave inicial del receptor. El receptor lo usa para localizar la conexión MPTCP local que el SYN pretende ampliar.

Esa es una búsqueda de estado. No es un permiso transportable.

La precisión temporal es importante. Durante el SYN, el nuevo subflujo aún no tiene un cinco-tupla que el estado MPTCP anterior conozca como suyo. Por eso el Token realiza el demultiplexado de admisión. Después de crear el subflujo, el TCP ordinario demultiplexa sus paquetes por el cinco-tupla. El Token no viaja como una identidad permanente de todos los paquetes ni reemplaza las comprobaciones TCP.

El Address ID tampoco dice lo que una lectura apresurada podría atribuirle. Lo genera el emisor para reconocer la dirección fuente aun cuando NAT haya cambiado el encabezado IP observado por el receptor. Sirve para correlación y retirada de direcciones sin exigir una vista idéntica del cable. No demuestra titularidad de IP, derecho a anunciar una ruta ni autorización fuera de esta conexión.

La prueba criptográfica no elimina el derecho a rechazar

La localización por Token necesita una prueba adicional. El receptor devuelve un nonce y un HMAC truncado; el iniciador contesta con su HMAC. Las claves proceden de la negociación MP_CAPABLE y ambos nonces hacen que una captura antigua no baste para repetir este intento de incorporación.

Si los HMAC verifican, RFC 8684 afirma algo delimitado: ambos hosts han comprobado que son los mismos pares MPTCP que existían al inicio y han acordado qué conexión recibe el subflujo. No afirma identidad de persona, autorización de negocio, propiedad de la dirección, éxito de una petición o permanencia de un efecto.

La política local sigue visible en el protocolo. Si el Token es desconocido, el receptor responde con RST. Si el Token es conocido pero la política local prohíbe aceptar un nuevo subflujo, también responde con RST. Un HMAC ausente o incorrecto cierra el subflujo. Encontrar una fila de estado no obliga al dueño de la tabla a abrirla; una prueba correcta no convierte el transporte en una autoridad de aplicación.

De la incorporación a los hechos que siguen fuera de ella

Sólo después de estas decisiones el nuevo cinco-tupla pasa a ser uno de los flujos TCP administrados por la conexión MPTCP. Un registro de red puede por ello decir cosas bastante valiosas: que hubo negociación inicial, que se eligió una conexión mediante Token, que se verificaron HMAC y que un subflujo quedó establecido. No puede, con los mismos datos, decir que la petición aplicada fue aceptada, almacenada, autorizada o completada por un usuario.

La disciplina sirve para no construir una autoridad ficticia a partir de datos de transporte. Descubrir ubica un estado. La continuidad criptográfica vincula un intento con material previo. La política local admite o niega capacidad. La aplicación asigna significado a los bytes. Una conexión que conserva su flujo no absorbe esas cuatro jurisdicciones.

Fuentes y límites de evidencia

Las RFC citadas describen el diseño, los estados documentales y el comportamiento definido. No prueban uso actual, rutas físicamente separadas, conducta de un NAT concreto, rendimiento, cumplimiento de productos, identidad humana ni resultado aplicativo.