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

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Fri, 13 Feb 2009 08:06:23 -0600 Drake Wilson <drake@xxxxxxxxxxxx>
wrote:
>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... ?

     I see that someone has since responded to that by pointing out the
tor roadmap.
>
>> >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.)

     Not at all.  It's what I asked for. :-)
>
>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.

     The above is, of course, true right now, but the problem may well
fade away over the next few years, now that SCTP is an official protocol
for the Internet.  W.r.t. electronics store routers, one only need note
the huge numbers of 802.11(draft)n devices being sold these days.  People
want the new stuff, even when there is no official standard and even when
most of those customers will not benefit from the higher data rates and
larger areas of coverage.  I'm not sure what to do about NAT, but how
would that be any different from the current situation?  As long as the
various packet filtering systems (pf, ipf, ipfw, ipfilter) are upgraded
to deal with SCTP, we ought to be able to handle that sort of thing
somehow.  So far, no one has been thinking about supporting SCTP over
SCTP [gasp!], just TCP over SCTP.  NAT also might prove pretty much
obsolete/unnecessary in IPv6, as well.
>
>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.

     There will undoubtedly be a transitional period while we wait for
people to upgrade their software, but that's true already with the move
to IPv6.
>
>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

     That does sound nasty, but probably no worse than TCP over UDP.

>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

     Yes, it's already in FreeBSD 7 and will probably be significantly
improved in FreeBSD 8.  I don't use LINUX, so I can't comment on that.
(LINUX folks, please chime in!)  I don't think OpenBSD has it yet, but
can't swear to it.  NetBSD I have no idea about.  It's reasonable to
assume that both will sooner or later if they don't have it now, especially
given the amount of code sharing that goes on between the different BSD
and MacOS X teams all the time.  (OpenBSD and NetBSD folks, please let us
know, too!)

>userspace library.  This can presumably all be handled with

     Even Micro$slop has to support protocols eventually, but yes, I
would expect problems from that quarter temporarily. :-(

>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

     Thank you very much.  You're the first to respond to my queries
regarding SCTP as a possible addition to tor, eventually replacing TCP.

>incomplete.  I'd welcome additions or corrections, certainly; if

     Me, too. :-)

>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.
>
     On the contrary, I asked it here because of the current plans to
replace the current TCP-over-TCP setup in tor with a TCP-over-UDP
implementation.  SCTP looks so much more versatile and has so many
features that seem just what tor would need, that I raised the question
here about why the developers chose UDP for their roadmap instead of
SCTP.  It seems as though the switch to UDP would take quite a bit of
time anyway and would most likely require supporting the current setup
in parallel for some time to accommodate the transition once the new
setup were working.  SCTP ought to be more widely supported by then,
so why not choose it now instead of UDP, especially if tor might later
need to switch to SCTP anyway for performance or other reasons?
     Thanks again for your information.  All in all, it doesn't sound
nearly as bad a situation as I might have feared; rather it sounds much
more like the hangups are mainly over being among the early birds to
use SCTP.


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************