Protocols that were designed with a LAN in mind sometimes have to travel over the Internet, where reliability, security and privacy are serious concerns. Solutions that construct a tunnel between LANs that runs over TLS tend to loose useful properties of the original protocol. SCTP has the flexibility to resolve that.

Usecase 1: RADIUS (and Kerberos5, DNS, ...)

The RADIUS protocol is used to grant access to resources. Attributes such as a username and credential are sent to a RADIUS server, which answers with acceptance or rejection.

The RADIUS protocol runs over UDP, with good reason. The loss of one message does not block later messages from getting through, as would be the case with TCP. Typical applications of RADIUS include massive access control at ISP gateways, where such delays would be rather disruptive. Lost UDP messages can be resent, but that need not stop the rest from getting through. Similar mechanisms are found in Kerberos5, DNS and most other UDP-based protocols.

When federated mechanisms are constructed, RADIUS is often run over TLS. The mere cost of setting up these connection implies that one TLS connection is used for all users being authenticating, which eventually restricts the scale at which this can be done. DTLS over UDP might resolve this, but is not common.

Usecase 2: SNMP

The SNMP protocol is the IETF standard for inquiring the host or service state for purposes of monitoring. SNMP is run over UDP for good reason -- it should not cause additional resends on a network if that network is suffering from severe overload. SNMP would rather loose information in that case.

SNMP is not commonly used for federated constructs; but if hosting providers are brought together as we intend to do with InternetWide then this is the only standard, therefore the most probable option for support of service plugins with domain hosters.

The reasons why SNMP is sent over UDP do not matter when crossing over the Internet, but there will be more than one inquiry, and again the delay of one would undermine what follows when it is simply tunneled over TLS. As many of the measurements made with SNMP are time-specific, it is wise to avoid that problem.

Usecase 3: LDAP (and IMAP, SIP, XMPP, ...)

LDAP runs over TCP, but its design involves quite a bit of concurrency, due to a decoupling of the order in which queries are answered. In general, a question is marked with an identifier that is reproduced in the answer. This is not at all unique; IMAP follows a similar structure, and so do SIP and XMPP.

The reason we find LDAP interesting for SCTP tunneling, is that it can be used for authorisation inquiries. As in the usecase for RADIUS, these work better when no more queueing is enforced on them than necessary; although LDAP itself is concurrent, this only applies to server handling but the TCP carrier does not extend that idea to the transport.

Usecase 4: FastCGI (and WSGI, remote shells, ...)

The web is quickly evolving to a model where a frontend serves HTTP, and application-specific backends implement functionality. The advantage of this approach is that state can be kept, regardless of the stateless HTTP transport, thus reserving database power for what it is really good at.

There are a few frameworks that standardise the link between the HTTP server and the backend applications; one of the first was perhaps FastCGI, but there are others, such as WSGI and more -- this is usually an in-house protocol, so it generally does not matter. When we say FastCGI, please don't assume that we are saying it is the last word in the area.

But, looking at FastCGI, it does a lot of things that SCTP can do better; it defines multiple streams, and communicates them in a fixed order. The possibility of SCTP to serve them over separate streams is of course more general, and avoids slowdowns of one stream on account of another -- much the same as we observed for SNMP and RADIUS.

The same principle (using multiple streams) may apply for other protocols as well. Consider a remote shell with a stdout and stderr stream; consider an OpenSSH connection with forwarding of TCP connections -- and, since this is done over separate streams, we can easily add UDP connections!

Benefits of SCTP

SCTP can be useful in all these situations. It sends data in frames, which can be larger than a UDP packet. Frames are always delivered as a whole, even if they span multiple network packets, so it is the level at which applications perform their sends and receives.

For each frame, a sender can decide whether whether it should be delivered in any order, or after all the previous submissions have been delivered. In fact, a frame can act a bit like a "flush" call on the connection, which can otherwise deliver frames in-order or out-of-order.

An SCTP association may contain multiple streams, each of which form one of those frame sets with partial ordering. Streams are totally concurrent, and may be used to multiple multiple protols into one association. This is very attractive for combining multiple protocols into one association.

Indeed, we see great possibilities in SCTP as a single connection between a plugin provider and a domain hoster; the former would connect to the latter and request services like SNMP, RADIUS and LDAP, and perhaps it would offer FastCGI for access to an internal website.

Mutual Authentication and Encryption

There are a few ways to arrange authentication and encryption. The most flexible method is to authenticate separately over each of the SCTP streams. One advantage of this approach is that it works when some of the requested functionality is not made available; only refused stream would fail but others could continue. Moreover, it evades a requirement of separate configuration of what functionality to run on which stream -- as long as the security protocol is explicit about what it wants.

The mechanism that InternetWide has selected for authentication is the common choice for centralised management of infrastructures, namely Kerberos5. The somewhat more general protocol designed for this is GSS-API. It is useful to know that Kerberos5 under GSS-API can be used in a way that permits out-of-order delivery of frames.

So, when an SCTP association is created from plugin provider to domain hoster, the former asks for a number of streams, and starts GSS-API over each of those. Where applicable, it will request out-of-order delivery; and it will always require mutual authentication, and the presence of both encryption and message integrity. GSS-API generates byte sequences for the setup of a security context on both sides, and will indicate when this is ready for further communication.

The client (plugin provider) requests a certain service from the domain hoster, and the domain hoster can decide whether it not it will grant access to this service. It could decide to not provide a suitable ticket to the plugin provider or it could take down streams that make too bold requests.

Any further communication will now be passed through GSS-API, applying both encryption and a messaage integrity code to the frames sent. As was the case during the creation of the mutual context, the GSS-API will construct byte sequences to be sent as an SCTP frame.

The logic of an application dictates whether frames are ordered such that one precedes another. General UDP applications would permit out-of-order delivery, general TCP applications would not, and certain protocols such as LDAP may have a smarter method implemented, perhaps in a plugin module, that gets as much out of SCTP as is possible.

The task of Funnel

The client Funnel binds to UDP and TCP ports, and forwards them over SCTP to the server Funnel. The client would run at the plugin provider and the server would run at the domain hoster, in terms of InternetWide. Finally, it may serve as a switchbox between Funnel instances; this would enable the further delivery of protocols over SCTP instead of UDP or TCP. The sending methods of frames would then simply be copied. (This is possible; the socket API shares header information, including ordering requirements in the SCTP_UNORDERED send and receive flags.)

It is valuable for Funnel to support plugin modules for specific protocols, of which LDAP and IMAP were a few examples. Such plugin modules could be split in client and server modules.

Configurations for Funnel include the following aspects:

• Ports to listen (client) or connect (server) to for UDP and TCP
• Ports to listen or connect to with SCTP
• The mapping between ports and SCTP streams
• When applicable, modules that might be loaded if available
• For each SCTP stream, the local identity
• For each SCTP stream, the remote identities to accept

SCTP behind NAT and Firewalls?

SCTP is not yet implemented in all NAT and Firewall products. This is typically resolved by running it over a UDP tunnel, with port 9899 used on both ends. Such ports can be manually opened in NAT and Firewall products, and turned into locally acceptable SCTP.

It is generally a good idea to be able to send and receive both modes, inasfar as possible. The least common denominator will be to run over a UDP tunnel for some time to come, but the future may be more direct, and more efficient. The general advise is to try the direct connection first, and fallback to the UDP-based mode. This is especially true for the hosting infrastructure that InternetWide targets; it seems reasonable to expect that the equipment used there is already SCTP-capable.