On 4/28/2016 10:00 AM, David Mazieres wrote: > Joe Touch <to...@isi.edu> 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.
If the sidechannel measures the overall flow by essentially random sampling, sure. But, as you note, there's no guarantee that the sidechannel would correlate to a specific TCP segment or its header (including options). > ... > 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. You can layer anything you want on top of TCP, including TCP. Ultimately, the only way to get around middlebox behavior is to do this, but then we'll end up with middleboxes that parse the inner packet and reassemble them. We've already seen this escalation with IP option use and tunnels and V6OPS is finally starting to pushback, saying that we need to hold the ground that routers may be required to deal with hop-by-hop IP options (silly me - I thought this was a requirement of RFC2460). Ultimately, as I've said there, until the ISOC creates a compliance mechanism, we have to do the best we can, which sometimes means interoperating and sometimes means pushing back. Joe _______________________________________________ Tcpinc mailing list Tcpinc@ietf.org https://www.ietf.org/mailman/listinfo/tcpinc
