Respuestas:
Un TCP ACK básico dice "Recibí todos los bytes hasta X". El ACK selectivo le permite decir "Recibí los bytes XY y VZ".
Entonces, por ejemplo, si un host le envió 10,000 bytes y se perdieron 3000-5000 en tránsito, ACK diría "Tengo todo hasta 3000". El otro extremo tendría que enviar bytes 3001-10000 nuevamente. SACK podría decir "Obtuve 1000-2999 y 5001-10000" y el host solo enviaría el 3000-5000.
Esto es excelente en un enlace de gran ancho de banda, con pérdida (o de alto retraso). El problema es que puede causar graves problemas de rendimiento en circunstancias específicas. Los TCP ACK normales harán que el servidor trate una conexión con pérdida de ancho de banda alto con guantes de niño (envíe 500 bytes, espere, envíe 500 bytes, espere, etc.). SACK le permite adaptarse a la gran demora porque sabe exactamente cuántos paquetes se perdieron realmente .
Aquí es donde pueden pasar cosas malas. Un atacante puede obligar a su servidor a mantener una cola de retransmisión masiva durante mucho tiempo, y luego procesar toda esa maldita cosa una y otra vez. Esto puede vincular la CPU, consumir RAM y consumir más ancho de banda de lo que debería. En pocas palabras, un sistema liviano puede iniciar un DoS contra un servidor más robusto.
Si su servidor es robusto y no sirve archivos grandes, está bastante bien aislado contra esto.
Si está sirviendo principalmente a una intranet u otro grupo de usuarios de baja latencia, SACK no le compra nada y puede apagarse por razones de seguridad sin pérdida de rendimiento.
Si está en un enlace de bajo ancho de banda (digamos 1 Mbps o menos como una regla general completamente arbitraria), SACK puede causar problemas en las operaciones normales al saturar su conexión y debe apagarse.
En última instancia, depende de usted. Considere lo que está sirviendo, a quién, de qué, y calcule el grado de riesgo frente a los efectos de rendimiento de SACK.
Hay una gran descripción de SACK y su vulnerabilidad aquí.
Otra razón por la que TCP SACK a menudo está deshabilitado es que hay una increíble cantidad de equipo de red que no puede manejar esta opción correctamente. Esto lo vemos todo el tiempo con un producto de transferencia de archivos de alta velocidad que ofrecemos que utiliza TCP. El problema más común es el de los dispositivos de puerta de enlace que hacen cosas como aleatorizar números de secuencia para paquetes TCP que transitan a través del dispositivo desde redes internas a externas, pero que no "des-aleatorizan" las opciones de TCP SACK que pueden enviarse desde el remoto fin. Si estos dispositivos no traducen los valores SACK reales a los valores correctos, entonces la sesión TCP nunca se completará ante la pérdida de paquetes cuando el extremo remoto intente usar SACK para obtener los beneficios ACK selectivos.
Probablemente esto sería un problema menor si las personas aplicaran de manera más agresiva el mantenimiento preventivo de software a este equipo, pero tienden a no hacerlo.
Puedo confirmar por amarga experiencia que tcp_sack = 1 causa una transferencia de datos estancada a través de sftp / rsync / scp, etc. con archivos que superan los 12 mb cuando se utilizan ciertos dispositivos de firewall Cisco ASA.
CADA vez se estancaría.
Estábamos transfiriendo a través de un enlace dedicado de 100 Mbps entre el host A y el host B en dos centros de datos diferentes, ambos usando el firewall de Cisco y el hardware del conmutador con centos.
Esto puede mitigarse algo modificando los tamaños del búfer, por ejemplo, no pude transferir un archivo de 1GB a través de sftp desde el host A al host B a menos que configuré el búfer sftp en 2048, pero podría independientemente si el host B extraía el archivo de A.
Los experimentos con el mismo archivo usando rsync y el ajuste del búfer de envío / recepción me permitieron levantar alrededor de 70mb de un archivo de 1GB empujado de A a B.
Sin embargo, la respuesta final fue deshabilitar tcp_sack en el host A. Inicialmente configurando tcp_sack = 0 en el kernel sobre la marcha, pero finalmente lo agregué a mi /etc/sysctl.conf