Hi Michael, see below.
On 27.04.2016 09:38, Scharf, Michael (Nokia - DE) wrote:
I think this could be done for non-SYN options that do not modify the semantics of the key TCP header fields. But there are not to many of those options and putting them inside TCPINC gets relatively close to developing a new shim layer transport inside a "TCPINC tunnel". As far as I understand, encrypting MSS, WS, and SACK would be very challenging.
Can you further explain why?
Encrypting TS may be possible in some use case, but e.g. there have been TCPM discussions regarding leveraging TS in CG-NATs, so what would be the value?
I agree that there might be value to not encrypt TS, however, using this information in a middlebox is architecturally very unclear and a pity that we have too...
Fast open seems challenging as it is a SYN option. Regarding other options, MD5 and TCP-AO may typically not be used in combination with TCPINC. So, what options could realistically be encrypted? MPTCP?
Yes, I was actually thinking about some MPTCP options as they might reveal privacy-sensitive information that allows the network to identify that two connections/two IP addresses belong to the same endpoint. I was really only talking about encryption, not authentication. I don't think there is a middlebox out there yet that would miss this information or block the traffic if it could be encrypted, at least I hope that's not the case.
Mirja
Michael -----Original Message----- From: Tcpinc [mailto:[email protected]] On Behalf Of EXT Mirja Kühlewind Sent: Wednesday, April 27, 2016 8:50 AM To: tcpinc Subject: [tcpinc] Encryption of TCP Options 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
