Summary

  • RFC 3436 paired opposite SCTP streams into bidirectional channels and established a separate TLS connection on each one; sessions could be resumed and handshakes delayed, but every protected stream still needed its own completed handshake.
  • TLS protection required ordered, fully reliable delivery and covered SCTP user data rather than the association’s control chunks. RFC 6083 later cited that cost and used one DTLS context to recover unordered delivery, partial reliability and larger stream counts.

A secure association that did not exist

Imagine an SCTP association with thirty-two streams. An operator says, “TLS is enabled on the association.” RFC 3436 makes that sentence dangerously imprecise. Stream 0 might have completed a full handshake. Stream 1 might be resuming the same TLS session. Stream 2 might not start its handshake until an application first needs it. Several unidirectional streams cannot carry TLS under the specification at all. Another paired stream may remain native SCTP.

The association is real. So are the individual TLS connections. The supposed single security state is not.

Published in December 2002, RFC 3436 described how to run TLS 1.0 over the then-new Stream Control Transmission Protocol. Its plain-text edition, RFC Editor record, Datatracker file, history, references, later citations and errata search establish the documentary record. They do not prove that a named product implemented it, that two implementations interoperated, or that a production service benefited.

TLS expected a river; SCTP supplied labelled parcels

TLS 1.0 expected a reliable byte stream that delivered records in order. SCTP’s original specification offered reliable messages, multiple streams and multiple endpoint addresses. The checksum update was already part of SCTP’s record when RFC 3436 appeared.

The adaptation made one TLS record one SCTP user message. SCTP, not TLS, had to fragment and reassemble that message to avoid IP fragmentation and keep MTU knowledge below the security layer. An implementation had to accept at least 18,437 bytes: 2^14 + 2048 + 5, the maximum TLSCiphertext size used by the document. A partial-delivery API might be needed even though the logical record remained one message.

That choice preserved a visible boundary. Network fragments were not TLS records. An SCTP user message carried one record. A complete record was still not proof that the application accepted or acted on it.

The stream pair became the security container

SCTP negotiated outbound streams independently in each direction. If A had n streams toward Z and Z had m toward A, RFC 3436 paired equal identifiers to create min(n,m) bidirectional streams. Any excess remained unidirectional.

TLS could use only the paired streams. Each pair received its own connection and its own handshake. That preserved SCTP’s protection against cross-stream head-of-line blocking: a stalled TLS record on one stream did not have to stop every other stream in the association. But independence had a resource price. Twenty protected stream pairs meant as many TLS connections and handshake state machines.

The RFC offered three ways to manage the bill. A stream could perform a full handshake. It could perform an abbreviated handshake by resuming a session created on another connection, even on another association. Or its handshake could be delayed until the application actually used the stream. On high-round-trip-time networks, several full handshakes in parallel might be faster; under computational pressure, resumption might be cheaper. The document did not pretend one policy dominated every network.

Session resumption did not erase the connection boundary. A shared session identifier reduced work, but stream 1 could not send protected application data merely because stream 0 was ready. Its own handshake still had to finish.

Protection removed two advertised freedoms

TLS records had to arrive strictly in sequence. RFC 3436 therefore prohibited SCTP’s unordered-delivery feature on TLS streams. For the same reason, a TLS record could not be assigned a limited lifetime and abandoned when it became stale. Unidirectional streams also remained outside the TLS mapping.

Other streams in the same association could still use native SCTP without those restrictions. This produced a mixed association: protected ordered user data here, unconstrained SCTP user data there, and unidirectional traffic elsewhere. “The association uses TLS” concealed which messages had which guarantees.

RFC 3758 later standardized partial reliability, allowing a sender to abandon data. That useful capability could not be inserted into RFC 3436’s serial TLS record stream. RFC 7496 still stated years later that TLS over SCTP could not be used for partially reliable SCTP.

The lock did not cover the transport controls

The sharpest limit appeared outside RFC 3436. RFC 4895 explained that TLS over SCTP did not solve SCTP chunk authentication because it secured only user data. An attacker’s ability to interfere with transport control required a separate association-level mechanism, SCTP-AUTH.

This is not wordplay. Confidential application records, an authenticated TLS peer, an authenticated DATA chunk and an authenticated control chunk are different receipts. If stream choice, ordered/unordered treatment, address reconfiguration or a forward-sequence instruction affects delivery, the security of the payload alone cannot attest to the transport decision around it.

The multihoming rule made the same point from another direction. SCTP could send records from an address different from the one first observed. RFC 3436 said decisions should rest on authenticated peer identity, not transport-layer identity. Address continuity was not identity; address change was not necessarily identity change.

DTLS moved the boundary

In 2011, RFC 6083 opened by naming four serious limitations of RFC 3436: no unordered messages, no partial reliability, equal stream counts in both directions, and one TLS connection per bidirectional stream with substantial cost at scale.

Its alternative placed one DTLS connection within the SCTP association. Security control traffic used stream 0 with ordered, unlimited reliability. Application data could use many other streams, preserve message boundaries, travel ordered or unordered, and use partial reliability. DATA chunks had to use SCTP-AUTH; FORWARD-TSN chunks also needed authentication when partial reliability was enabled.

The contrast is historically useful. RFC 3436 protected each serial stream separately so ordinary TLS could remain unchanged. RFC 6083 spent more integration effort at the association boundary to retain more of SCTP’s transport semantics. Neither publication proves deployment. The later design is evidence that the earlier boundary had measurable architectural costs, not evidence that every network migrated.

RFC 8996 later deprecated TLS 1.0 and 1.1. RFC 3436’s original cipher-suite language is consequently part of the historical mechanism, not current cryptographic advice. The IANA SCTP registry proves coordinated protocol assignments; it does not supply implementation or traffic evidence.

The durable receipt chain

Heng Lu’s account of reality layers gives this old transport decision a contemporary reading. Standards status proves a published coordination rule. A completed handshake proves a particular cryptographic state. SCTP-AUTH proves specified chunks were authenticated. Application telemetry can show an outcome. None is entitled to borrow the authority of the next.

His argument for running-code primacy keeps the specification separate from an implementation that survives loss, reordering and address change. The minimum-initial-specification lens explains why RFC 3436 could reuse existing TLS and SCTP, accept a narrow profile, and leave richer semantics to later work. These are retrospective editorial applications, not claims about the authors’ motives.

RFC 3436 did not fail by drawing a boundary. It succeeded in making that boundary inspectable. One association could contain several security states. One resumed session could underlie several connections. One protected stream had surrendered capabilities that another stream retained. The honest operational statement was never “SCTP is secured.” It was: this stream completed this handshake, under this identity, with these delivery rules—and these transport controls still need their own proof.

Sources

Additional frozen records