Of these, I think TS is the only one with clear privacy tradeoffs: > On 28 Apr 2016, at 12:28, Scharf, Michael (Nokia - DE) > <[email protected]> wrote: > > 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.
Definitely used for RTT estimation in network analytics. :) Timestamp sequencing can be used to identify devices behind a NAT, and clock skew provides a few bits of entropy in fingerprinting devices regardless of NATs. Not clear that there's much benefit to TCPINC encryption of this option, though, because a more comprehensive solution to fingerprinting is to disable transmission of TS. Cheers, Brian > 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:[email protected]] > 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:[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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
