Netstack does a few things incorrectly which results in odd test failures that pass on linux but fail on gVisor.
We should validate inbound segment handling in each state as specified https://tools.ietf.org/html/rfc793#section-2.7 page 69
We also need to verify which parts have been updated by RFC5961 to make TCP robust against attacks. eg. the following section describes handling of SYN's in synchronized state. Netstack today silently drops SYN's in synchronized state.
https://tools.ietf.org/html/rfc5961#section4.2
Eg. Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows:
-
If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further.
By sending an ACK, the remote peer is challenged to confirm the loss
of the previous connection and the request to start a new connection.
A legitimate peer, after restart, would not have a TCB in the
synchronized state. Thus, when the ACK arrives, the peer should send
a RST segment back with the sequence number derived from the ACK
field that caused the RST.
This RST will confirm that the remote peer has indeed closed the
previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to
re-establish the connection.
Netstack does a few things incorrectly which results in odd test failures that pass on linux but fail on gVisor.
We should validate inbound segment handling in each state as specified https://tools.ietf.org/html/rfc793#section-2.7 page 69
We also need to verify which parts have been updated by RFC5961 to make TCP robust against attacks. eg. the following section describes handling of SYN's in synchronized state. Netstack today silently drops SYN's in synchronized state.
https://tools.ietf.org/html/rfc5961#section4.2
Eg. Instead, the handling of the SYN in the synchronized state SHOULD be
performed as follows:
If the SYN bit is set, irrespective of the sequence number, TCP
MUST send an ACK (also referred to as challenge ACK) to the remote
peer:
<SEQ=SND.NXT><ACK=RCV.NXT><CTL=ACK>
After sending the acknowledgment, TCP MUST drop the unacceptable
segment and stop processing further.
By sending an ACK, the remote peer is challenged to confirm the loss
of the previous connection and the request to start a new connection.
A legitimate peer, after restart, would not have a TCB in the
synchronized state. Thus, when the ACK arrives, the peer should send
a RST segment back with the sequence number derived from the ACK
field that caused the RST.
This RST will confirm that the remote peer has indeed closed the
previous connection. Upon receipt of a valid RST, the local TCP
endpoint MUST terminate its connection. The local TCP endpoint
should then rely on SYN retransmission from the remote end to
re-establish the connection.