> 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.
Of course it is. And of course we want to protect at least part of the TCP header, detect changes, and leave policy decisions to whoever manages the nodes. Let look at TCP + crypto. It has to compete with two established standards. On one hand, TLS, which is easily deployed but does not protect any of the TCP headers. On the other hand, IPSEC, which is harder to deploy but does protect the TCP header. A secure version of TCP only makes sense if it protects the headers better than TLS and is easier to deploy than IPSEC. Preferably much easier. The addresses and ports are part the header but cannot be protected because they are fudged by NAT. That's regrettable, but the presence of a secure association mitigates that. Apart from addresses and ports, pretty much everything else should be protected. Yes, we could go on an inventory of existing threats and try to carve out the least common denominator that would mitigate these known threats. But then, we would never know which new threat we are missing. Much better to protect the whole header, minus addresses and ports. -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
