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 theShow full document text