Doesn't this same basic problem happen in this simple case? On Thu, May 22, 2025, at 00:59, David Benjamin wrote: > 1. Client sends request > > 2. Server reads request > > 3. Server sends response > > 4. Server closes connection > > 5. Client reads response > > 6. Client closes connection
Maybe the client is not pushing data at the server after step 4, but there is a chance that the client believes that some TCP segment was lost, causing the client to retransmit what it thinks is lost. When that retransmission arrives at the server, the server might generate a RST in response if it has discarded state. The same applies if the client has any cause to send more data at that point. That is, in a slightly more complex protocol interaction. The underlying problem is that the server is closing and discarding state prematurely. That's a general problem with TCP. State synchronization in protocols is a challenging problem and ultimately any clean transition, whether it be connection establishment or closure, requires three messages or 1.5 RTT to execute. You can try to use timers, if you are willing to accept some rate of things being left hanging, which is what most session close arrangements end up using, because that's often good enough. There's a bunch of text in QUIC, where we "solved" this problem using timers after spending a bunch of time on trying to find something better than the full 1.5 exchange. The general advice I'd give is to not discard state immediately after initiating a close, at least for long enough to ensure that any delayed activity doesn't trigger an unwanted reset reaction. _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
