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 <[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
