Re: 24C3: Current events in Tor development

[coderman <coderman@xxxxxxxxx>]

On Jan 9, 2008 8:15 AM, coderman <coderman@xxxxxxxxx> wrote:
> ... the DTLS proposal hasn't seen any attention lately

things i would add to a revised DTLS proposal in my copious free time:

- preserve TCP support while converting all traffic to DTLS; use
airhook [0] like library for transparent TCP, SOCKS, and reliable Tor
messaging (signalling channel).

- use a virtual machine implementation to avoid timer resolution and
event dispatch latency in win32, in addition to traffic shaping (pf or
tc) on the VM for outgoing DTLS control and transport traffic.  UDP,
TCP and name resolution could then be supported transparently to the
user/host os while running on a fast event based unix implementation
in vm.  traffic shaping is going to be critical to keeping latency low
(buffers on broadband CPE devices can incur up to 1-2 seconds of
latency when send queue is maxed out...)

- UDP NAPT busting, including symmetric and full cone UDP NAPT
detection and assisted simultaneous open.  UPnP would of course be
just as useful for UDP port assignment as for TCP...

- the TCP support could be kept in place for bridge nodes, as DTLS Tor
will stick out like a sore thumb on a network.  the "Web HTTPS"
looking sessions to bridges would be useful when UDP/DTLS is blocked.

:)


0. Airhook - Reliable, efficient transmission control for networks that suck.
   http://airhook.ofb.net/
* this is likely to be useful in a Tor DTLS environment, as it is for
wireless, because most TCP stacks are going to treat the intermittent
lag / packet loss of the multiple DTLS hops as "congestion", leading
to poor throughput.  this is similar to the situation with wireless
where temporary congestion or 802.11 timeouts are treated as
"congested network" by most TCP stacks, rather than just "less than
ideal wireless network".