Joe Touch <[email protected]> writes: > Hi, all, > > TCPINC decided not to include any protection for the TCP header. > > TCP options are part of the TCP header. > > Sorry, but I have absolutely no idea why they would be asking now for a > way to protect part of the TCP header when they've already so clearly > decided otherwise. > > If you're not protecting things like IP addresses, ports, or - more to > the point -the TCP header length field, I have no idea what it even > means to claim you're protecting options.
So my understanding of the sidechannel is that it could be used for things like measurement studies. It's obviously not going to be 100% right, since packets might get resegmented, etc. But it's also a fairly small change to make to tcpcrypt, so a small numerator makes the cost/benefit analysis is probably favorable. I think the high-level point is that doing anything that consumes option space and risks middlebox problems should be considered a large cost. So at that point we really need to maximize the benefit, which was already what we tried to do with the original version of tcpcrypt before the working group required TLV. Actually, there's one more thing we never showed the working group, which was an authenticated encryption mode that is robust to middlebox resegmentation, basically using cumulative authentication. We came up with that in response to objections about middlebox resegmentation, but it was too late as the working group had already gone to TLV and no header protection. That vastly complicates implementation but is by construction robust to pretty much any layer 4 or lower middlebox shenanigans. Of course, the advantage of ENO is that it doesn't completely shut the door on revisiting these decisions even after tcpcrypt is deployed, but I won't be holding my breath. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
