Resumen

  • El servidor puede codificar estado provisional verificable en su número de secuencia inicial y esperar a que el ACK final lo devuelva antes de reservar un registro SYN-RECEIVED.
  • Ese retorno prueba acceso reciente a la ruta de respuesta del cuádruple observado. No autentica a una persona, no legitima la petición y no garantiza que la aplicación tenga recursos.
  • La admisión sin estado comprime la negociación en 32 bits. El disparador, las opciones recuperables, el comportamiento ante pérdidas y los cuellos de botella posteriores pertenecen a la implementación desplegada.

En una apertura pasiva convencional, el servidor se compromete primero. Llega un SYN, la pila entra en SYN-RECEIVED, genera un SYN-ACK y guarda datos de la conversación incompleta mientras espera el acuse final. El remitente todavía no ha mostrado que recibe tráfico en la dirección que presentó, pero ya ocupa una entrada de una cola finita.

El SYN flood explota ese intervalo. Un flujo de inicios que nunca terminan deja obligaciones pendientes hasta que expiran o se retransmiten. Cuando la cola embrionaria se llena, un cliente legítimo puede quedarse fuera aunque la aplicación, la red o las conexiones establecidas no hayan agotado todavía sus propios recursos. RFC 4987 acota así el problema: se ataca el estado de establecimiento; no se demuestra por ello que todos los demás presupuestos estén saturados.

Las mitigaciones reparten el daño de maneras distintas. Ampliar la cola conserva más intentos, pero expone más memoria. Acortar el temporizador recupera entradas, aunque castiga a rutas lentas o con pérdidas. Reciclar lo antiguo convierte la edad en criterio de selección. Un SYN cache retiene una ficha reducida. Un proxy acepta el primer compromiso en otra máquina y cambia el lugar donde se aplican la semántica y el riesgo.

El SYN cookie elimina la ficha provisional. El servidor elige su número de secuencia inicial para que transporte una descripción comprimida de la tentativa y una comprobación ligada a un secreto. Los esquemas históricos combinan el par de direcciones y puertos, el número inicial del cliente, un contador temporal que avanza despacio, una clase de MSS y secretos locales. No existe un algoritmo universal impuesto por el RFC; cada implementación decide cómo reparte los bits y rota sus claves.

El cliente no participa en esa decisión. Recibe un SYN-ACK normal y responde con el número del servidor más uno. Cuando vuelve el tercer ACK, el servidor recupera el valor, considera los intervalos temporales que aún acepta y vuelve a calcular la función secreta sobre el cuádruple que observa. Si coincide, reconstruye lo necesario y crea el estado ESTABLISHED. Si no coincide, descarta el paquete sin consultar un registro que nunca almacenó.

Por eso el cookie se parece a un recibo que el solicitante carga por cuenta del servidor. Demuestra que alguien accedió recientemente al SYN-ACK dirigido a ese camino, ya fuera por recibirlo o por observarlo. Esa evidencia puede bastar para autorizar una pequeña asignación local. No dice quién es el usuario, qué empresa representa, qué pretende hacer ni cuánto costará atenderlo.

La resistencia a la adivinación protege el recibo frente a un atacante fuera de ruta. No convierte TCP en autenticación criptográfica. Un observador en ruta ve el intercambio; una botnet con direcciones reales puede devolver miles de cookies válidos. Después de entrar, cada conexión puede gastar memoria establecida, negociación TLS, procesos, consultas, colas y cuotas. La defensa retrasa un compromiso, pero no certifica la conducta posterior.

El coste de no recordar aparece en el presupuesto de información. El número de secuencia tiene 32 bits y no deja de ser un número TCP. Una ficha normal podría guardar todas las opciones que llegaron con el SYN. Un cookie básico debe reservar bits para frescura, integridad y parámetros imprescindibles. Las construcciones clásicas solo codificaban, por ejemplo, un índice pequeño entre varios valores habituales de MSS. Todo dato que no quepa y no pueda deducirse del ACK se pierde para la reconstrucción.

Window Scale muestra por qué no se trata de una molestia decorativa. RFC 7323 limita su negociación a segmentos con SYN y fija el factor de cada dirección al abrir la conexión. Si el servidor olvidó la oferta y su formato de cookie no la recupera, no puede inventarla después del tercer paquete. RFC 4987 documentó compromisos históricos sobre escalado, SACK y otros estados; también describió un diseño de FreeBSD que reutilizaba bits devueltos por Timestamp para recuperar más opciones.

