On 3/15/2015 3:04 PM, Olivier Bonaventure wrote: > Joe, > >> ... >>>> 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. >> ... >>>> Joe, do you have a design that solves that? >> >> Actually, to be more direct: >> >> Don't use a NAT. >> >> when you're behind a NAT, you're beholden to how the NAT interacts with >> the Internet, and *you* are on a private communications system that is >> decidedly NOT the Internet. > > I agree that the Internet would be easier without NATs, but looking at > the TCPINC charter, the first requirement for TCPINC is : > > "The high-level requirements for the protocol for providing TCP > unauthenticated encryption and integrity protection are: > - It should work over the vast majority of paths that unmodified TCP > works over, in particular it must be compatible with NATs (at the very > minimum with the NATs that comply with BEHAVE requirements as > documented in RFC4787, RFC5382 and RFC5508)." > > > This requirement has been met by Multipath TCP. TCPINC should also aim > at meeting this requirement.
Sure, but there will never be a NAT that prevents an off-path RST attack from DOSing a connection. Once you accept that NATs have control over your connection but you don't have control over NATs, you're done with claiming protection from NAT-directed attacks. That's true for ALL TCP approaches though NATs. Joe _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
