TCP reassembly issues when handling data overlaps #64
Description
Dear picoTCP development team,
During some research work we conducted with Gilles Guette (IMT Atlantique), Pierre Chifflier (ANSSI) and Johan Mazel (ANSSI), we analyzed picoTCP 1.7.0 (tass-belgium/picotcp) and picoTCP 2.1 (virtualsquare/picotcp) reassembly when processing overlapping and non-overlapping TCP data segments.
We observed multiple problems that impact differently picoTCP versions.
Since we could not find a dedicated email address to report the issues, we contact the main picoTCP contributors.
You can find PCAP and plot files attached that illustrate the described issues.
Testing setup
The testing scenarii have the following common characteristics:
-
- a handshake is initiated from 192.168.56.140 host to 192.168.57.143 picoTCP host, targetting its TCP Echo port 7.
-
- the test case's data segments are sent from the initiator. (*)
-
- the initiator resets the TCP connection with a RST+ACK packet, whose sequence number is located after to the test case's rightmost data byte (or at the beginning of the first hole if applicable).
Every packet that picoTCP host echoes back is acknowledged by the initiator.
- the initiator resets the TCP connection with a RST+ACK packet, whose sequence number is located after to the test case's rightmost data byte (or at the beginning of the first hole if applicable).
(*) this step may change across testing scenario.
Issue 1: original payload truncation on the right (observed with and without parallelization testing)
We remark from picoTCP reassemblies that it can reconstruct an original data segment only if all the segments are in order and contiguous. Indeed, if any segment is out-of-order, picoTCP echoes some data but not the maximum possible amount of data. picoTCP ignores any data segment that overlaps an already received data segment.
This observed behavior may be due to implementation choices. Is this behavior intended?
Here is what the latest TCP RFC standard 9293 state about overlapping data-related processing:
- in part 4 "Glossary" (https://datatracker.ietf.org/doc/html/rfc9293#section-4), part of the "receive window" definition states that "the local TCP endpoint considers that segments overlapping the range RCV.NXT to RCV.NXT + RCV.WND - 1 carry acceptable data or control. Segments containing sequence numbers entirely outside this range are considered duplicates or injection attacks and discarded.".
- in part 3.10 "Event processing" (https://datatracker.ietf.org/doc/html/rfc9293#section-3.10-9), there is a TCP implementation example. It is said about overlapping segments that "When a segment overlaps other already received segments, we reconstruct the segment to contain just the new data and adjust the header fields to be consistent".
Consequently, even if the specification is not really crystal clear about the behaviour implementations must adopt in the presence of overlapping data segments, we believe that accepting overlapping data segments is the most RFC-compliant behaviour. This is not the observed picoTCP behavior that ignore any overlapping data segment.
Moreover, picoTCP must fully reassemble out-of-ordered data segments (i.e., without data truncation).
This issue impacts picoTCP 1.7 and 2.1. See tests 7, 8, 9, 10, and 168.
Issue 2: original payload truncation on the left (observed only with parallelization testing)
We observe this issue in the following testing scenario:
- 2.a. a non-overlapping segment is sent with data "0" from relative sequence number 1 to 2. We name this segment Start.
- 2.b. the test case's (overlapping or non-overlapping) data chunks are sent from the initiator.
We note that the Start segment's data is not always echoed back whereas some test case's chunks are echoed back. This is problematic since the test case's chunk data starts to the right of Start's beginning.
This issue impacts only picoTCP 2.1. See test cases 382 and 478.
Issue 3: duplicates in payload (observed only with parallelization testing)
PicoTCP echoes back some already echoed data in some test cases. These duplicates are located at a wrong sequence number.
This issue impacts picoTCP 1.7 and 2.1. See test cases 376 and 456.