On 3/13/2015 2:51 PM, Christian Huitema 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 already 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?
NATs that use RST or FIN to explicitly remove an entry are vulnerable to spoofing for either kind of packet, but then they were also vulnerable to spoofing of the SYN too (which could have flooded their tables). > Joe, do you have a design that solves that? Short of giving the NAT an authentication key, there's no solution to any of these behaviors - but that's true regardless of whether the headers are integrity protected and authenticated or not. The only solution where endpoints track NAT behavior is one where there is no authentication. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