La conclusión debe ser específica. No todos los sistemas pierden siempre Window Scale o SACK. Tampoco todos los conservan porque una implementación moderna haya ampliado su codificación. El resultado depende del kernel, la versión, la tarjeta, el offload, el balanceador y el oyente que recibe la producción. La documentación general solo identifica el lugar donde verificar.

Una pérdida en el último tramo puede cambiar la experiencia. RFC 4987 usa el caso de un protocolo donde el servidor habla primero, como SMTP. El cliente envía el ACK final y espera un saludo. Si ese ACK se pierde, el servidor sin estado no tiene una entrada desde la que retransmitir su decisión y aún no ha avisado a la aplicación. La recuperación depende de retransmisiones posteriores y del comportamiento concreto. Ahorrar memoria modifica qué lado descubre antes el silencio.

La operación híbrida limita mejor ese coste. En condiciones normales, una cola o un SYN cache conserva negociación y retransmisión completas. Solo cuando un umbral local se desborda, el servidor pasa a cookies en vez de expulsar una petición ya guardada. Así, la defensa es un modo de emergencia con una condición de entrada y otra de salida, no una redefinición permanente de TCP.

La documentación actual de Linux hace esa distinción. Presenta tcp_syncookies como respaldo cuando se desborda el SYN backlog del socket y advierte que no debe utilizarse para soportar una tasa legítima que la máquina no puede atender. tcp_max_syn_backlog gobierna por separado cuántas solicitudes SYN_RECV recuerda cada oyente. Si el tráfico ordinario mantiene activo el respaldo, hay un problema de capacidad, cola o servicio que el cookie no debe ocultar.

Quedan otros presupuestos abiertos. El host sigue recibiendo y analizando paquetes, calculando cookies, enviando SYN-ACK y validando retornos. El enlace, las interrupciones, las colas y la CPU se pueden agotar. Tras el establecimiento, se pueden llenar la accept queue, los sockets, la criptografía y la aplicación. Una defensa es correcta aunque el atacante se mueva a otra capa; la organización falla si no observa esa capa siguiente.

La validación de direcciones de origen responde a una pregunta complementaria. BCP 38 y BCP 84 dificultan que una red exporte paquetes con fuentes falsificadas. Reducen respuestas inútiles hacia víctimas o direcciones inventadas, pero no detienen a máquinas reales que completan el diálogo. El borde de origen limita lo que deja salir; el servidor limita cuándo gasta memoria. Son autoridades independientes.

La telemetría tiene que reconstruir el proceso que el mecanismo ha borrado de la tabla. RFC 4898 distingue eventos de la cola embrionaria, asignación completa de recursos y aceptación por la aplicación, y señala que un sistema con SYN cookies no representa explícitamente el estado SYN-RCVD codificado. Una gráfica plana de conexiones incompletas puede ser tranquilidad o puede ser amnesia deliberada.

Conviene unir llegadas SYN, SYN-ACK, retransmisiones, ocupación y desbordes, cookies emitidos, retornos válidos, inválidos y caducados, conexiones establecidas, accept queue y aceptaciones de la aplicación. También hay que muestrear MSS, Window Scale, SACK, Timestamp, ECN y Fast Open en conexiones normales y reconstruidas. Si el cambio de modo no deja rastro, el operador pierde el hecho que más necesita conocer.

TCP Fast Open añade datos de aplicación al SYN bajo otro sistema de cookie y otro modelo de repetición. RFC 7413 no permite presumir que un fallback SYN-cookie tradicional conservará esos datos. Los frontales, balanceadores, offloads y kernels deben probarse juntos. La presencia del mismo nombre informal —cookie— no vuelve equivalentes sus contratos.

SCTP ofrece un contraste arquitectónico. RFC 9260 reserva una State Cookie de longitud variable dentro de una apertura en cuatro pasos. Puede llevar la información de la asociación, un MAC, tiempo y vida útil. No es compatible con TCP ni reproduce su cookie compacto. Muestra, sin embargo, que aplazar estado es más fiel cuando el protocolo concede un recipiente explícito en vez de comprimir una negociación creciente dentro de un campo heredado.

La capa común puede fijar la interoperabilidad y advertir de los compromisos. No puede conocer la memoria, la latencia, la mezcla de opciones ni el coste posterior de cada servicio. El principio de especificación inicial mínima de Heng Lu deja esas elecciones futuras con quien ejecuta el sistema. La primacía del código exige después una prueba material: el sysctl escrito no es el resultado; lo son las conexiones que realmente sobrevivieron con sus opciones y su rendimiento.

Fuentes