On Wed, May 21, 2025, 20:24 Martin Thomson <m...@lowentropy.net> wrote:
> 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. > With the caveat that I'm not a TCP expert and did most of my exploring here a whole back, no, that's not right. As I understand, that will not cause a RST. TCP would be truly non-functional if that were the case! If it's a retransmit of data you've received, I believe that's all fine. I expect it'll just ACK it. It's specifically data that will never be read that TCP treats as an error condition. 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. > Right, now that one TCP considers an error condition if the server closes the connection. Of course, if the server is expecting that data, having implemented an application protocol where that data exists, the server won't close the connection and presumably it'll eventually read the data. But TCP considers it an error condition if one side writes data that the other side doesn't eventually read. As far as I can tell, you're just not supposed to design protocols stop TCP where one side sends data that the other side is not always expected to read. Indeed simply saying "this was a mistake in TCP" is complicated. Suppose TCP did *not* treat this as a reset condition. Then we'd be in al position where the closed receiver never ACKs anything either, which means the other side can never progress its send window. If the other side is trying to write too much data to fit in the send window, it will get stuck. This is discussed in https://www.rfc-editor.org/rfc/rfc2525#page-50 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. > The application using TCP doesn't get a choice in what TCP does when closing a socket.TCP is simply defined so that extra data after a close is an error condition. Once it sees that error condition, it resets and all bets are off. (If it closes without this error condition, that is fine and you'll be in one of the various wait states for a bit to finish everything up like retransmitting stuff.) Likewise, TLS is somewhat constrained because it is sandwiched between an application layer that expects a TCP-like thing from TLS and expects TLS to run stop a TCP-like thing. If there is a general lesson it is that, when working on specifically TLS over TCP, we have to be wary of any time we write "out of turn" or "unexpectedly" from the point of view of the application. The TCP interface does not like it. And yeah a protocol that isn't layered atop TCP gets to invent all its own rules here and can avoid all this mess. But TLS over TCP still exists, so this is the world we're all in. These sorts of issues happen in reality and lead to weird flaky effects. Having diagnosed one, I like to send these just because, as long as we work on such protocols, I think it's useful to detail them to the WG for broader awareness. David >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
