hi Mirja, all, Briefly, inline,
> On 28 Apr 2016, at 11:14, Mirja Kühlewind <[email protected]> > 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. Yep. I think the main win here, as David says below, would be protecting something a la HICCUPS, where hash information about the packet header would be tcpcrypt-protected, to allow endpoint detection of header manipulation. > 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? As an author of the SPUD requirements draft, this seems to me like a useful general purpose facility to have... Cheers, Brian >> David >> > > _______________________________________________ > 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
