draft-ietf-tsvwg-sctp-dtls-encaps-08.txt   draft-ietf-tsvwg-sctp-dtls-encaps-09.txt 
Network Working Group M. Tuexen Network Working Group M. Tuexen
Internet-Draft Muenster Univ. of Appl. Sciences Internet-Draft Muenster Univ. of Appl. Sciences
Intended status: Standards Track R. Stewart Intended status: Standards Track R. Stewart
Expires: July 19, 2015 Netflix, Inc. Expires: July 28, 2015 Netflix, Inc.
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
S. Loreto S. Loreto
Ericsson Ericsson
January 15, 2015 January 24, 2015
DTLS Encapsulation of SCTP Packets DTLS Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-dtls-encaps-08.txt draft-ietf-tsvwg-sctp-dtls-encaps-09.txt
Abstract Abstract
The Stream Control Transmission Protocol (SCTP) is a transport The Stream Control Transmission Protocol (SCTP) is a transport
protocol originally defined to run on top of the network protocols protocol originally defined to run on top of the network protocols
IPv4 or IPv6. This document specifies how SCTP can be used on top of IPv4 or IPv6. This document specifies how SCTP can be used on top of
the Datagram Transport Layer Security (DTLS) protocol. Using the the Datagram Transport Layer Security (DTLS) protocol. Using the
encapsulation method described in this document, SCTP is unaware of encapsulation method described in this document, SCTP is unaware of
the protocols being used below DTLS; hence explicit IP addresses the protocols being used below DTLS; hence explicit IP addresses
cannot be used in the SCTP control chunks. As a consequence, the cannot be used in the SCTP control chunks. As a consequence, the
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 July 19, 2015. This Internet-Draft will expire on July 28, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 2, line 21 skipping to change at page 2, line 21
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3 3. Encapsulation and Decapsulation Procedure . . . . . . . . . . 3
4. General Considerations . . . . . . . . . . . . . . . . . . . 3 4. General Considerations . . . . . . . . . . . . . . . . . . . 3
5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 3 5. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 4
6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 9 Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Overview 1. Overview
The Stream Control Transmission Protocol (SCTP) as defined in The Stream Control Transmission Protocol (SCTP) as defined in
[RFC4960] is a transport protocol running on top of the network [RFC4960] is a transport protocol running on top of the network
protocols IPv4 [RFC0791] or IPv6 [RFC2460]. This document specifies protocols IPv4 [RFC0791] or IPv6 [RFC2460]. This document specifies
how SCTP is used on top of the Datagram Transport Layer Security how SCTP is used on top of the Datagram Transport Layer Security
(DTLS) protocol. DTLS 1.0 is defined in [RFC4347] and the present (DTLS) protocol. DTLS 1.0 is defined in [RFC4347] and the latest
latest version, DTLS 1.2, is defined in [RFC6347]. This version when this RFC was published, DTLS 1.2, is defined in
encapsulation is used for example within the WebRTC protocol suite [RFC6347]. This encapsulation is used for example within the WebRTC
(see [I-D.ietf-rtcweb-overview] for an overview) for transporting protocol suite (see [I-D.ietf-rtcweb-overview] for an overview) for
non-SRTP data between browsers. The architecture of this stack is transporting non-SRTP data between browsers. The architecture of
described in [I-D.ietf-rtcweb-data-channel]. this stack is described in [I-D.ietf-rtcweb-data-channel].
[NOTE to RFC-Editor:
Please ensure that the authors double check the above statement
about DTLS 1.2 during AUTH48 and then remove this note before
publication.
]
+----------+ +----------+
| SCTP | | SCTP |
+----------+ +----------+
| DTLS | | DTLS |
+----------+ +----------+
| ICE/UDP | | ICE/UDP |
+----------+ +----------+
Figure 1: Basic stack diagram Figure 1: Basic stack diagram
This encapsulation of SCTP over DTLS over or UDP or ICE/UDP (see This encapsulation of SCTP over DTLS over UDP or ICE/UDP (see
[RFC5245]) can provide a NAT traversal solution together with [RFC5245]) can provide a NAT traversal solution in addition to
confidentiality, source authentication, and integrity protected confidentiality, source authentication, and integrity protected
transfers. transfers. Please note that using ICE does not necessarily imply
that a different packet format is used on the wire.
Please note that the procedures defined in [RFC6951] for dealing with Please note that the procedures defined in [RFC6951] for dealing with
the UDP port numbers do not apply here. When using the encapsulation the UDP port numbers do not apply here. When using the encapsulation
defined in this document, SCTP is unaware about the protocols used defined in this document, SCTP is unaware about the protocols used
below DTLS. below DTLS.
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 3, line 46 skipping to change at page 4, line 8
implementation of "Packetization Layer Path MTU Discovery" [RFC4821] implementation of "Packetization Layer Path MTU Discovery" [RFC4821]
either in SCTP or DTLS is RECOMMENDED. either in SCTP or DTLS is RECOMMENDED.
The path MTU discovery is performed by SCTP when SCTP over DTLS is The path MTU discovery is performed by SCTP when SCTP over DTLS is
used for data channels (see Section 5 of used for data channels (see Section 5 of
[I-D.ietf-rtcweb-data-channel]). [I-D.ietf-rtcweb-data-channel]).
5. DTLS Considerations 5. DTLS Considerations
The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD The DTLS implementation MUST support DTLS 1.0 [RFC4347] and SHOULD
support the most recently published version of DTLS, which is DTLS support the most recently published version of DTLS, which was DTLS
1.2 [RFC6347] as of December 2014. In the absence of a revision to 1.2 [RFC6347] when this RFC was published. In the absence of a
this document, the latter requirement applies to all future versions revision to this document, the latter requirement applies to all
of DTLS when they are published as RFCs. This document will only be future versions of DTLS when they are published as RFCs. This
revised if a revision to DTLS or SCTP makes a revision to the document will only be revised if a revision to DTLS or SCTP makes a
encapsulation necessary. revision to the encapsulation necessary.
[NOTE to RFC-Editor:
Please ensure that the authors double check the above statement
about DTLS 1.2 during AUTH48 and then remove this note before
publication.
]
SCTP performs segmentation and reassembly based on the path MTU. SCTP performs segmentation and reassembly based on the path MTU.
Therefore the DTLS layer MUST NOT use any compression algorithm. Therefore the DTLS layer MUST NOT use any compression algorithm.
The DTLS MUST support sending messages larger than the current path The DTLS MUST support sending messages larger than the current path
MTU. This might result in sending IP level fragmented messages. MTU. This might result in sending IP level fragmented messages.
If path MTU discovery is performed by the DTLS layer, the method If path MTU discovery is performed by the DTLS layer, the method
described in [RFC4821] MUST be used. For probe packets, the described in [RFC4821] MUST be used. For probe packets, the
extension defined in [RFC6520] MUST be used. extension defined in [RFC6520] MUST be used.
skipping to change at page 5, line 23 skipping to change at page 5, line 42
o All SCTP associations are single-homed, because DTLS does not o All SCTP associations are single-homed, because DTLS does not
expose any address management to its upper layer. Therefore it is expose any address management to its upper layer. Therefore it is
RECOMMENDED to set the SCTP parameter path.max.retrans to RECOMMENDED to set the SCTP parameter path.max.retrans to
association.max.retrans. association.max.retrans.
o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or o The INIT and INIT-ACK chunk MUST NOT contain any IPv4 Address or
IPv6 Address parameters. The INIT chunk MUST NOT contain the IPv6 Address parameters. The INIT chunk MUST NOT contain the
Supported Address Types parameter. Supported Address Types parameter.
o The implementation MUST NOT rely on processing ICMP or ICMPv6 o The implementation MUST NOT rely on processing ICMP or ICMPv6
packets. This applies in particular to path MTU discovery when packets, since the SCTP layer most likely is unable to access the
performed by SCTP. SCTP common header in the plain text of the packet, which
triggered the sending of the ICMP or ICMPv6 packet. This applies
in particular to path MTU discovery when performed by SCTP.
o If the SCTP layer is notified about a path change by its lower o If the SCTP layer is notified about a path change by its lower
layers, SCTP SHOULD retest the Path MTU and reset the congestion layers, SCTP SHOULD retest the Path MTU and reset the congestion
state to the initial state. The window-based congestion control state to the initial state. The window-based congestion control
method specified in [RFC4960], resets the congestion window and method specified in [RFC4960], resets the congestion window and
slow start threshold to their initial values. slow start threshold to their initial values.
6.2. Padding Extension 6.2. Padding Extension
When the SCTP layer performs path MTU discovery as specified in When the SCTP layer performs path MTU discovery as specified in
skipping to change at page 6, line 48 skipping to change at page 7, line 17
It should be noted that the inability to process ICMP or ICMPv6 It should be noted that the inability to process ICMP or ICMPv6
messages does not add any security issue. When SCTP is carried over messages does not add any security issue. When SCTP is carried over
a connection-less lower layer like IPv4, IPv6, or UDP, processing of a connection-less lower layer like IPv4, IPv6, or UDP, processing of
these messages is required to protect other nodes not supporting these messages is required to protect other nodes not supporting
SCTP. Since DTLS provides a connection-oriented lower layer, this SCTP. Since DTLS provides a connection-oriented lower layer, this
kind of protection is not necessary. kind of protection is not necessary.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank David Black, Spencer Dawkins, Francis The authors wish to thank David Black, Benoit Claise, Spencer
Dupont, Gorry Fairhurst, Christer Holmberg, Eric Rescorla, Tom Dawkins, Francis Dupont, Gorry Fairhurst, Stephen Farrell, Christer
Taylor, Joe Touch and Magnus Westerlund for their invaluable Holmberg, Barry Leiba, Eric Rescorla, Tom Taylor, Joe Touch and
comments. Magnus Westerlund for their invaluable comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[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.
 End of changes. 13 change blocks. 
28 lines changed or deleted 46 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/