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. 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? 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? Michael -----Original Message----- From: Tcpinc [mailto:tcpinc-boun...@ietf.org] 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 Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
