> TCP is intended to protect TCP, not turn all TCP users into Multipath-lite > users. > > > With this kind of mechanism, a TCP variant can have the ability to > > react to spurious resets. > > Only if you substantively protect those connection ID tokens. Which means > you're protecting "header" information - and you;ave' made it worse by > protecting a header that doesn't even exist yet. > > It's a lot easier to protect the headers we alredy have.
Protecting against spoofed RST would be a very good thing indeed. But we want a solution that is robust in the presence of middle-boxes, and there is a generic issue there. Today, middleboxes like NAT and Firewall inspect the TCP flags. If they see an RST or FIN flag, they "know" that the connection is being terminated, and they proceed to release the associated resource, e.g., close the open holes in the firewall or remove the mappings in the NAT. After the middle box release the connection, further packets on that path will be dropped. What does that do to TCP-INC? Suppose we have a nice way to authenticate the headers. The attacker injects a spoofed RST message. The end points of the connection will observe that the message fails authentication, and they will drop it. But that's too late, because the middle-boxes on the path have also seen the message. They do not know the authentication key, so they have no way to know whether the RST is genuine or not. Most will continue doing what they are doing today, they will just assume that this is a bona fide RST. They will close the holes and drop the mappings. Further packets will be dropped. Joe, do you have a design that solves that? -- Christian Huitema _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
