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
