Hi, On 2014-7-28, at 17:48, Joe Touch <to...@isi.edu> wrote: > IMO, if you're not protecting the TCP header the solutions should not be > called TCP anything, nor should it be integrated as a TCP option. It's > basically just TLS with no signature on either end, and that ought to suffice > if that's all you really want. > > However, protection from rogue middleboxes is something I'd appreciate, and > that can't be done solely as a payload of the transport layer.
thanks for raising this. I think we have an ambiguity in the first sentence of the charter text, which reads: "The TCPINC WG will develop the TCP extensions to provide unauthenticated encryption and integrity protection of TCP streams." The ambiguity is whether by "TCP stream" we mean the payload bytestream (only), or the flow of TCP packets (incl. their headers). When I read this, I came away with understanding this to mean payload bytestream, partly because it says stream and not connection. But reading it again I fully see that people can also understand this to mean TCP connection, which is why we are having discussions about protecting header fields, etc. I think the WG needs to clarify what is meant here. Lars _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
