Mirja Kühlewind <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
