Transport Layer Security over Stream Control Transmission Protocol
RFC 3436
| Document | Type | RFC - Proposed Standard (December 2002; No errata) | |
|---|---|---|---|
| Authors | Andreas Jungmaier , Eric Rescorla , Michael Tüxen | ||
| Last updated | 2013-03-02 | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 3436 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | Allison Mankin | ||
| Send notices to | <mankin@psg.com>, <jon.peterson@neustar.biz> | ||
Network Working Group A. Jungmaier
Request for Comments: 3436 University of Essen
Category: Standards Track E. Rescorla
RTFM Inc.
M. Tuexen
Siemens AG
December 2002
Transport Layer Security over
Stream Control Transmission Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document describes the usage of the Transport Layer Security
(TLS) protocol, as defined in RFC 2246, over the Stream Control
Transmission Protocol (SCTP), as defined in RFC 2960 and RFC 3309.
The user of TLS can take advantage of the features provided by SCTP,
namely the support of multiple streams to avoid head of line blocking
and the support of multi-homing to provide network level fault
tolerance.
Additionally, discussions of extensions of SCTP are also supported,
meaning especially the support of dynamic reconfiguration of IP-
addresses.
Jungmaier, et al. Standards Track [Page 1]
RFC 3436 TLS over SCTP December 2002
1. Introduction
1.1. Overview
This document describes the usage of the Transport Layer Security
(TLS) protocol, as defined in [RFC2246], over the Stream Control
Transmission Protocol (SCTP), as defined in [RFC2960] and [RFC3309].
TLS is designed to run on top of a byte-stream oriented transport
protocol providing a reliable, in-sequence delivery. Thus, TLS is
currently mainly being used on top of the Transmission Control
Protocol (TCP), as defined in [RFC793].
Comparing TCP and SCTP, the latter provides additional features and
this document shows how TLS should be used with SCTP to provide some
of these additional features to the TLS user.
This document defines:
- how to use the multiple streams feature of SCTP.
- how to handle the message oriented nature of SCTP.
It should be noted that the TLS user can take advantage of the multi-
homing support of SCTP. The dynamic reconfiguration of IP-addresses,
as currently being discussed, can also be used with the described
solution.
The method described in this document does not require any changes of
TLS or SCTP. It is only required that SCTP implementations support
the optional feature of fragmentation of SCTP user messages.
1.2. Terminology
This document uses the following terms:
Association:
An SCTP association.
Connection:
A TLS connection.
Session:
A TLS session.
Stream:
A unidirectional stream of an SCTP association. It is uniquely
identified by a stream identifier.
Jungmaier, et al. Standards Track [Page 2]
RFC 3436 TLS over SCTP December 2002
1.3. Abbreviations
MTU: Maximum Transmission Unit
SCTP: Stream Control Transmission Protocol
TCP: Transmission Control Protocol
TLS: Transport Layer Security
2. Conventions
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL", in this document are to be interpreted as described in
BCP 14, RFC 2119 [RFC2119].
3. SCTP Requirements
3.1. Number of Inbound and Outbound Streams
An association between the endpoints A and Z provides n streams from
A to Z and m streams from Z to A.
A pair consisting of two streams with the same stream identifier is
considered and used as one bi-directional stream.
Thus an SCTP association can be considered as a set of min(n,m) bi-
directional streams and (max(n,m) - min(n,m)) uni-directional
streams.
3.2. Fragmentation of User Messages
To avoid the knowledge and handling of the MTU inside TLS, SCTP MUST
provide fragmentation of user messages, which is an optional feature
of [RFC2960]. Since SCTP is a message oriented protocol, it must be
able to transmit all TLS records as SCTP user messages. Thus the
supported maximum length of SCTP user messages MUST be at least 2^14
+ 2048 + 5 = 18437 bytes, which is the maximum length of a
TLSCiphertext, as defined in [RFC2246].
Please note that an SCTP implementation might need to support the
Show full document text