On Wed, May 21, 2025 at 9:38 PM David Benjamin <david...@chromium.org> wrote: > > 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.
I for one definitely appreciate these kinds of emails. It could well save someone a late night (or a week of late nights) somewhere, even if it doesn't result in textual changes to an RFC to try to preempt the mistakes. > > David > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
