[messaging] Ronion anonymous routing protocol framework

[James McGlasan]

(Carlo, sorry for the dup, accidentally replied directly to you.)

On Wed, Nov 01, 2017 at 08:27:37PM +0100, carlo von lynX wrote:
> James, SOCKS5: Sorry, my bad, I just assumed it is a circuit-oriented
> interface. So Tor could introduce message types to support other parts
> of the SOCKS5 protocol?

As I already said, Tor isn't suitable for UDP traffic because Tor is
already reliable - which is perfectly fine for TCP and may even reduce
the latency in retransmissions when packets are dropped.

If you want UDP over TCP, you gain none of the benefits of UDP.  You may
use https://onioncat.org without modifying Tor. Just as OnionCat
implements UDP, yes, Tor could do the same for SOCKS5.

Alternatively if Tor were to use both UDP and TCP for transport, then it
might look something along the lines of this (old and discarded)
proposal.

 https://gitweb.torproject.org/torspec.git/tree/proposals/100-tor-spec-udp.txt

On the other hand, implementing TCP over UDP has its own (minor) cost
(WRT onion routing), the reliability is tracked over the whole path, not
between each hop. This means the worst case retransmission must walk the
whole path instead of just resending between two hops.

However, when using a reasonable congestion control mechanism, such as
BBR, dropped packets should be rare.

Recap or TLDR:

 TCP over Tor: slow setup, low latency, per-hop retransmission.
 TCP over HORNET: fast setup, lower latency, whole-path retransmission.
 
 UDP over Tor: slow setup, reliable and ordered (blocking).
 UDP over HORNET: fast setup, unreliable and unordered.

 Sidenote: one of the benefits of UDP over HORNET is that we can have
 send-only services / push notifications that do not leak if the
 recipient is actively online or not. We cannot get this feature with
 Tor's TLS/TCP core.

Finally, the lowest level protocol that HORNET can expose is similar to
IP, just datagrams with a destination and optional return path. With
this, we implement SOCKS5 for TCP and UDP.


James.