Re: Failed TCP connection reset when processing overlapping data segments

[Lucas Aubard <lucas.aubard@xxxxxxxx>]

Dear Anil, 

Thanks for the quick answer!

The weird behaviour we were refering to is that mirage does not accept the 
initiator's TCP connection RST termination when encoutering overlapping data 
segments (if the initiator previously sent more data than acknowledged by 
mirage). However, it cannot really be qualified as "weird", since it is 
expected that the initiator's SND.NXT be different with mirage's RCV.NXT 
(because of mirage overlapping segments' drop), and thus, that the termination 
fails. 

We suppose that the "most conservative option" you mention thus refers to 
"dropping overlapping data segments". Is that correct? 

Here is what the latest TCP RFC (9293) says about overlapping TCP data segments:
- 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, we believe that accepting overlapping 
data segments is the most RFC-compliant behaviour. 
For what it's worth, we tested different OS families (e.g., Linux, Windows, 
BSD) with the same TCP overlapping test cases as mirage. All of them reassemble 
overlapping data segments. 

Best regards, 
Lucas Aubard.


----- Mail original -----
> De: "Anil Madhavapeddy" <avsm2@xxxxxxxxxxxx>
> À: "Lucas Aubard" <lucas.aubard@xxxxxxxx>
> Cc: "mirageos-devel" <mirageos-devel@xxxxxxxxxxxxxxxxxxxx>, "Johan Mazel" 
> <Johan.Mazel@xxxxxxxxxxx>, "gilles guette"
> <gilles.guette@xxxxxxxxxxxxxxxxx>, "Pierre Chifflier" 
> <Pierre.Chifflier@xxxxxxxxxxx>
> Envoyé: Lundi 31 Mars 2025 18:37:20
> Objet: Re: Failed TCP connection reset when processing overlapping data 
> segments

> Dear Lucas,
> 
> You've really taken me down memory lane now; I wrote this part of the stack
> about 15 years ago! If I remember correctly, TCP's behaviour is undefined when
> there are multiple overlapping segments, and so the implementation can define
> its own behaviour here.
> 
> I remember referring to Section 4.3.2 of the classic paper by Ptacek on this.
> https://insecure.org/stf/secnet_ids/secnet_ids.html
> This defines all the different OS behaviours for overlapping segments, and
> they're all different.
> 
> So from a high level perspective, I remember picking the most conservative
> option, but I don't remember all the details without diving into git 
> (actually,
> svn) history. What behaviour are you expecting to happen below? Is the "weird"
> behaviour you are seeing simply a deviance from Linux TCP/IP reassembly
> semantics, or is there some reassembly property not being maintained that you
> would expect to be?
> 
> best,
> Anil
> 
> 
>> On 27 Mar 2025, at 15:03, Lucas Aubard <lucas.aubard@xxxxxxxx> wrote:
>> 
>> Dear mirage-tcpip development team,
>> 
>> I am Lucas Aubard. I am a PhD student in an Inria lab in Rennes, France.
>> This PhD is supervised by Gilles Guette (IMT Atlantique), Pierre Chifflier
>> (ANSSI) and Johan Mazel (ANSSI).
>> 
>> During our research work, we analyzed mirage-tcpip 9.0.0 reassembly when
>> processing overlapping TCP data segments. We noticed something weird for some
>> of our test cases.
>> 
>> The testing scenario for every test case is as follow:
>>     • a handshake is initiated from 192.168.56.200 host to 192.168.57.203
>>     mirage-tcpip host, targetting its TCP Echo port 7.
>>     • the overlapping data chunks are sent from the initiator.
>>     • the initiator resets the TCP connection with a RST+ACK packet.
>> Every packet that mirage-tcpip host echoes back is acknowledged by the
>> initiator.
>> 
>> In the impacted test cases, mirage-tcpip echoes some data but not the maximum
>> possible amount of data. In fact, from what we observe across mirage test 
>> case
>> reassemblies, it does not echo back overlapping data segments. This may be
>> related to this part of mirage-tcpip code
>> https://github.com/mirage/mirage-tcpip/blob/6766a3f0b34695e19797a1264697d3dd1343c73e/src/tcp/segment.ml#L151.
>> The following termination of the TCP connections with a RST+ACK packet fails.
>> We believe that mirage-tcpip considers that the RST+ACK packet sequence 
>> number
>> is invalid because it is located after all sent data (including the 
>> overlapping
>> segments). Since mirage-tcpip does not echo the maximum possible amount of
>> data, we hypothesize that the initiator SND.NXT internal variable is not the
>> same as the RCV.NXT value in mirage-tcpip.
>> 
>> Attached are the pcap files and plots for some (random) overlap test cases
>> illustrating the problem.
>> You can see in the pcap files that mirage-tcpip sends an ACK after the 
>> RST+ACK
>> packets whose acknowledgment is not related to the last data sent by the
>> initiator.
>> This means that mirage does not consider the sequence number of the RST+ACK
>> packet as valid, ignores this RST+ACK packet, and does not close the TCP
>> connection. Mirage here expects data that follows the last valid data it
>> observed.
>> 
>> Can you confirm that our understanding of the mirage-tcpip TCP stack 
>> behavior is
>> correct, in particular in term of data overlap and sequence number 
>> processing?
>> 
>> Best regards,
> > Lucas Aubard.<pcaps.zip><plots.zip>