I think there are three common (legit) uses of RST: 1. In response to a SYN to indicate no-one is listening. 2. In mid connection, commonly used to avoid having to hold time-wait state. 3. After a reboot, to optimize timing out an old connection.
Of these, 1 isn't an issue for TCPINC - it's pre-handshake, so we wouldn't change anything. 2 is OK - these RSTs could be authenticated. 3 is problematic, but I suspect it isn't actually anyway near as common as 1 and 2, and ignoring such RSTs wouldn't really be a big deal. In the end, this is a tradeoff, and we can argue which side of that tradeoff we'd prefer to be on: hardened against DoS vs optimize an uncommon case. As Dave says though, this is a local choice, and even if the protocol supports it, not all hosts and/or apps need to enforce RST protection. Mark On Mon, Jul 28, 2014, at 08:57 AM, David Mazieres wrote: > marcelo bagnulo braun <[email protected]> writes: > > > Hi, > > > > As we discussed in the meeting, we should try to make some design > > decisions for TCPINC. > > One of them is whether to protect or not the TCP header. > > I would like to start the discussion on this topic. Arguments on one way > > or the other? > > Can we rephrase the question slightly and ask: "Which TCP header fields > are worth protecting?" Obviously one way forward is to protect nothing > in the headers. But I don't think anyone is advocating protecting the > whole header. (After all, the charter talks about NAT traversal.) > > At the meeting, I also sensed widespread agreement that people > (including me) consider always protecting the RST bit somewhat > problematic, particularly in the short term. That's why, for instance, > tcpcrypt says implementations SHOULD disable RST validation by default. > On the other hand, there are some very good use cases where you do want > protection against RST, as evidenced by multiple previous ways to do so. > > If we are going to protect any header bits at all, I argue it makes > sense to have a per-connection option to protect against RST, because > the benefit/cost ratio is very high. It's trivial to condition the > header integrity check on RST being clear or some socket option being > set. Conversely, for proposals that aren't designed to protect any > other header bits, adding RST protection could be a big burden. > > A common-sense guideline would be to say once we converge on a > high-level tcpinc design, we shouldn't leave any low-hanging fruit. > (This is the same logic by which the charter requires authentication > hooks, even though our anticipated use case is to protect unmodified > legacy applications against passive eavesdroppers. If we go through all > the trouble of standardizing increased TCP security, it's silly not to > let people authenticate connections.) > > David > > _______________________________________________ > Tcpinc mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
