MSS, WS, SACK, and TS are part of the standard TCP header. Moving these options elsewhere would change not only the TCP header but affect the fundamental TCP/IP protocol architecture. This would have to be brought up at least in TCPM, IMHO.
I do not deal with middleboxes but I think the following has been discussed in the IETF in the last decades: * MSS option: As already mentioned, this is often modified e.g. in xDSL networks (MSS clamping) * WS: SYN only option, i.e. hard to encrypt, has to be read by Wireshark, stateful firewalls, etc. to determine whether a TCP segment is in-window, also has to be understood by TCP PEPs that reduce RWND (e.g., to prevent congestion on a last hop) * SACK: May perhaps be used by transparent TCP caches that transparently retransmit segments (e.g., in SATCOM environments), probably also read by anomaly detection systems, stateful firewalls, packet loss estimation in network analytics, etc. * TS: Probably used for RTT estimation in network analytics, possibly also some CG-NAT use, etc. And I am pretty sure this list is not comprehensive in particular regarding network analytics and dynamic traffic engineering. TCPM contributors may know more. For measurement purposes any application protocol running on top of TCP could copy the content of TCP options into an application layer protocol structure. Unless I miss something, I think measurement is completely orthogonal to encryption. Michael -----Original Message----- From: EXT Mirja Kühlewind [mailto:mirja.kuehlew...@tik.ee.ethz.ch] Sent: Thursday, April 28, 2016 11:07 AM To: Scharf, Michael (Nokia - DE); tcpinc Subject: Re: [tcpinc] Encryption of TCP Options 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: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
