On Thu, 2013-12-12 at 12:43 +0100, Christian Grothoff wrote: > On 12/12/2013 11:19 AM, Jacob Appelbaum wrote: > > I think that generally, I would prefer if the code didn't use MD5 but > > otherwise, I don't see any real risk of adding an exploitable hole. It > > seems silly to disable it by default though - ideally, I'd like a sysctl > > to ensure that Tor could use this without making the user recompile > > their kernel. That is more of a pain than running a userspace helper, I > > think. > > > > All the best, > > Jacob > > Given that the output is truncated to 32 bits and that performance (SYN > flood) is also a concern, AND that the original TCP SQN generation is > also MD5-based (and we want to look the same), what disadvantage do you > see over MD5? Given the truncation to 32 bits, I don't think a stronger > hash would do anything for us. > > As for it being disabled by default, we did this with respect to > kernel submission guidelines which we understood said that features > should _initially_ always be submitted with disabled-by-default > (presumably so that until they have stabilized, nobody is harmed > unless they explicitly activate the code). > > I don't see the point in having a sysctl, as applications have to > explicitly request it anyway.
Wait a minute. Your implementation looks like another TCP MD5 thing, but with a single secret. Check at git history to discover how many bugs we had to fix. Ask yourself how wrong was TCP MD5 being implemented in the kernel. Very soon you'll need to support different secrets. You do not want all clients share a common secret, do you ? How can a server change its secret without disrupting clients ? How having a constant initial sequence number can even be valid ? What about TCP timestamps being not available at all ? How typical servers can be behind a load balancer ? Or am I missing something ? With various proposals (like TCP minion), maybe its time to be able to implement part of TCP stack in user land (Keep the mux inside the kernel, and forward raw incoming packets to user land where all the crazy things can be done without kernel patching.) To me your idea is very close from TCP fast open. The only difference would be for the server to not send its cookie in SYNACK ? Sorry, you seem to hurry to get this facility, I do not see how it can really save the world. If it does, you definitely should get feedback from TCP community at IETF. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
