Some protocols are designed for use on an internal network, and land in trouble when they need to cross-over to other operational domains, usually over the public Internet. Two such applications are RADIUS (for AAA) and SNMP (for monitoring). The common way out is to use TCP with TLS; but this has problems too. Instead, we want to try this with SCTP.

Problem Description

Protocols such as RADIUS and SNMP are very useful in relaying information for accounting and management purposes, specifically. Both are run over UDP with good reason; RADIUS wants to avoid the sequential of independent requests; SNMP wants to survive in situations where the network deteriorates.

These protocols are sometimes called for between operational domains, but they are not sufficiently reliable, or secure, to cross the public Internet. So in these cases, TCP and TLS are used as wrappers. This is always at the expense of the original reasons to run the protocols over UDP.

SCTP [RFC 4960] is very suitable to resolve these issues for cross-realm communication. Not only can it be protected through DTLS or GSS-API, but it can specify separate streams, and each of these can specify whether they implement ordered delivery (which is useful for RADIUS) or partially reliable [RFC 3758] due to dropouts (which is useful for SNMP). Even more interestingly, SCTP can support sending information from more than one source address, so failure of one network interface could be resolved by sending through another.

What we would like to see, is an experiment that verifies if this works, and how well it works. This involves the creation of a simple program that translates local RADIUS and SNMP streams back and forth to SCTP, on both ends. In addition, it involves validation that the reasons why these protocols originally preferred SCTP still holds.

Protocol Design

The full protocol to implement this involves DTLS or GSS-API over one of its streams, as well as some configuration dynamicity; we will not be bothered with those aspects in this exercise. Instead, the following fixed setup will suffice:

  • Stream 0 is silent (reserved for DTLS or GSS-API)

  • Stream 1 is silent (reserved for configuration)

  • Stream 2 is for RADIUS Authentication + Authorisation

  • Stream 3 is for RADIUS Change of Authorisation

  • Stream 4 is for RADIUS Accounting

  • Stream 4 is for SNMP Get and Walk operations

  • Stream 5 is for SNMP Trap operations

The distinction between streams serves a number of purposes. They may be routed separately (Authentication versus Accounting) and they may each have different delivery modes (reliability, ordering).

Questions

  • Is the proposed stream split optimal, or are there reasons to improve upon it? What are the pros and cons of combining of RADIUS with SNMP (and possibly more) protocols?

  • What are recommended modes of operation for each? Consider various circumstances, including local versus Internet routing and a normal versus a flooded, slow or packet-dropping network.

  • Conduct tests of your recommendations in simulated network settings.

  • Investigate the reasons why RADIUS uses UDP instead of TCP. Does SCTP offer a suitable alternative?

  • Investigate the reasons why SNMP uses UDP instead of TCP. Does SCTP offer a suitable alternative?