Jozsef Kadlecsik wrote:
The TCP sequence numbers *are* tracked and checked - but with the limit of a node being in the middle of the two communicating endpoints. That limit is physical and cannot be discarded.
That said, would it be safe to say that if conntrack has already seen a certain sequence number in one direction, then a RST packet with less than sequence number + 1 is automatically invalid?
To take my original example, if the client sends a legitimate packet with sequence number 421, then sends a following RST packet that also has sequence number 421, the RST packet *must* be bogus, and will (hopefully) be ignored by the server.
I realize that in practice, when our node-in-the-middle forwards the two seq=421 packets to the server, the first ("real") packet could be lost. Or perhaps the two packets arrive at the server in the other order. Either case will cause the server to see the bogus RST packet before it sees the "real" packet, and the server will "incorrectly" accept the bogus RST. And I don't see a way for conntrack to detect whether this happened.
However, it seems much more likely that the server will "correctly" reject the RST. Perhaps conntrack should assume that, instead? It would be correct more often, and it's also less harmful if we're wrong: when we receive data that violates the TCP standard, it seems better for conntrack to decide that a connection is still open when it's not, than to decide that a connection is closed when it isn't.
-- Robert L Mathews, Tiger Technologies http://www.tigertech.net/ -- To unsubscribe from this list: send the line "unsubscribe netfilter" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
