Resumen

  • La razón histórica principal del saludo de tres vías es evitar que un SYN duplicado de una conexión anterior parezca una apertura nueva.
  • Cada extremo elige su número inicial. El servidor combina en el SYN-ACK la confirmación del número recibido y su propio número; el tercer mensaje demuestra que el iniciador vio ese desafío actual.
  • Quiet time, TIME-WAIT, los ISN con secreto y las SYN cookies responden a riesgos distintos. Ninguno convierte la frescura de TCP en autenticación de identidad.

Un paquete de otra conversación

Internet puede retrasar, duplicar y desordenar paquetes. Cuando una conexión se cierra, sus cuatro datos identificadores —dos direcciones y dos puertos— pueden reutilizarse antes de que desaparezca cada copia antigua. El receptor de un SYN no ve en él una fecha fiable: el paquete puede ser reciente o un residuo.

El RFC 761, de enero de 1980, formuló la solución mediante espacios de secuencia. Cada TCP escoge un número inicial de envío y aprende el del par. Esos números sólo ordenan correctamente si primero queda claro a qué encarnación de la conexión pertenecen.

Cuatro hechos viajan en tres mensajes

La sincronización exige que A anuncie X, B confirme X, B anuncie Y y A confirme Y. TCP une las dos frases de B: SYN X; SYN Y, ACK X+1; ACK Y+1.

SYN ocupa una posición en el espacio de secuencia, por eso se confirma con el siguiente número. Un ACK sin datos no ocupa otra posición; de lo contrario habría que confirmar indefinidamente cada confirmación. El RFC 793 fijó en 1981 este intercambio y sus estados.

No interviene un registro mundial de sesiones. Dos decisiones locales se vuelven compatibles porque cada lado recibe el número del otro y una prueba de que el propio fue observado.

El tercer paso verifica al iniciador

Después del SYN-ACK, el iniciador ya conoce el número del respondiente. Este último aún no sabe si el primer SYN pertenecía al presente. Una copia vieja podría haberlo despertado, aunque el host que la originó ya no conserve esa conexión.

El ACK final nombra el número actual del respondiente. Esa devolución cierra la incertidumbre. RFC 761 describió el mecanismo como un intercambio entre memoria y mensajes: en vez de recordar todos los números usados por cada pareja, se pide al aparente iniciador que confirme la ronda actual.

La afirmación es deliberadamente estrecha. Demuestra recepción dentro del modelo de TCP; no acredita persona, empresa, permiso de aplicación ni ausencia de un atacante que observe el camino.

Los números conservan una sombra temporal

El saludo filtra SYN antiguos, pero datos y ACK de una encarnación cerrada pueden seguir circulando. Las primeras especificaciones asignaron dos minutos a la vida máxima de un segmento. Si un reinicio borraba la memoria de secuencias, el host debía guardar silencio durante ese MSL; si retenía memoria, podía continuar más allá del espacio reciente.

TIME-WAIT mantiene el cuádruple durante dos MSL después de un cierre normal. Permite que mueran duplicados y que se repita el último ACK del cierre. El tiempo actúa como estado distribuido: impide que un número antiguo vuelva demasiado pronto con significado nuevo.

El estándar actual, RFC 9293, conserva la lógica, aunque considera normalmente innecesario el silencio tras reinicio. La aleatorización de puertos e ISN, la menor vida efectiva de los paquetes y la duración de los reinicios reducen el caso. Para enlaces rápidos, timestamps y PAWS protegen contra el recorrido veloz de los 32 bits.

El asesinato de TIME-WAIT

RFC 1337 mostró que TIME-WAIT podía terminar antes de tiempo. Un segmento antiguo provoca un ACK; el par, sin estado, responde con RST; aceptar ese reset “asesina” la espera. Si el mismo cuádruple se abre enseguida, datos o confirmaciones viejas pueden caer dentro de la ventana nueva.

El documento expuso aceptación de bytes erróneos, desincronización y fallo de conexión. La enseñanza es modular: el saludo protege la iniciación, las ventanas vigilan una conexión viva y TIME-WAIT separa encarnaciones. Que una defensa exista no vuelve prescindibles las otras.

Frescura no es identidad

La selección predecible de ISN abrió otro problema. Un atacante fuera del camino podía estimar la respuesta del servidor y fabricar el ACK esperado. RFC 6528 combinó un contador temporal con una función secreta del cuádruple. Cada relación obtiene un desplazamiento difícil de relacionar desde fuera sin perder la progresión temporal.

La mejora dificulta una conjetura ciega. No oculta la secuencia a quien observa el intercambio y no autentica al usuario. La pregunta “¿esta secuencia es actual?” sigue separada de “¿quién está al otro lado?”.

Estado aplazado dentro del desafío

Un servidor suele reservar memoria al recibir el primer SYN, antes de obtener prueba del cliente. Muchos SYN falsificados llenan la cola de conexiones a medias. RFC 4987 documentó la historia pública de los SYN floods desde 1996 y las mitigaciones comunes.

Una SYN cookie codifica en el número del SYN-ACK una función del cuádruple, el ISN cliente, el tiempo, algunos parámetros y un secreto. El servidor no guarda todo el bloque de control. Cuando llega el ACK final, valida la cookie y reconstruye el estado.

Así, el tercer mensaje sigue siendo la prueba, pero el gasto se desplaza hasta recibirla. El espacio disponible limita opciones y cada implementación elige compromisos propios.

La historia completa distribuye funciones: la red transporta, los extremos eligen, las confirmaciones crean estado común, el tiempo agota significados viejos, el secreto frena adivinanzas y la cookie pospone recursos. Ninguna función por sí sola es una autoridad de identidad.

Fuentes y límites de la evidencia

Los RFC establecen diseño y fallos concretos, no una fecha única de despliegue mundial. La interpretación de elecciones locales convertidas en estado compartido mediante prueba recíproca es una lectura arquitectónica de esos mecanismos.