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.
Olivier
--
INL, ICTEAM, UCLouvain, Belgium, http://inl.info.ucl.ac.be
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
