TCP options define how a TCP segment and its header are interpreted. If you put them somewhere else, you need a synchronization mechanism to tie them back together.
I.e., you're defeating the idea of the header as a control channel for TCP. This is a very bad idea. Joe On 4/28/2016 2:14 AM, Mirja Kühlewind wrote: > Hi all, > > another idea would be to provide some side channel to transport > additional information such as potentially options instead of > encrypting the actual options. In this case we would probably rather > need a length field than a single bit (and then we could use the same > semantics as used for options to fill this field...). Just an idea... > probably need to further think about it. > > Mirja > > > On 27.04.2016 20:24, David Mazieres wrote: >> Mirja Kühlewind <mirja.kuehlew...@tik.ee.ethz.ch> writes: >> >>> 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? >> >> Encrypting existing TCP options strikes me as a bit complex, especially >> since at that point you might to authenticate them. >> >> That said, there's a related point which is that tcpcrypt, given its TLV >> structure, could easily offer some sort of side channel. In BA, Jana >> suggested there might be good uses for something like this. For >> example, suppose you want to collect information on what middleboxes are >> doing. You could transmit an advisory copy of the options in a special >> tcpcrypt frame and compare them at the receiving end. >> >> We are definitely open to accommodating such scenarios for the simple >> reason that it would be extremely simple. In fact, we currently have 6 >> unused bits in the flags field of a frame. We could easily say that the >> high bit means this is a control message and implementations MUST skip >> over control messages they don't understand. (Or partition the space >> using the other bits into some MANDATORY and a bunch of OPTIONAL >> skippable ones.) >> >> What do people think? >> >> David >> > > _______________________________________________ > 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
