Resumen

  • RFC 793 aceptaba en estados sincronizados un RST cuyo número de secuencia estuviera dentro de la ventana; RFC 5961 exige coincidencia exacta con RCV.NXT para reiniciar de inmediato.
  • Si el RST está en ventana pero no es exacto, el receptor envía un challenge ACK y descarta el segmento: un par real puede confirmar su estado, mientras que un emisor ciego normalmente no ve la pregunta.

El problema comenzaba con una confusión entre dos permisos. La ventana de recepción responde si un segmento puede pertenecer al flujo. Sin embargo, la regla original de RFC 793 también dejaba que esa prueba de plausibilidad autorizara un acto distinto: eliminar todo el estado de la conexión cuando el bit RST estaba activo. Un atacante fuera del camino no necesitaba escuchar el tráfico; podía recorrer números de secuencia hasta acertar alguno dentro de una ventana suficientemente amplia.

RFC 5961 no intentó convertir TCP en un protocolo criptográfico. Introdujo una decisión intermedia. Un RST fuera de ventana se descarta en silencio. Uno cuyo número coincide exactamente con el siguiente byte esperado, RCV.NXT, reinicia la conexión. El caso peligroso —dentro de la ventana pero sin coincidencia exacta— produce un ACK con SEQ=SND.NXT y ACK=RCV.NXT; después, el receptor descarta el paquete sospechoso y continúa con los siguientes.

Ese ACK es un desafío porque exige una respuesta ligada al estado. Si el extremo remoto cerró de verdad o reinició y ya no conserva el antiguo bloque de control, al recibir el ACK puede devolver un nuevo RST cuyo número se deriva del reconocimiento. Esa segunda respuesta sí puede coincidir exactamente con lo que espera el extremo que mantiene la conexión. Quien inyecta a ciegas no observa el desafío y, por regla general, no puede transformar un acierto aproximado en la contestación precisa.

El cambio histórico no está en un campo nuevo del encabezado, sino en el reparto de autoridad. “Está dentro de la ventana” pasa a significar “merece una comprobación”, no “puede destruir”. Entre ignorar y cerrar aparece una operación reversible que conserva el estado mientras pide evidencia adicional.

RFC 5961 aplica una lógica parecida a un SYN inesperado cuando la conexión ya está sincronizada. La mitigación ordena enviar un challenge ACK sin depender del número de secuencia del SYN y abandonar su procesamiento. Un SYN falsificado suele provocar un ACK adicional que el par establecido desecha como duplicado. Si el otro sistema realmente se reinició, su ausencia de estado le permite reaccionar de forma distinta y confirmar que la conexión anterior debe terminar.

La defensa tiene límites expresos. No autentica identidades ni detiene a un adversario situado en el camino que observa secuencias y reconocimientos. El documento también conserva un caso extremo de reinicio en el que se reutilizan dirección y puerto y se elige por azar un número inicial particular. Se endurece el ataque ciego, pero no se elimina toda falsificación posible.

Las recomendaciones tampoco son uniformes. Las mitigaciones para RST y SYN son recomendadas; la comprobación más estrecha de ACK contra la inyección de datos es opcional. RFC 9293 sigue siendo la especificación base actual de TCP y remite a RFC 5961 como mejora de robustez. La historia es una superposición controlada: el arreglo posterior convive con la base, en lugar de fingir que la vulnerabilidad nunca formó parte del contrato.

Fuentes primarias