On Sun, Aug 25, 2013 at 10:52 PM, Bill Stewart
... Because "low latency protocols that are resistant to traffic analysis" is a really really hard problem. Even doing "high latency protocols that are resistant to traffic analysis" is a really hard problem.
the best kind of problems!
Datagrams don't give you any useful anonymity,
correct. i mention them as a prerequisite for both protection and usability. protection for example, with end-to-end SCTP multi-homed endpoints via userspace stacks would avoid predecessor attacks - if you block one route there are others which transit traffic, maintaining an uninterrupted session across otherwise individually volatile paths. usability for example to support UDP traffic and applications which are not currently served via TCP and connection oriented services.
... The standard warning about using them for an application is that it's extremely tempting to use them to reinvent TCP badly,
sadly, even TCP re-invented in user space is insufficient. you want a specific protocol implementation of multi-homed SCTP in userspace, probably on top of other protocol supports like LEDBAT or AQM. perhaps using ORCHID IPv6 identifiers for endpoint addressing. lot's of options; and as you said: it's a hard problem!
Some other problems with them are that you need to ... disguise them as other protocols.
this is a separate problem. for the core transport encapsulation in UDP may be sufficient. for censorship avoidance you will likely need to bounce over a DUST like path first to access such an anonymizing network. topology is an interesting subject, as the design must be decentralized but may not need to be homogenous.
Putting them in user space is just fine and mostly more portable. It's hard to get millisecond-level latency if you do that, but you can't hide from traffic analysis with latency that low anyway.
you want variable latency at the datagram level (e.g. stochastic reordering and shaping of traffic, with prioritization done at the endpoint where flows are visible.) more than the utmost in performance. as long as it is overall TCP fair of course :) and this is just the start. we haven't touched on network discovery, path awareness/selection/weighting, etc. as you said, hard problems; the best kind of problems!