Hi Joe,
On 27.04.2016 19:50, Joe Touch wrote:
Hi, all,
TCPINC decided not to include any protection for the TCP header.
TCP options are part of the TCP header.
Sorry, but I have absolutely no idea why they would be asking now for a
way to protect part of the TCP header when they've already so clearly
decided otherwise.
To my understanding the reason to not encrypt the header was that some of the
header information is need to pass middleboxes, such as for sure the ports
but also some of the flags and maybe even the seq#. However, I think options
or at least some of the options are less critical.
If you're not protecting things like IP addresses, ports, or - more to
the point -the TCP header length field, I have no idea what it even
means to claim you're protecting options.
The main reason is to avoid (easy) leakage of privacy-sensitive information
that could be used to identify different connections or different IP
addresses that belong to the same host.
Mirja
Joe
On 4/26/2016 11:50 PM, Mirja Kühlewind wrote:
Hi all,
I briefly brought this up in the last meeting and would like to start the
discussion on the mailing list now. The working group decided that tcpinc will
not encrypt the TCP header for good reasons. However, it would still be
possible to encrypt TCP options. This could help keeping confidentiality and
would avoid that a middle could alter information in a option or strip it. Not
sure if there is a case where some options should be encrypted and some not but
I guess that would be possible as well. Any thoughts?
Mirja
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
