Resumen

  • El RFC 5961 acepta de inmediato un RST de una conexión establecida solo si su secuencia coincide exactamente con RCV.NXT; si está dentro de la ventana pero no coincide, responde con un Challenge ACK y lo descarta.
  • La misma prueba protege frente a SYN ciegos, mientras una comprobación opcional de ACK reduce la inyección de datos y un límite configurable contiene el coste de responder.

La debilidad histórica no era la ausencia de números de secuencia, sino la autoridad concedida a cualquier valor dentro de la ventana de recepción. Un atacante fuera del camino podía emitir RST falsos separados por ventanas probables hasta acertar y cerrar la conexión.

RFC 5961 reduce esa autoridad. Un RST fuera de ventana se descarta en silencio. Solo la coincidencia exacta con el siguiente byte esperado cierra de inmediato. Un valor dentro de la ventana pero no exacto provoca <SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>; el segmento se elimina y la conexión continúa.

El desafío obliga al par a mostrar estado

El ACK no autentica al emisor. Pregunta por su estado. Un par legítimo que ya eliminó la conexión no conserva el bloque de control y responde con otro RST derivado del acuse. Ese segundo reset coincide exactamente. El atacante ciego normalmente no ve el desafío y no puede completarlo.

En estado sincronizado, un SYN también genera un Challenge ACK sin importar su secuencia, se descarta y espera que un par realmente reiniciado confirme el cierre. En SYN-SENT, el RST solo vale si su ACK reconoce el SYN. Persiste un caso raro: si el par reutiliza el mismo cuádruple y elige justo RCV.NXT-1, puede ignorar el desafío y agotar sus retransmisiones.

La inyección de datos requiere dos aciertos

La mitigación opcional de datos restringe el ACK aceptable al intervalo entre SND.UNA-MAX.SND.WND y SND.NXT. MAX.SND.WND guarda la mayor ventana recibida del par, incluido su escalado. Esto reduce también la probabilidad de FIN falsos, pero no elimina la inyección. Por ello, RST y SYN reciben fuerza SHOULD; la protección de datos, MAY.

Cada desafío consume CPU y ancho de banda. El RFC recomienda limitación configurable. Diez ACK en cinco segundos es solo un ejemplo empírico. Un límite bajo protege recursos pero retrasa la limpieza de estado obsoleto; uno alto acelera esa limpieza y admite más trabajo de respuesta.

Un middlebox no conforme puede repetir RST mal numerados y sostener un intercambio RST/ACK. El límite debe contenerlo. Un paquete falsificado puede reflejar un ACK, pero no hay amplificación: cada respuesta exige un segmento del atacante.

La única fuente es el RFC 5961, publicado en Standards Track en agosto de 2010. Eleva el coste del atacante fuera del camino, pero no autentica TCP, no detiene a quien observa el camino ni cubre ICMP falsificado. IPsec AH o ESP representa la frontera de protección completa. Un desafío demuestra falta de autoridad, no malicia.