draft-ietf-mmusic-sctp-sdp-07.txt   draft-ietf-mmusic-sctp-sdp-08.txt 
MMUSIC S. Loreto MMUSIC C. Holmberg
Internet-Draft G. Camarillo Internet-Draft S. Loreto
Intended status: Standards Track Ericsson Intended status: Standards Track G. Camarillo
Expires: January 5, 2015 July 4, 2014 Expires: June 1, 2015 Ericsson
November 28, 2014
Stream Control Transmission Protocol (SCTP)-Based Media Transport in the Stream Control Transmission Protocol (SCTP)-Based Media Transport in the
Session Description Protocol (SDP) Session Description Protocol (SDP)
draft-ietf-mmusic-sctp-sdp-07 draft-ietf-mmusic-sctp-sdp-08
Abstract Abstract
SCTP (Stream Control Transmission Protocol) is a transport protocol SCTP (Stream Control Transmission Protocol) is a transport protocol
used to establish associations between two endpoints. This document used to establish associations between two endpoints.
describes how to express media transport over SCTP in SDP (Session
Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS' This specification describes how to describe SCTP associations using
and 'DTLS/SCTP' protocol identifiers for SDP. the Session Description Protocol (SDP), and defines the following new
SDP Media Description protocol identifiers (proto values):'SCTP',
'SCTP/DTLS' and 'DTLS/SCTP'.
The specification also describes how to use the new proto values
together with the SDP Offer/Answer mechanism in order to negotiate
and establish SCTP associations, and how to indicate the SCTP
application usage.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 5, 2015. This Internet-Draft will expire on June 1, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 3 3. SCTP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Media Formats . . . . . . . . . . . . . . . . . . . . . . . . 4 4. SDP Media Descriptions . . . . . . . . . . . . . . . . . . . 4
4.1. Media Descriptions . . . . . . . . . . . . . . . . . . . 5 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1.1. sctp-port . . . . . . . . . . . . . . . . . . . . . . 6 4.2. Protocol Identifiers . . . . . . . . . . . . . . . . . . 5
4.1.2. max-message-size . . . . . . . . . . . . . . . . . . 6 4.3. Media Format Management . . . . . . . . . . . . . . . . . 5
5. The Setup and Connection Attributes and Association 4.4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
Management . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5. Example . . . . . . . . . . . . . . . . . . . . . . . . . 6
6. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. SDP 'sctp-port' Attribute . . . . . . . . . . . . . . . . . . 6
7. Network Address Translation (NAT) Considerations . . . . . . 8 5.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 6
8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 6
8.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . 8 6. SDP 'fmtp' Attribute . . . . . . . . . . . . . . . . . . . . 7
8.2. Existing Connection Reuse . . . . . . . . . . . . . . . . 9 6.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.3. SDP description for SCTP over DTLS Connection . . . . . . 9 6.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.4. SDP description for SCTP over DTLS Connection using 7. SCTP Association Management . . . . . . . . . . . . . . . . . 7
default values . . . . . . . . . . . . . . . . . . . . . 10 7.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.2. SDP setup Attribute . . . . . . . . . . . . . . . . . . . 7
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7.3. SDP connection Attribute . . . . . . . . . . . . . . . . 8
10.1. sctp-port attribute . . . . . . . . . . . . . . . . . . 12 8. SDP Offer/Answer Procedures . . . . . . . . . . . . . . . . . 8
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 8
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Generating the Initial SDP Offer . . . . . . . . . . . . 9
12.1. Normative References . . . . . . . . . . . . . . . . . . 12 8.3. Generating the SDP Answer . . . . . . . . . . . . . . . . 9
12.2. Informative References . . . . . . . . . . . . . . . . . 13 8.4. Offerer Processing of the SDP Answer . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 8.5. Modifying the Session . . . . . . . . . . . . . . . . . . 10
9. Multihoming Considerations . . . . . . . . . . . . . . . . . 10
10. NAT Considerations . . . . . . . . . . . . . . . . . . . . . 11
10.1. General . . . . . . . . . . . . . . . . . . . . . . . . 11
10.2. ICE Considerations . . . . . . . . . . . . . . . . . . . 11
11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
12. Security Considerations . . . . . . . . . . . . . . . . . . . 12
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
13.1. New SDP proto values . . . . . . . . . . . . . . . . . . 12
13.2. New SDP Attribute . . . . . . . . . . . . . . . . . . . 12
13.3. association-usage Name Registry . . . . . . . . . . . . 13
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
SDP (Session Description Protocol) [RFC4566] provides a general- SDP (Session Description Protocol) [RFC4566] provides a general-
purpose format for describing multimedia sessions in announcements or purpose format for describing multimedia sessions in announcements or
invitations. TCP-Based Media Transport in the Session Description invitations. TCP-Based Media Transport in the Session Description
Protocol (SDP) [RFC4145] specifies a general mechanism for describing Protocol (SDP) [RFC4145] specifies a general mechanism for describing
and establishing TCP (Transmission Control Protocol) streams. and establishing TCP (Transmission Control Protocol) [RFC5246]
Connection-Oriented Media Transport over the Transport Layer Security streams. Connection-Oriented Media Transport over the Transport
(TLS) Protocol in the Session Description Protocol (SDP) [RFC4572] Layer Security (TLS) Protocol in the Session Description Protocol
extends RFC4145 [RFC4145] for describing TCP-based media streams that (SDP) [RFC4572] extends RFC4145 [RFC4145] for describing TCP-based
are protected using TLS (Transport Layer Security) [RFC5246]. media streams that are protected using TLS.
This document defines three new protocol identifiers:
SCTP : to describe SCTP-based [RFC4960] media streams.
SCTP/DTLS : to describe media streams transported using the Datagram
Transport Layer Security (DTLS) [RFC4347] protocol over SCTP, as
specified in [RFC6083]. DTLS over SCTP provides communications
privacy for applications that use SCTP as their transport
protocol.
DTLS/SCTP : to describe media streams transported using SCTP on top SCTP (Stream Control Transmission Protocol) is a transport protocol
of the Datagram Transport Layer Security (DTLS) protocol, as used to establish associations between two endpoints.
defined in [I-D.ietf-tsvwg-sctp-dtls-encaps].
The authentication certificates are interpreted and validated as This specification describes how to describe SCTP associations using
defined in RFC4572 [RFC4572]. Self-signed certificates can be used the Session Description Protocol (SDP) [RFC4566], and defines the
securely, provided that the integrity of the SDP description is following new SDP Media Description [RFC4566] protocol identifiers
assured as defined in RFC4572 [RFC4572]. (proto values):'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'.
TLS is designed to run on top of a byte-stream oriented transport The specification also describes how to use the new proto values
protocol providing a reliable, in-sequence delivery like TCP. Since together with the SDP Offer/Answer mechanism [RFC3264] in order to
no-one so far has implemented SCTP over TLS, due to some serious negotiate and establish SCTP associations, and how to indicate the
limitations described in [RFC6083], this document does not make use SCTP application usage.
of TLS over SCTP as described in RFC3436 [RFC3436].
Additionally, this document specifies the use of the 'setup' and NOTE: TLS is designed to run on top of a byte-stream oriented
'connection' SDP attributes to establish SCTP associations. These transport protocol providing a reliable, in-sequence delivery like
attributes were defined in RFC4145 [RFC4145] for TCP. This document TCP. [RFC6083] presents serious limitations with transporting SCTP
discusses their use with SCTP. on top of TLS. Therefore, defining a mechanism to negotiate media
streams transported using SCTP on top of TLS is outside the scope of
this specification.
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [RFC2119] and indicate requirement described in BCP 14, RFC 2119 [RFC2119] and indicate requirement
levels for compliant implementations. levels for compliant implementations.
3. Protocol Identifier 3. SCTP Terminology
SCTP Association: A protocol relationship between SCTP endpoints,
composed of the two SCTP endpoints and protocol state information
including Verification Tags and the currently active set of
Transmission Sequence Numbers (TSNs), etc. An association can be
uniquely identified by the transport addresses used by the endpoints
in the association. Two SCTP endpoints MUST NOT have more than one
SCTP association between them at any given time.
SCTP Stream: A unidirectional logical channel established from one to
another associated SCTP endpoint, within which all user messages are
delivered in sequence except for those submitted to the unordered
delivery service.
SCTP Transport address: A transport address is traditionally defined
by a network-layer address, a transport-layer protocol, and a
transport-layer port number. In the case of SCTP running over IP, a
transport address is defined by the combination of an IP address and
an SCTP port number (where SCTP is the transport protocol).
4. SDP Media Descriptions
4.1. General
This section defines the following new SDP Media Description (m-
line) protocol identifiers (proto values) for describing an SCTP
association: 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP'. The section also
describes how an m- line, associated with the proto values, is
created.
The following is the format for an 'm' line, as specified in RFC4566 The following is the format for an 'm' line, as specified in RFC4566
[RFC4566]: [RFC4566]:
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
This document defines three new values for the 'proto' field: 'SCTP', The 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' proto values are similar to
'SCTP/DTLS' and 'DTLS/SCTP'. both the 'UDP' and 'TCP' proto values in that they only describe the
transport protocol and not the upper-layer protocol.
The 'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers are NOTE: When the 'DTLS/SCTP' proto value is used, the underlying
similar to both the 'UDP' and 'TCP' protocol identifiers in that they transport protocol is either UDP or TCP.
only describe the transport protocol and not the upper-layer
protocol.
Media described using an 'm' line containing the 'SCTP' protocol The m- line fmt value, identifying the application-layer protocol,
identifier are carried using SCTP [RFC4960]. MUST be registered by IANA.
The 'SCTP/DTLS' protocol identifier indicates that the media 4.2. Protocol Identifiers
described will use the Datagram Transport Layer Security (DTLS)
[RFC4347] over SCTP as specified in [RFC6083].
The 'DTLS/SCTP' protocol identifier indicates that the media The new proto values are defined as below:
described will use SCTP on top of the Datagram Transport Layer
Security (DTLS) protocol as specified in
[I-D.ietf-tsvwg-sctp-dtls-encaps]. The actual layer below DTLS can
be plain UDP or what ICE agrees on (in the case ICE is used to
negotiate the actual transport flow). The lower layer used is
identified from the elements present inside the m= line block.
An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST o The 'SCTP' proto value describes an SCTP association, as defined
further qualify the application-layer protocol using an fmt in [RFC4960].
identifier.
An 'm' line that specifies 'SCTP/DTLS' or 'DTLS/SCTP' MUST provide a o The 'SCTP/DTLS' proto value describes a Datagram Transport Layer
certificate fingerprint only if the endpoint supports, and is willing Security (DTLS) [RFC6347] connection on top of an SCTP
to use, a cipher suite with an associated certificate. An SDP association, as defined in [RFC6083].
attribute (an 'a' line) is used to transport and exchange end point
certificate. The authentication certificates are interpreted and
validated as defined in [RFC4572].
4. Media Formats o The 'DTLS/SCTP' proto value describes an SCTP association on top
of a DTLS connection, as defined in
[I-D.ietf-tsvwg-sctp-dtls-encaps].
The SDP specification, [RFC4566], states that specifications defining NOTE: In the case of 'DTLS/SCTP', the actual transport protocol below
new proto values, like the SCTP, SCTP/DTLS and DTLS/SCTP proto values DTLS is either UDP or TCP.
defined in this RFC, must define the rules by which their media
format (fmt) namespace is managed. Use of an existing MIME subtype
for the format is encouraged. If no MIME subtype exists, it is
RECOMMENDED that a suitable one is registered through the IETF
process [RFC4288] [RFC4289] by production of, or reference to, a
standards-track RFC that defines the transport protocol for the
format.
An m-line with <proto> of 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' always OPEN ISSUE #1: It is FFS whether separate proto values will be used,
describe a single SCTP association. depending on whether the underlying transport protocol is UDP (e.g.
'UDP/DTLS/SCTP') or TCP (e.g. 'TCP/DTLS/SCTP').
An 'm' line that specifies 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' MUST 4.3. Media Format Management
further qualify the application-layer protocol using an 'fmt'
identifier.
The 'fmtp' attribute should be used to map from the 'association- [RFC4566] defines that specifications defining new proto values must
usage' (as used in an "m=" line) to the max-message-size parameter define the rules by which their media format (fmt) namespace is
indicating the maximum message size, in bytes, the endpoint is managed. Use of an existing MIME subtype for the format is
willing to accept. encouraged. If no MIME subtype exists, it is recommended that a
suitable one is registered through the IETF process [RFC6838]
[RFC4289] by production of, or reference to, a standards-track RFC
that defines the transport protocol for the format.
The sctp-port attribute specifies the actual sctp port. An m- line with a proto value of 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP'
always describe a single SCTP association.
In addition, such m- line MUST further indicate the application-layer
protocol using an 'fmt' identifier. There MUST be exactly one 'fmt'
value per m- line associated with the proto values defined in this
specification. The "fmt" namespace associated with those proto
values describes the generic application usage of the entire SCTP
association, including the associated SCTP streams.
NOTE: A mechanism on how to describe, and manage, individual SCTP
streams within an SCTP association, is outside the scope of this
specification.
4.4. Syntax
sctp-m-line = %x6d "="
("application" SP sctp-port SP "SCTP" SP sctp-fmt CRLF) /
("application" SP sctp-port SP "SCTP/DTLS" SP sctp-fmt CRLF) /
("application" SP udp-port SP "DTLS/SCTP" SP sctp-fmt CRLF)
sctp-port = port
udp-port = port
sctp-fmt = association-usage
association-usage = token
4.5. Example
m=application 12345 DTLS/SCTP webrtc-datachannel m=application 12345 DTLS/SCTP webrtc-datachannel
a=fmtp:webrtc-datachannel max-message-size=100000 a=fmtp:webrtc-datachannel max-message-size=100000
a=sctp-port 4060
4.1. Media Descriptions 5. SDP 'sctp-port' Attribute
An 'm' line containing the 'SCTP', 'SCTP/DTLS' or 'DTLS/SCTP' 5.1. General
protocol identifier has the following syntax:
sctp-m-line = %x6d "=" This section defines a new SDP media-level attribute, 'sctp-port'.
("application" space sctp-port space "SCTP" space sctp-fmt CRLF) / The attribute can be associated with an SDP media descriptor (m-
("application" space sctp-port space "SCTP/DTLS" space sctp-fmt CRLF) / line) with a 'DTLS/SCTP' proto value, in which case the m- line port
("application" space udp-port space "DTLS/SCTP" space sctp-fmt CRLF) value indicates the port of the underlying transport protocol (UDP or
TCP).
sctp-port = port If the SDP sctp-port attribute is not present, the default value is
5000.
udp-port = port Usage of the SDP sctp-port attribute with other proto values is not
specified, and MUST be discarded if received.
sctp-fmt = association-usage 5.2. Syntax
association-usage = token sctp-port-attr = "a=sctp-port:" portnumber
port-number = port
port = 1*DIGIT
The media description change slightly depending on the actual 6. SDP 'fmtp' Attribute
<proto>.
If the <proto> sub-field is 'SCTP' or 'SCTP/DTLS', the <port> is 6.1. General
the SCTP transport port (sctp-port) and follows the same active/
passive offer/answer model described in Section 4.1 of [RFC4145].
If the <proto> sub-field is 'DTLS/SCTP', the <port> is the UDP The SDP 'fmtp' attribute can be used with an m- line, associated with
transport port (udp-port). an SCTP association, to indicate the maximum message size that an
SCTP endpoint is willing to receive, for a particular SCTP
association usage, on that SCTP association.
The <fmt> sub-field carries the parameter indicating the conventional The remote peer MUST assume that larger messages will be rejected by
usage of an entire sctp association (association-usage). the SCTP endpoint. SCTP endpoints need to decide on appropriate
behaviour in case a message that exceeds the maximum size needs to be
sent.
association-usage: If the SDP 'fmtp' attribute contains a maximum message size value of
The association-usage token indicates the conventional usage of an zero, it indicates the SCTP endpoint will handle messages of any
entire sctp association including its streams (e.g. the pairing of size, subject to memory capacity etc.
certain streams, the protocol carried over certain streams, etc).
This parameter is a required parameter. [TBD a value for the If the SDP 'fmtp' attribute is not present, the default value is 64K.
generic usage as defined in RFC 4960 [RFC4960]].
Any offered association MAY be rejected in the answer, for any 6.2. Syntax
reason. If an association offer is rejected, the offerer and
answerer MUST NOT establish an SCTP association for it. To reject an
SCTP association, the <port> in the answer MUST be set to zero.
4.1.1. sctp-port sctpmap-attr = "a=fmtp:" association-usage [max-message-size]
max-message-size = "max-message-size" EQUALS 1*DIGIT
sctp-port-attr = "a=sctp-port=" portnumber 7. SCTP Association Management
port-number = port
The sctp-port attribute specifies the actual sctp port. This 7.1. General
attribute is optional and is only meaningful and required if the the
<proto> sub-field is 'DTLS/SCTP'. If the attribute is not present,
the default value is 5000.
4.1.2. max-message-size The management of an SCTP association is identical to the management
of a TCP connection. An SCTP endpoints MUST follow the rules in
Section 6 of [RFC4145] to manage SCTP associations. Whether to use
the SCTP ordered or unordered delivery service is up to the
applications using the SCTP association, and this specification does
not define a mechanism to indicate the type of delivery service using
SDP.
sctpmap-attr = "a=fmtp:" association-usage [max-message-size] 7.2. SDP setup Attribute
max-message-size = "max-message-size" EQUALS 1*DIGIT
The 'fmtp' attribute may be used to map from the 'association-usage' If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', the
(as used in an "m=" line) to the max-message-size parameter SDP setup attribute [RFC4145] is used to determine the TLS roles,
indicating the maximum message size, in bytes, the endpoint is following the proceduresin [RFC4572] (the 'active' endpoint will take
willing to accept. the TLS client role).
The max-message-size parameter indicates the maximum message size, in The SDP setup attribute is not used to determine which endpoint
bytes, the endpoint is willing to accept. The peer should assume initiates the SCTP association. Instead, both endpoints MUST
that larger message will be rejected by the endpoint, though it is up initiate the SCTP association, and MUST use the same SCTP port as
to the endpoint decide the appropriate behaviour. A parameter with client port and server port (in order to prevent two separate SCTP
value of '0' will signal a best effort attempt, subject to the associations from being established).
current endpoint memory capacity, to handle messages of any size. If
the parameter is not present, the implementation should provide a
default, with a suggested value of 64K.
5. The Setup and Connection Attributes and Association Management However, if the proto field value is 'DTLS/SCTP', and the transport
layer protocol is TCP (SCTP is carried on top of TCP), the SDP setup
attribute is also used to negotiate which endpoint will initiate the
TCP connection (send TCP SYN), following the procedures in [RFC4145].
The use of the 'setup' and 'connection' attributes in the context of 7.3. SDP connection Attribute
an SCTP association is identical to the use of these attributes in
the context of a TCP connection. That is, SCTP endpoints MUST follow
the rules in Sections 4 and 5 of RFC 4145 [RFC4145] when it comes to
the use of the 'setup' and 'connection' attributes in offer/answer
[RFC3264] exchanges.
The management of an SCTP association is identical to the management The SDP connection attribute is used following the procedures in
of a TCP connection. That is, SCTP endpoints MUST follow the rules [RFC4145], with the additional SCTP specific considerations described
in Section 6 of RFC 4145 [RFC4145] to manage SCTP associations. in this section.
Whether to use the SCTP ordered or unordered delivery service is up
to the applications using the SCTP association.
6. Multihoming In general, the SDP connection attribute only applies to an SCTP
association. Therefore, if the m- line proto field value is 'DTLS/
SCTP', a connection attribute 'new' value will not automatically re-
establish an existing DTLS connection, unless some DTLS properties
are also changed in a way which require the DTLS connection to be re-
established.
An SCTP endpoint, unlike a TCP endpoint, can be multihomed. An SCTP However, if the m- line proto field value is 'SCTP/DTLS', if the SCTP
endpoint is considered to be multihomed if it has more than one IP association is re-established, the DTLS connection also needs to be
address. A multihomed SCTP endpoint informs a remote SCTP endpoint re-established.
about all its IP addresses using the address parameters of the INIT
or the INIT-ACK chunk (depending on whether the multihomed endpoint
is the one initiating the establishment of the association).
Therefore, once the address provided in the 'c' line has been used to
establish the SCTP association (i.e., to send the INIT chunk),
address management is performed using SCTP. This means that two SCTP
endpoints can use addresses that were not listed in the 'c' line but
that were negotiated using SCTP mechanisms.
During the lifetime of an SCTP association, the endpoints can add and OPEN ISSUE #2: Verify that the above statement regarding 'SCTP/DTLS'
remove new addresses from the association at any point [RFC5061]. If is correct.
an endpoint removes the IP address listed in its 'c' line from the
SCTP association, the endpoint SHOULD update the 'c' line (e.g., by
sending a re-INVITE with a new offer) so that it contains an IP
address that is valid within the SCTP association.
In some environments, intermediaries performing firewall control use 8. SDP Offer/Answer Procedures
the addresses in offer/answer exchanges to perform media
authorization. That is, policy-enforcement network elements do not
let media through unless it is sent to the address in the 'c' line.
In such network environments, the SCTP endpoints can only exchange 8.1. General
media using the IP addresses listed in their 'c' lines. In these
environments, an endpoint wishing to use a different address needs to
update its 'c' line (e.g., by sending a re-INVITE with a new offer)
so that it contains the new IP address.
It is worth to underline that when using SCTP on top of DTLS, only This section defines the SDP Offer/Answer [RFC3264] procedures for
single homed SCTP associations can be used, since DTLS does not negotiating and establishing an SCTP association. Unless explicitly
expose any address management to its upper layer. stated, the procedures apply to all protocol identifier values
('SCTP', 'SCTP/DTLS' and 'DTLS/SCTP') defined in this specification.
7. Network Address Translation (NAT) Considerations If the m- line proto value is 'SCTP/DTLS' or 'DTLS/SCTP', each
endpoint MUST provide a certificate fingerprint, using the SDP
'fingerprint' attribute [RFC4145], if the endpoint supports, and is
willing to use, a cipher suite with an associated certificate.
SCTP specific features (not present in UDP/TCP), such as the checksum The authentication certificates are interpreted and validated as
(CRC32c) value calculated on the whole packet (not just the header) defined in [RFC4572]. Self-signed certificates can be used securely,
or its multihoming capabilities, present new challenges for NAT provided that the integrity of the SDP description is assured as
traversal. [I-D.ietf-behave-sctpnat] describes an SCTP specific defined in [RFC4572].
variant of NAT, which provides similar features of Network Address
and Port Translation (NAPT).
Current NATs do not typically support SCTP. As an alternative to NOTE: The procedures apply to a specific m- line describing an SCTP
design SCTP specific NATs, Encapsulating SCTP into UDP [RFC6951] association. If an offer or answer contains multiple m- line
makes it possible to use SCTP in networks with legacy NAT and describing SCTP associations, the procedures are applied separately
firewalls not supporting SCTP. to each m- line. The procedures related to SDP attributes apply to
attributes associated with the m- line describing the SCTP
association.
At the time of writing, the work on NAT traversal for SCTP is still EDITOR'S NOTE: The offer/answer proceudres for the max-message-size
work in progress. Additionally, no extension has been defined to value still need to be added.
integrate ICE (Interactive Connectivity Establishment) [RFC5768] with
SCTP and its multihoming capabilities either. Therefore, this
specification does not define how to establish and maintain SCTP
associations using ICE. Should this feature be specified for SCTP in
the future, there will be a need to specify how to use them in an SDP
environment as well.
8. Examples 8.2. Generating the Initial SDP Offer
The following examples show the use of the 'setup' and 'connection' When the offerer creates an offer, if the m- line proto field value
SDP attributes. As discussed in Section 5, the use of these is 'SCTP/DTLS' or 'DTLS/SCTP', the offerer MUST insert an SDP setup
attributes with an SCTP association is identical to their use with a attribute in the offer, in order to determine the TLS roles, and in
TCP connection. For the purpose of brevity, the main portion of the cases where SCTP is transported on TCP, determine which endpoint is
session description is omitted in the examples, which only show 'm' responsible for establishing the TCP connection [Section 7.2].
lines and their attributes (including 'c' lines).
8.1. Actpass/Passive The offerer MAY insert an SDP connection attribute, with a 'new'
value, in the offer.
An offerer at 192.0.2.2 signals its availability for an SCTP If the value of the m- line proto field is set to 'DTLS/SCTP', the
association at SCTP port 54111. Additionally, this offerer is also offerer MAY insert an SDP sctp-port attribute, with a value
willing to initiate the SCTP association: indicating the local SCTP port, in the offer.
m=application 54111 SCTP t38 8.3. Generating the SDP Answer
c=IN IP4 192.0.2.2
a=setup:actpass
a=connection:new
Figure 1 When the answerer receives an offer, which contains an m- line
describing an SCTP association, it MUST insert a corresponding m-
line, with an identical m- line proto field value, in the associated
answer, following the procedures in [RFC3264].
The endpoint at 192.0.2.1 responds with the following description: If the answerer accepts the offered m- line, it assigns the other m-
line field values according to Section 4.
m=application 54321 SCTP t38 If the offer contains an SDP setup attribute, the answerer MUST
c=IN IP4 192.0.2.1 insert a setup attribute in the answer, following the rules in
a=setup:passive [RFC4572] and [RFC4145] (if applicable).
a=connection:new
Figure 2 If the value of the m- line proto field is set to 'DTLS/SCTP', the
answerer MAY insert an SDP sctp-port attribute, with a value
indicating the local SCTP port, in the answer.
This will cause the offerer (at 192.0.2.2) to initiate an SCTP Once the answerer has sent the answer, if the SCTP association
association to port 54321 at 192.0.2.1. associated with the m- line has yet not been established, or if an
existing SCTP association is to be re-established, the answer MUST
start establishing the SCTP association towards the peer.
8.2. Existing Connection Reuse If the answerer does not accept the m- line in the offer, it MUST
assign a zero value to the port field of the corresponding m- line in
the answer. In addition, the answerer MUST NOT insert an SDP setup
attribute, or an SDP sctp-port attribute, in the answer.
Subsequent to the exchange in Section 8.1, another offer/answer 8.4. Offerer Processing of the SDP Answer
exchange is initiated in the opposite direction. The endpoint at
192.0.2.1, which now acts as the offerer, wishes to continue using
the existing association:
m=application 54321 SCTP * When the offerer receives an answer, if the SCTP association
c=IN IP4 192.0.2.1 associated with the m- line has not yet been established, or if an
a=setup:passive existing SCTP association is to be re-established, the offerer MUST
a=connection:existing start establishing the SCTP association towards the peer.
Figure 3 If the m- line port field value in the answer is zero, the offerer
MUST terminate the SCTP association (if it exists) associated with
the m- line.
The endpoint at 192.0.2.2 also wishes to use the existing SCTP 8.5. Modifying the Session
association and responds with the following description:
m=application 54111 SCTP * When an offerer sends an updated offer, in order to modify a
c=IN IP4 192.0.2.2 previously negotiated SCTP association, it follows the rules in
a=setup:active Section 8.2, with the following exceptions:
a=connection:existing
Figure 4 If the offerer wants to re-establish an existing SCTP association
associated with the m- line, the offerer MUST insert an SDP
connection attribute, with a 'new' value, in the offer.
The existing SCTP association between 192.0.2.2 and 192.0.2.1 will be If the m- line proto field value is 'SCTP/DTLS' or 'DTLS/SCTP', and
reused. the offer is not intended to re-establish the DTLS connection, the
offerer MUST NOT insert a SDP setup attribute with a value that
changes the previously determined TLS roles in the offer.
8.3. SDP description for SCTP over DTLS Connection If the offerer wants to disable a previously established SCTP
association, it MUST set the port value of the m- line associated
with the SCTP association to zero, following the procedures in
[RFC3264]. The offerer MUST NOT insert an SDP setup attribute, or an
SDP sctp-port attribute, in the offer.
This example shows the usage of SCTP over DTLS. NOTE: Different SCTP association applications might define protocol
procedures etc that need to be performed before an SCTP association
is terminated. Such procedures are outside the scope of this
specification.
An offerer at 192.0.2.2 signals the availability of a webrtc- 9. Multihoming Considerations
DataChannel session over SCTP/DTLS. The DTLS connection runs on top
of port 54111. The sctp association runs on port 5000 (i.e. sctp-
port) over DTLS. The maximum message size, in bytes, the endpoint is
willing to accept is 100000 (i.e. max-message-size).
m=application 54111 DTLS/SCTP webrtc-datachannel SCTP supports multihoming. An SCTP endpoint is considered multihomed
a=fmtp:webrtc-datachannel max-message-size=100000 if it has more than one IP address on which SCTP can be used. An
a=sctp-port 5000 SCTP endpoint inform the remote peer about its IP addresses using the
c=IN IP4 192.0.2.2 address parameters in the INIT/INIT-ACK chunk. Therefore, when SDP
a=setup:actpass is used to describe an SCTP association, while the "c=" line contains
a=connection:new the address which was used to negotiate the SCTP association,
a=fingerprint:SHA-1 \ multihomed SCTP endpoints might end up using other IP addresses.
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 5 If an endpoint removes the IP address [RFC5061] that it offered in
the SDP "c=" line associated with the SCTP association, it MUST send
a new Offer, in which the "c=" line contains an IP address with is
valid within the SCTP association.
The endpoint at 192.0.2.1 responds with the following description: NOTE: In some network environments, intermediaries performing gate-
and firewall control use the address information in the SDP "c=" and
"m=" lines to authorize media, and will not pass media sent using
other addresses. In such network environment, if an SCTP endpoints
wants to change the address information on which media is sent and
received, it needs to send an updated Offer, in which the SDP "c="
and "m=" lines contain the new address information.
m=application 62442 DTLS/SCTP webrtc-datachannel Multihoming is not supported when sending SCTP on top of DTLS, as
a=fmtp:webrtc-datachannel max-message-size=100000 DTLS does not expose address management to its upper layer.
a=sctp-port 5000
c=IN IP4 192.0.2.1
a=setup:actpass
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 6 10. NAT Considerations
8.4. SDP description for SCTP over DTLS Connection using default values 10.1. General
This example shows the usage of SCTP over DTLS when default values SCTP features not present in UDP or TCP, including the checksum
are used. (CRC32c) value calculated on the whole packet (rather than just the
header), and multihoming, introduce new challenges for NAT traversal.
[I-D.ietf-behave-sctpnat] defines an SCTP specific variant of NAT,
which provides similar features of Network Address and Port
Translation (NAPT).
An offerer at 192.0.2.2 signals the availability of a webrtc- Current NATs typically do not support SCTP. [RFC6951] defines a
DataChannel session over SCTP/DTLS. The DTLS connection runs on top mechanism for sending SCTP on top of UDP, which makes it possible to
of port 54111. As the sctp association runs on the default sct-port use SCTP with NATs and firewalls that do not support SCTP.
number 5000 over DTLS ant the maximum message size, in bytes, the
endpoint is willing to accept is equal to the default value of 64K
both the parameters may be omitted.
Note that as the sctp association is meant to be used to transport 10.2. ICE Considerations
webrtc data channel, the association-usage parameter is present with
the webrtc-datachannel value.
m=application 54111 DTLS/SCTP webrtc-datachannel At the time of writing this specification, no procedures have been
c=IN IP4 192.0.2.2 defined for using ICE ICE (Interactive Connectivity Establishment)
a=setup:actpass [RFC5768] together with SCTP. Such procedures, including the
a=connection:new associated SDP Offer/Answer procedures, are outside the scope of this
a=fingerprint:SHA-1 \ specification, and might be defined in a future specification.
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 7 11. Examples
The endpoint at 192.0.2.1 responds with the following description, TODO: ADD EXAMPLES HERE
with default value for the sctp-port and max-message-size parameters:
m=application 62442 DTLS/SCTP webrtc-datachannel 12. Security Considerations
c=IN IP4 192.0.2.1
a=setup:actpass
a=connection:new
a=fingerprint:SHA-1 \
4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:AB
Figure 8 [RFC4566] defines general SDP security considerations, while
[RFC3264], [RFC4145] and [RFC4572] define security considerations
when using the SDP Offer/Answer mechanism to negotiate media streams.
9. Security Considerations [RFC4960] defines general SCTP security considerations. security
considerations on SCTP in general, while [RFC6083] defines security
considerations when using DTLS on top of SCTP.
See RFC 4566 [RFC4566] for security considerations on the use of SDP This specification does not introduce new security considerations in
in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572 addition to those defined in the specifications listed above.
[RFC4572] for security considerations on establishing media streams
using offer/answer exchanges. See RFC 4960 [RFC4960] for security
considerations on SCTP in general and [RFC6083] for security
consideration using DTLS on top of SCTP. This specification does not
introduce any new security consideration in addition to the ones
discussed in those specifications.
10. IANA Considerations 13. IANA Considerations
This document defines three new proto values: 'SCTP', 'SCTP/DTLS' and 13.1. New SDP proto values
'DTLS/SCTP'. Their formats are defined in Section 3. These proto
values should be registered by the IANA under "Session Description [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
Protocol (SDP) Parameters" under "proto". document.]
This document updates the "Session Description Protocol (SDP)
Parameters" registry, following the procedures in [RFC4566], by
adding the following values to the table in the SDP "proto" field
registry:
+-------+-----------+-----------+
| Type | SDP Name | Reference |
+-------+-----------+-----------+
| proto | SCTP | [RFCXXXX] |
| proto | SCTP/DTLS | [RFCXXXX] |
| proto | DTLS/SCTP | [RFCXXXX] |
+-------+-----------+-----------+
Table 1: SDP "proto" field values
13.2. New SDP Attribute
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
This document defines a new SDP media-level attribute,'sctp-port', as
follows:
Attribute name: sctp-port
Type of attribute: media
Subject to charset: No
Purpose: Indicate the SCTP port value associated
with the SDP Media Description.
Appropriate values: Integer
Contact name: Christer Holmberg
Contact e-mail: christer.holmberg@ericsson.com
Reference: RFCXXXX
13.3. association-usage Name Registry
[RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
document.]
This specification creates a new IANA registry, following the
procedures in [RFC5226], for the "fmt" namespace associated with the
'SCTP', 'SCTP/DTLS' and 'DTLS/SCTP' protocol identifiers. Each "fmt"
value describes the usage of an entire SCTP association, including
all SCTP streams associated with the SCTP association.
NOTE: Usage indication of individual SCTP streams is outside the
scope of this specification.
The "fmt" value, "association-usage", used with these "proto" is The "fmt" value, "association-usage", used with these "proto" is
required. It is defined in section Section 4.1. required. It is defined in section Section 4.
[Note] TBD whether a new registry is necessary to register the As part of this registry, IANA maintains the following information:
different possible "association-usage" values.
10.1. sctp-port attribute association-usage Name: .The identifier of the subprotocol, as will
be used in the <sctp-fmtp> subfield.
This document defines a new SDP session and media-level attribute: association-usage reference: A reference to the document in which
the the association usage is defined.
sctp-port: Its format is define in section Section 4.1.This association-usage names are to be subject to the "First Come First
attribute should be registered by IANA under "Session Description Served" IANA registration policy [RFC5226].
Protocol (SDP) Parameters" under "att-field" (both session and
media level)".
11. Acknowledgments IANA is asked to add initial values to the registry.
| name | Reference |
-+--------------------+-------------------------------------+
| webrtc-datachannel | draft-ietf-rtcweb-data-protocol-xx |
-+----------------------------------------------------------|
Figure 1
14. Acknowledgments
The authors wish to thank Harald Alvestrand, Randell Jesup, Paul The authors wish to thank Harald Alvestrand, Randell Jesup, Paul
Kyzivat, Michael Tuexen for their comments and useful feedback. Kyzivat, Michael Tuexen for their comments and useful feedback.
12. References 15. References
12.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, June with Session Description Protocol (SDP)", RFC 3264, June
2002. 2002.
[RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in [RFC4145] Yon, D. and G. Camarillo, "TCP-Based Media Transport in
the Session Description Protocol (SDP)", RFC 4145, the Session Description Protocol (SDP)", RFC 4145,
September 2005. September 2005.
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", RFC 4288, December 2005.
[RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail [RFC4289] Freed, N. and J. Klensin, "Multipurpose Internet Mail
Extensions (MIME) Part Four: Registration Procedures", BCP Extensions (MIME) Part Four: Registration Procedures", BCP
13, RFC 4289, December 2005. 13, RFC 4289, December 2005.
[RFC4347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security", RFC 4347, April 2006.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006. Description Protocol", RFC 4566, July 2006.
[RFC4572] Lennox, J., "Connection-Oriented Media Transport over the [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
Transport Layer Security (TLS) Protocol in the Session Transport Layer Security (TLS) Protocol in the Session
Description Protocol (SDP)", RFC 4572, July 2006. Description Protocol (SDP)", RFC 4572, July 2006.
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC [RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC
4960, September 2007. 4960, September 2007.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, September Dynamic Address Reconfiguration", RFC 5061, September
2007. 2007.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
Security Version 1.2", RFC 6347, January 2012.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC
6838, January 2013.
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS Tuexen, M., Stewart, R., Jesup, R., and S. Loreto, "DTLS
Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp- Encapsulation of SCTP Packets", draft-ietf-tsvwg-sctp-
dtls-encaps-04 (work in progress), May 2014. dtls-encaps-06 (work in progress), November 2014.
12.2. Informative References
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport 15.2. Informative References
Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, January 2011. Transmission Protocol (SCTP)", RFC 6083, January 2011.
[RFC5768] Rosenberg, J., "Indicating Support for Interactive [RFC5768] Rosenberg, J., "Indicating Support for Interactive
Connectivity Establishment (ICE) in the Session Initiation Connectivity Establishment (ICE) in the Session Initiation
Protocol (SIP)", RFC 5768, April 2010. Protocol (SIP)", RFC 5768, April 2010.
[RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream [RFC6951] Tuexen, M. and R. Stewart, "UDP Encapsulation of Stream
Control Transmission Protocol (SCTP) Packets for End-Host Control Transmission Protocol (SCTP) Packets for End-Host
to End-Host Communication", RFC 6951, May 2013. to End-Host Communication", RFC 6951, May 2013.
[I-D.ietf-behave-sctpnat] [I-D.ietf-behave-sctpnat]
Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control Stewart, R., Tuexen, M., and I. Ruengeler, "Stream Control
Transmission Protocol (SCTP) Network Address Translation", Transmission Protocol (SCTP) Network Address Translation",
draft-ietf-behave-sctpnat-09 (work in progress), September draft-ietf-behave-sctpnat-09 (work in progress), September
2013. 2013.
Authors' Addresses Authors' Addresses
Christer Holmberg
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: christer.holmberg@ericsson.com
Salvatore Loreto Salvatore Loreto
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
Finland Finland
Email: Salvatore.Loreto@ericsson.com Email: Salvatore.Loreto@ericsson.com
Gonzalo Camarillo Gonzalo Camarillo
Ericsson Ericsson
 End of changes. 114 change blocks. 
362 lines changed or deleted 462 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/