On 4/28/2016 3:47 AM, Mirja Kühlewind wrote: > Just one minor comment: Other than the TCP header itself, all this > information is optional, so a middlebox can never be sure that this > information will be available anyway.
However, it will interpret it as in-the-clear and modify it, regardless of whether you want it to or not. And if you make it look like it's "unknown", it will drop, split/copy, or coalesce/drop it, regardless of whether you want it to or not. The whole motivation for TCPINC - which is effectively TLS inside the OS on the TCP payload, even if that exact variant isn't what we ended up with - was to provide TLS-like protection without needing application involvement. If you want to protect the TCP header too, use TCP-AO, If you want to encrypt the TCP header and/or options, use TCP-AO-ENC. If you want to include the IP header in all of this, use IPsec. Don't get me wrong - I still think TCPINC is a mistake and that we ought to push back on the nonsense that many middleboxes create, but there's simply no valid reason for TCPINC to claim that the header isn't involved but the options are. To repeat more simply - "TCP options ARE part of the header". They're not this separate thing that you get to include in other ways on a per-option basis. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
