Re: use of SCTP in volunteer relay networks (a bit off-topic)

[Drake Wilson <drake@xxxxxxxxxxxx>]

Quoth Scott Bennett <bennett@xxxxxxxxxx>, on 2009-02-13 07:27:10 -0600:
> >TCP connection has much more of this than would be present if one were
> >using the underlying packet network more directly, I think.)
> 
>      But I don't think reimplementing all of that over UDP is necessarily
> the optimal way to go about it.

I'm not sure who proposed reimplementing Tor with UDP... ?

> >Using a protocol like SCTP might help with this, but that brings up
> >various other annoying practical problems that are particularly
> >annoying because there's no good reason for them to exist.
> >
>      Such as?  A list of pros and cons is the kind of elaboration I've
> been hoping to get.

I've been examining SCTP during some of my Copious Free Time as part
of some (non-Tor) research on relay networks.  (Pardon my verbosity in
the following paragraphs.)

The advantages are mainly the desirable features of SCTP that are not
easily replicable with TCP or UDP: multiple streams per association, a
goodly amount of control over ordering constraints and (I think)
reliable versus unreliable delivery, while retransmissions and packet
boundaries are still handled for you at the transport layer rather
than having to fold them into an application-layer protocol, and so
forth.

As I see it, one main problem with native SCTP if you expect random
people on the Internet to run relays is the toxic black moldy
outgrowth of NAT everywhere.  In the presence of NAT, direct access to
the original transport-protocol-agnostic packet network between the
hosts is lost, so the NAT box has to handle remapping port numbers in
transport protocols.  "NAT box", here, includes huge swathes of
consumer-grade "routers", which will (at least in my experience and by
extrapolation) mostly fail to understand SCTP, because it's not
commonly used, and they have no incentive to put another code path in
that takes up space and time and might cause bugs.  Tor already
requires people to set up TCP port forwarding, which is a potential
barrier to becoming a relay; for people using consumer-grade NAT on
their Internet connections, doing SCTP port forwarding or similar
tricks may be close to impossible.

A secondary, similar problem might be restrictive perimeter firewalls
or intrusion detection systems that deny all unrecognized transport
protocols because they don't know how to inspect them; I've seen
university networks with these, for instance.  I don't know how common
this is, nor how the set of locations with such restrictions
correlates with the set of locations where people want to operate
relay nodes.

It's possible to get around some of the above by layering SCTP on top
of UDP, which is quite ugly but may be less ugly than designing a new
transport layer from scratch; there's an "interim protocol" for this
designated by the experimental-status sigtran-sctptunnel-00
Internet-Draft (which expired in August 2000).  That uses a daemon
that tunnels SCTP using a single reserved UDP port, which can create
deployment problems if applications are assumed to only allocate TCP
and UDP ports for themselves, which is a common assumption.
Presumably it would be easy to define SCTP over single
application-assigned UDP ports based on the existing draft, but this
wouldn't interoperate with existing native SCTP implementations, which
is a pain.

There may be issues with operating system support.  Several Unix-like
systems support SCTP directly; Windows seems to require an extra
userspace library.  This can presumably all be handled with
application-level glue code; I don't know how much implementation
complexity it adds to handle both cases for SCTP versus TCP.  The
latter seems likely to be better-known, making it easier to find
information and existing multiplatform glue code.

That's what I've learned so far; as you can see, my knowledge is
incomplete.  I'd welcome additions or corrections, certainly; if
there's going to be extended discussion on this topic, though, it
might be better to do it off-list, since it's not directly
Tor-related.

   ---> Drake Wilson