draft-ietf-mmusic-sctp-sdp-00.txt   draft-ietf-mmusic-sctp-sdp-01.txt 
MMUSIC S. Loreto MMUSIC S. Loreto
Internet-Draft G. Camarillo Internet-Draft G. Camarillo
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: January 5, 2012 July 4, 2011 Expires: September 13, 2012 March 12, 2012
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-00 draft-ietf-mmusic-sctp-sdp-01
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. This document
describes how to express media transport over SCTP in SDP (Session describes how to express media transport over SCTP in SDP (Session
Description Protocol). This document defines the 'SCTP' and 'SCTP/ Description Protocol). This document defines the 'SCTP', 'SCTP/DTLS'
DTLS' protocol identifiers for SDP. and 'DTLS/SCTP' protocol identifiers for SDP.
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, 2012. This Internet-Draft will expire on September 13, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Identifier . . . . . . . . . . . . . . . . . . . . . 4
4. The Setup and Connection Attributes and Association 4. The Setup and Connection Attributes and Association
Management . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Management . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Multihoming . . . . . . . . . . . . . . . . . . . . . . . . . 5
6. Network Address Translation (NAT) Considerations . . . . . . . 5 6. Network Address Translation (NAT) Considerations . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Actpass/Passive . . . . . . . . . . . . . . . . . . . . . 6
7.2. Existing Connection Reuse . . . . . . . . . . . . . . . . . 6 7.2. Existing Connection Reuse . . . . . . . . . . . . . . . . 7
7.3. SDP description for DTLS Connection . . . . . . . . . . . . 7 7.3. SDP description for DTLS Connection . . . . . . . . . . . 7
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . . 9 10.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
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. RFC4145 [RFC4145] specifies a general mechanism for invitations. RFC4145 [RFC4145] specifies a general mechanism for
describing and establishing TCP (Transmission Control Protocol) describing and establishing TCP (Transmission Control Protocol)
streams. RFC 4572 [RFC4572] extends RFC4145 [RFC4145] for describing streams. RFC 4572 [RFC4572] extends RFC4145 [RFC4145] for describing
TCP-based media streams that are protected using TLS (Transport Layer TCP-based media streams that are protected using TLS (Transport Layer
Security) [RFC5246]. Security) [RFC5246].
This document defines a new protocol identifier, 'SCTP', to describe This document defines a new protocol identifier, 'SCTP', to describe
SCTP-based [RFC4960] media streams. Additionally, this document SCTP-based [RFC4960] media streams. Additionally, this document
specifies the use of the 'setup' and 'connection' SDP attributes to specifies the use of the 'setup' and 'connection' SDP attributes to
establish SCTP associations. These attributes were defined in establish SCTP associations. These attributes were defined in
RFC4145 [RFC4145] for TCP. This document discusses their use with RFC4145 [RFC4145] for TCP. This document discusses their use with
SCTP. SCTP.
Additionally this document defines a new protocol identifier, 'SCTP/ Additionally this document defines two new protocol identifiers:
DTLS', to establish secure SCTP-based media streams over DTLS
(Datagram Transport Layer Security) [RFC4347], as specified in SCTP/DTLS : to allow the usage of the Datagram Transport Layer
[RFC6083], using SDP. The authentication certificates are Security (DTLS) [RFC4347] protocol over SCTP, as specified in
interpreted and validated as defined in RFC4572 [RFC4572]. Self- [RFC6083], using SDP. DTLS over SCTP provides communications
signed certificates can be used securely, provided that the integrity privacy for applications that use SCTP as their transport
of the SDP description is assured as defined in RFC4572 [RFC4572]. protocol.
DTLS/SCTP : to allow the usage of SCTP on top of the Datagram
Transport Layer Security (DTLS) protocol, as defined in
[I-D.tuexen-tsvwg-sctp-dtls-encaps], using SDP. SCTP over DTLS is
used by the RTCWeb protocol suite for transporting non- media data
between browsers.
The authentication certificates are interpreted and validated as
defined in RFC4572 [RFC4572]. Self-signed certificates can be used
securely, provided that the integrity of the SDP description is
assured as defined in RFC4572 [RFC4572].
TLS is designed to run on top of a byte-stream oriented transport TLS is designed to run on top of a byte-stream oriented transport
protocol providing a realible, in-sequence delivery like TCP. Since protocol providing a realible, in-sequence delivery like TCP. Since
no-one so far has implemented SCTP over TLS, due to some serious no-one so far has implemented SCTP over TLS, due to some serious
limitations described in [RFC6083], this document does not make use limitations described in [RFC6083], this document does not make use
of TLS over SCTP as described in RFC3436 [RFC3436]. of TLS over SCTP as described in RFC3436 [RFC3436].
2. Terminology 2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
skipping to change at page 4, line 5 skipping to change at page 4, line 14
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. Protocol Identifier
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 two new values for the 'proto' field: 'SCTP' This document defines three new values for the 'proto' field: 'SCTP',
and 'SCTP/DTLS'. 'SCTP/DTLS' and 'DTLS/SCTP'.
The 'SCTP' protocol identifier is similar to both the 'UDP' and 'TCP' The 'SCTP' protocol identifier is similar to both the 'UDP' and 'TCP'
protocol identifiers in that it only describes the transport protocol protocol identifiers in that it only describes the transport protocol
and not the upper-layer protocol. Media described using an 'm' line and not the upper-layer protocol. Media described using an 'm' line
containing the 'SCTP' protocol identifier are carried using SCTP containing the 'SCTP' protocol identifier are carried using SCTP
[RFC4960]. [RFC4960].
The 'SCTP/DTLS' protocol identifier indicates that the media The 'SCTP/DTLS' protocol identifier indicates that the media
described will use the Datagram Transport Layer Security (DTLS) described will use the Datagram Transport Layer Security (DTLS)
[RFC4347] over SCTP as specified in [RFC6083]. [RFC4347] over SCTP as specified in [RFC6083].
An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' MUST further qualify The 'DTLS/SCTP' protocol identifier indicates that the media
the application-layer protocol using an fmt identifier. described will use SCTP on top of the Datagram Transport Layer
Security (DTLS) protocol as specified in
[I-D.tuexen-tsvwg-sctp-dtls-encaps].
An 'm' line that specifies 'SCTP/DTLS' MUST further provide a An 'm' line that specifies 'SCTP' or 'SCTP/DTLS' or 'DTLS/SCTP' MUST
certificate fingerprint. An SDP attribute (an 'a' line) is used to further qualify the application-layer protocol using an fmt
transport and exchange end point certificate. The authentication identifier.
certificates are interpreted and validated as defined in [RFC4572].
An 'm' line that specifies 'SCTP/DTLS' or 'DTLS/SCTP' MUST further
provide a certificate fingerprint. An SDP 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. The Setup and Connection Attributes and Association Management 4. The Setup and Connection Attributes and Association Management
The use of the 'setup' and 'connection' attributes in the context of The use of the 'setup' and 'connection' attributes in the context of
an SCTP association is identical to the use of these attributes in 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 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 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 the use of the 'setup' and 'connection' attributes in offer/answer
[RFC3264] exchanges. [RFC3264] exchanges.
skipping to change at page 5, line 26 skipping to change at page 5, line 43
the addresses in offer/answer exchanges to perform media the addresses in offer/answer exchanges to perform media
authorization. That is, policy-enforcement network elements do not authorization. That is, policy-enforcement network elements do not
let media through unless it is sent to the address in the 'c' line. let media through unless it is sent to the address in the 'c' line.
In such network environments, the SCTP endpoints can only exchange In such network environments, the SCTP endpoints can only exchange
media using the IP addresses listed in their 'c' lines. In these media using the IP addresses listed in their 'c' lines. In these
environments, an endpoint wishing to use a different address needs to 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) update its 'c' line (e.g., by sending a re-INVITE with a new offer)
so that it contains the new IP address. so that it contains the new IP address.
It is worth to underline that when using SCTP on top of DTLS, only
single homed SCTP associations can be used, since DTLS does not
expose any address management to its upper layer.
6. Network Address Translation (NAT) Considerations 6. Network Address Translation (NAT) Considerations
SCTP specific features (not present in UDP/TCP), such as the checksum SCTP specific features (not present in UDP/TCP), such as the checksum
(CRC32c) value calculated on the whole packet (not just the header) (CRC32c) value calculated on the whole packet (not just the header)
or its multihoming capabilities, present new challenges for NAT or its multihoming capabilities, present new challenges for NAT
traversal. [I-D.ietf-behave-sctpnat] describes an SCTP specific traversal. [I-D.ietf-behave-sctpnat] describes an SCTP specific
variant of NAT, which provides similar features of Network Address variant of NAT, which provides similar features of Network Address
and Port Translation (NAPT). and Port Translation (NAPT).
Current NATs do not typically support SCTP. As an alternative to Current NATs do not typically support SCTP. As an alternative to
skipping to change at page 7, line 45 skipping to change at page 8, line 27
in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572 in general. See RFC 3264 [RFC3264], RFC 4145 [RFC4145] and RFC 4572
[RFC4572] for security considerations on establishing media streams [RFC4572] for security considerations on establishing media streams
using offer/answer exchanges. See RFC 4960 [RFC4960] for security using offer/answer exchanges. See RFC 4960 [RFC4960] for security
considerations on SCTP in general and [RFC6083] for security considerations on SCTP in general and [RFC6083] for security
consideration using DTLS on top of SCTP. This specification does not consideration using DTLS on top of SCTP. This specification does not
introduce any new security consideration in addition to the ones introduce any new security consideration in addition to the ones
discussed in those specifications. discussed in those specifications.
9. IANA Considerations 9. IANA Considerations
This document defines two new proto values: 'SCTP' and 'SCTP/DTLS'. This document defines three new proto values: 'SCTP', 'SCTP/DTLS' and
Their formats are defined in Section 3. These proto values should be 'DTLS/SCTP'. Their formats are defined in Section 3. These proto
registered by the IANA under "Session Description Protocol (SDP) values should be registered by the IANA under "Session Description
Parameters" under "proto". Protocol (SDP) Parameters" under "proto".
The SDP specification, [RFC4566], states that specifications defining The SDP specification, [RFC4566], states that specifications defining
new proto values, like the SCTP and SCTP/DTLS proto values defined in new proto values, like the SCTP, SCTP/DTLS and DTLS/SCTP proto values
this RFC, must define the rules by which their media format (fmt) defined in this RFC, must define the rules by which their media
namespace is managed. For the SCTP protocol, new formats SHOULD have format (fmt) namespace is managed. For the SCTP protocol, new
an associated MIME registration. Use of an existing MIME subtype for formats SHOULD have an associated MIME registration. Use of an
the format is encouraged. If no MIME subtype exists, it is existing MIME subtype for the format is encouraged. If no MIME
RECOMMENDED that a suitable one is registered through the IETF subtype exists, it is RECOMMENDED that a suitable one is registered
process [RFC4288] [RFC4289] by production of, or reference to, a through the IETF process [RFC4288] [RFC4289] by production of, or
standards-track RFC that defines the transport protocol for the reference to, a standards-track RFC that defines the transport
format. protocol for the format.
10. References 10. References
10.1. Normative References 10.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, with Session Description Protocol (SDP)", RFC 3264,
skipping to change at page 9, line 10 skipping to change at page 9, line 41
RFC 4960, September 2007. RFC 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, Dynamic Address Reconfiguration", RFC 5061,
September 2007. September 2007.
[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.
[I-D.tuexen-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS
Encapsulation of SCTP Packets for RTCWEB",
draft-tuexen-tsvwg-sctp-dtls-encaps-00 (work in progress),
March 2012.
10.2. Informative References 10.2. Informative References
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, December 2002. 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.
 End of changes. 15 change blocks. 
50 lines changed or deleted 78 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/