Hi,
the charter reads:
- must always provide integrity protection of the payload data (it is
open for discussion for the WG if the TCP header should or should not
be protected).
So, I dont think we can clarify this, since it is up to the WG to figure it out.
Makes sense?
Regards, marcelo
El 29/07/14 08:55, Eggert, Lars escribió:
Hi,
On 2014-7-28, at 17:48, Joe Touch <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
