Re: Failed TCP connection reset when processing overlapping data segments

[Anil Madhavapeddy <avsm2@xxxxxxxxxxxx>]

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>