On Fri, Mar 13, 2015 at 9:51 PM, Christian Huitema <[email protected]> wrote: >> 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?
That it cannot be protected in all cases is not a reason to not protect in the cases where it can be; just like unauthenticated opportunistic encryption only gets you the potential for after the fact detection when there is a MITM. Seeking a pragmatic best effort outcome is, I think, what we want to accomplish with TCP-INC. _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
