Hi, Michio Honda has recently performed experiments on exactly these issues of extending TCP; the results are reported in an IMC paper to be published later this year that Michio and us have co-authored.
I can send the paper to interested people (please email me directly) but can't send it on this list because it is still not in its final form. The paper probes 150 access networks (including home, hotspots, 3g providers, cable, etc) to check and see if new TCP options get through, and whether middleboxes resegment the TCP stream. There are many other tests there, but those are not necesarily relevant to tcpcrypt. The paper does not probe the server end of things where firewalls, load balancers and the like can cause further grief. The new options get through on SYNs on 86% - 96% of the paths we probed. The percentage depends on the TCP port (only 86% allow new options on HTTP traffic, 94% on HTTPS traffic, and 96% for a new, unknown port). SYNs with new options were never dropped; in the remaining 4%-14% of the cases the new options were simply removed. As for middleboxes that resegment the bytestream: this behaviour did appear in the tests, but it was correlated with the removal of new options on SYNs. Basically, middleboxes that resegment tend to terminate the connection and open a new one to the destination, acting like a full proxy. We've analyzed all experimental data and its implications for about mptcp and tcpcrypt: the result is that these two protocols seem safe to deploy today in the access networks we've probed. Cheers, Costin On 3 Aug 2011, at 00:31, Andrea Bittau wrote: > On Tue, Aug 02, 2011 at 05:40:18PM +0200, SCHARF, Michael wrote: >> For whatever it is worth, the question of TCP extension vs. shim layer >> seems to be somehow related to some discussions in the MPTCP WG last >> year. In a different context, an expired ID >> (http://tools.ietf.org/html/draft-scharf-mptcp-mctcp-01) discusses some >> pros and cons of transport layer vs. shim layer+discovery by SYN >> options. Not all of them are about implementation, and IMHO both >> alternatives have disadvantages. Section 5.4 of RFC 6182 also includes >> some thoughts. > > Mark Handley is in fact one of the authors of tcpcrypt and RFC 6182 so > we're working closely with him to figure out what the implications of > TCP options are in practice. Section 5.4 of RFC 6182 concludes that TCP > options are the right way to go and hopefully that applies to tcpcrypt > too (we're working on it with Mark). All tcpcrypt authors agree that > TCP is the right place for encryption from a design perspective, though > the one practical downside are middleboxes. We're hoping we can > "handle" most cases by downgrading to TCP by checking if the options > make it through on the SYN / SYN-ACK. A pretty bad case is when the SYN > is dropped. > > For us to better present an argument (or perhaps even change our > design!) we're trying to figure out what the arguments are for an > application layer approach as opposed to a transport one. > Implementation has already come up. From a design perspective however, > apart from middleboxes (or even more specifically, SYNs getting dropped) > we'd be glad to hear more opinions on why the application layer might be > more attractive.
