On Tue, Aug 02, 2011 at 01:25:27AM -0400, [email protected] wrote: > There's a problem here that needs attention. As was pointed out in the > tsvarea presentation (IIRC) of tcpcrypt, there is plenty of unpleasant > deployment experience with at least middleboxes (e.g., firewalls) that > discard TCP packets with unexpected header contents such as a new TCP option > (or even attempted use of the ECN bits). Sending the SYN with a new TCP > option risks paying a long timeout with a site that doesn't support that new > TCP option and has a middlebox that discards the SYN packet because it > doesn't like the new option - that behavior will complicate incremental > adoption. > > What to do about this is a longer discussion, as some of the alternatives > have downsides (e.g., starting both a tcpcyrpt and non-tcpcrypt TCP > connections consumes an additional connection slot at the responder).
Yes, that's the crux of the argument - will a new TCP option cause packets to be dropped? In fact, that's the only compelling argument for why an application layer approach might be better than a TCP one, though we still think the arguments for TCP outweigh those for the application layer. We're working on measuring (the best we can) how much middleboxes drop packets with unknown options to see whether it's a show stopper. Hopefully the common case will be that middleboxes strip options rather than dropping packets. In fact, if you have pointers to case studies on middlebox behavior we'd love to have those. As you say the solution is not straightforward. For example, a very conservative approach could be to disable tcpcrypt if the sender is unable to connect using tcpcrypt to (say) three sites. That way the penatly of sending a vanilla TCP syn and a tcpcrypt SYN to "path probe" is paid only three times. tcpcrypt can be turned back on when the sender's IP changes. This may work out pretty well if our test results show that middleboxes are most often found closer to the client-side (e.g., NATs) rather than the server side. My understanding of most of ECN's problems is that the bits were previosuly reserved and then overloaded. TCP options (in principle) are a by-the-spec way of extending TCP, so hopefully we'll suffer less problems compared to ECN.
