Change Details

Note: This change is to start a discussion not to push it as is. In summary, this change sets a TCP timeout after close() call to avoid client to be able to consume all available TCP connections by setting them in TCP closing states like FIN_WAIT_1. Context: A TCP application that does: 1. accept() 2. recv() 3. send() 4. close() After 4. close() the connection can sit in TCP stack in TCP closing state (e.g. FIN_WAIT1) for quite a long time. Enough time, to actually being able to consume all available TCP connections / mbufs. Note: FIN_WAIT_2 and TIME_WAIT closing states already have timeout / maximum protection. This is unchanged. Questions and Answers: a. What is a better TCP application behavior? Follow [1] advices with: 1. accept() 2. recv() 3. send() 4. Wait for read() == 0 condition 5. If got read() == 0 -> close() 4. If timeout: Set SO_LINGER = 0 + close() to force reset the connection Sadly we don't control all TCP application socket usage. b. Why it is not happening on Linux? Linux has net.ipv4.tcp_max_orphans. An orphan connection is a connection on which close() has been called on i.e. the application did "orphan" it. Once the maximum is reached, the connection is destroyed at close() time, no timeout, no recycling, just destroyed in place. Ruthless, but does the job. c. What kind of client to reproduce these long-lived FIN_WAIT_1 connection? A TCP client that opens a TCP connection, sends a valid TCP request and, never sends a FIN. [1] Security Assessment of the Transmission Control Protocol (TCP) https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf

Note: This change is to start a discussion not to push it as is. In summary, this change uses a TCP timer after a close() call to prevent the peer from consuming all available TCP connections by leaving them in closing states like FIN_WAIT_1. Context: A TCP application that does: 1. accept() 2. recv() 3. send() 4. close() After 4. close(), the connection can sit in a TCP closing state (e.g. FIN_WAIT1) long enough to consume all available TCP connections / mbufs. Note: FIN_WAIT_2 and TIME_WAIT closing states already have timeout / maximum protection. This is unchanged. Questions and Answers: a. What is a better TCP application behavior? Follow [1] advices with: 1. accept() 2. recv() 3. send() 4. Wait for read() == 0 condition 5. If got read() == 0 -> close() 4. If timeout: Set SO_LINGER = 0 + close() to force reset the connection Sadly we don't control all TCP application socket usage. b. Why it is not happening on Linux? Linux has net.ipv4.tcp_max_orphans. An orphan connection is a connection on which close() has been called on i.e. the application did "orphan" it. Once the maximum is reached, the connection is destroyed at close() time, no timeout, no recycling, just destroyed in place. Ruthless, but does the job. c. What kind of client can produce these long-lived FIN_WAIT_1 connections? A TCP client that opens a TCP connection, sends a valid TCP request and, never sends a FIN. [1] Security Assessment of the Transmission Control Protocol (TCP) https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf

Note: This change is to start a discussion not to push it as is. In summary, this change setuses a TCP timeoutr after a close() call to avoid clientprevent the to be able topeer from consumeing all available TCP connections by settleaving them in in TCP closing states like FIN_WAIT_1. Context: A TCP application that does: 1. accept() 2. recv() 3. send() 4. close() After 4. close(), the connection can sit in TCP stack ina TCP closing statee (e.g. FIN_WAIT1) (e.g. FIN_WAIT1) for quite a long time. Eenough time, to actually being able to to consume all available TCP connections / mbufs. Note: FIN_WAIT_2 and TIME_WAIT closing states already have timeout / maximum protection. This is unchanged. Questions and Answers: a. What is a better TCP application behavior? Follow [1] advices with: 1. accept() 2. recv() 3. send() 4. Wait for read() == 0 condition 5. If got read() == 0 -> close() 4. If timeout: Set SO_LINGER = 0 + close() to force reset the connection Sadly we don't control all TCP application socket usage. b. Why it is not happening on Linux? Linux has net.ipv4.tcp_max_orphans. An orphan connection is a connection on which close() has been called on i.e. the application did "orphan" it. Once the maximum is reached, the connection is destroyed at close() time, no timeout, no recycling, just destroyed in place. Ruthless, but does the job. c. What kind of client to recan produce these long-lived FIN_WAIT_1 connections? A TCP client that opens a TCP connection, sends a valid TCP request and, never sends a FIN. [1] Security Assessment of the Transmission Control Protocol (TCP) https://www.gont.com.ar/papers/tn-03-09-security-assessment-TCP.pdf