draft-ietf-tsvwg-sctp-dtls-encaps-07.txt   draft-ietf-tsvwg-sctp-dtls-encaps-08.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: June 13, 2015 Netflix, Inc. Expires: July 19, 2015 Netflix, Inc.
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
S. Loreto S. Loreto
Ericsson Ericsson
December 10, 2014 January 15, 2015
DTLS Encapsulation of SCTP Packets DTLS Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-dtls-encaps-07.txt draft-ietf-tsvwg-sctp-dtls-encaps-08.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 agnostic encapsulation method described in this document, SCTP is unaware of
about the protocols being used below DTLS, explicit IP addresses can the protocols being used below DTLS; hence explicit IP addresses
not be used in the SCTP control chunks. As a consequence, the SCTP cannot be used in the SCTP control chunks. As a consequence, the
associations are single homed. SCTP associations carried over DTLS can only be single homed.
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 June 13, 2015. This Internet-Draft will expire on July 19, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 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
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. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . . . . . . . . 3
6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 4
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 8 Appendix A. NOTE to the RFC-Editor . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 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 present
latest version, DTLS 1.2, is defined in [RFC6347]. This latest version, DTLS 1.2, is defined in [RFC6347]. This
encapsulation is used for example within the WebRTC protocol suite encapsulation is used for example within the WebRTC protocol suite
(see [I-D.ietf-rtcweb-overview] for an overview) for transporting (see [I-D.ietf-rtcweb-overview] for an overview) for transporting
non-SRTP data between browsers. The architecture of this stack is non-SRTP data between browsers. The architecture of this stack is
described in [I-D.ietf-rtcweb-data-channel]. described in [I-D.ietf-rtcweb-data-channel].
+----------+
| SCTP |
+----------+
| DTLS |
+----------+
| ICE/UDP |
+----------+
Figure 1: Basic stack diagram
This encapsulation of SCTP over DTLS over or UDP or ICE/UDP (see
[RFC5245]) can provide a NAT traversal solution together with
confidentiality, source authentication, and integrity protected
transfers.
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 agnostic 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
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Encapsulation and Decapsulation Procedure 3. Encapsulation and Decapsulation Procedure
skipping to change at page 3, line 23 skipping to change at page 3, line 39
followed by a number of SCTP chunks. followed by a number of SCTP chunks.
4. General Considerations 4. General Considerations
An implementation of SCTP over DTLS MUST implement and use a path An implementation of SCTP over DTLS MUST implement and use a path
maximum transmission unit (MTU) discovery method that functions maximum transmission unit (MTU) discovery method that functions
without ICMP to provide SCTP/DTLS with an MTU estimate. An without ICMP to provide SCTP/DTLS with an MTU estimate. An
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
used for data channels (see Section 5 of
[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 is DTLS
1.2 [RFC6347] as of December 2014. In the absence of a revision to 1.2 [RFC6347] as of December 2014. In the absence of a revision to
this document, the latter requirement applies to all future versions this document, the latter requirement applies to all future versions
of DTLS when they are published as RFCs. This document will only be of DTLS when they are published as RFCs. This document will only be
revised if a revision to DTLS or SCTP makes a revision to the revised if a revision to DTLS or SCTP makes a revision to the
encapsulation necessary. encapsulation necessary.
skipping to change at page 4, line 17 skipping to change at page 4, line 37
sent (see [RFC2474]). This requires the DTLS implementation to pass sent (see [RFC2474]). This requires the DTLS implementation to pass
the value through and the lower layer to allow setting this value. the value through and the lower layer to allow setting this value.
If the lower layer does not support setting the DSCP, then the DTLS If the lower layer does not support setting the DSCP, then the DTLS
user will end up with the default value used by protocol stack. user will end up with the default value used by protocol stack.
Please note that only a single DSCP value can be used for all packets Please note that only a single DSCP value can be used for all packets
belonging to the same SCTP association. belonging to the same SCTP association.
Using explicit congestion notifications (ECN) in SCTP requires the Using explicit congestion notifications (ECN) in SCTP requires the
DTLS layer to pass the ECN bits through and its lower layer to expose DTLS layer to pass the ECN bits through and its lower layer to expose
access to them for sent and received packets (see [RFC3168]). The access to them for sent and received packets (see [RFC3168]). The
implementation of DTLS and its lower layer should provide this implementation of DTLS and its lower layer have to provide this
support. If this is not possible, for example due to implementation support. If this is not possible, for example due to implementation
restrictions, ECN can't be used by SCTP. restrictions, ECN can't be used by SCTP.
6. SCTP Considerations 6. SCTP Considerations
This section describes the usage of the base protocol and the This section describes the usage of the base protocol and the
applicability of various SCTP extensions. applicability of various SCTP extensions.
6.1. Base Protocol 6.1. Base Protocol
skipping to change at page 5, line 5 skipping to change at page 5, line 26
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. This applies in particular to path MTU discovery when
performed by SCTP. performed by SCTP.
o If the SCTP is notified about a path change by its lower layers, o If the SCTP layer is notified about a path change by its lower
SCTP SHOULD retest the Path MTU and reset the congestion state to layers, SCTP SHOULD retest the Path MTU and reset the congestion
the initial state. In case of a window based congestion control state to the initial state. The window-based congestion control
like the one specified in [RFC4960], this means setting the method specified in [RFC4960], resets the congestion window and
congestion window and slow start threshold to its initial values. slow start threshold to their initial values.
6.2. Padding Extension 6.2. Padding Extension
The padding extension defined in [RFC4820] MUST be supported and used When the SCTP layer performs path MTU discovery as specified in
for probe packets when performing path MTU discovery as specified in [RFC4821], the padding extension defined in [RFC4820] MUST be
[RFC4821] by the SCTP layer. supported and used for probe packets (HEARTBEAT chunks bundled with
PADDING chunks [RFC4820]).
6.3. Dynamic Address Reconfiguration Extension 6.3. Dynamic Address Reconfiguration Extension
If the dynamic address reconfiguration extension defined in [RFC5061] If the dynamic address reconfiguration extension defined in [RFC5061]
is used, only wildcard addresses MUST be used in ASCONF chunks. is used, ASCONF chunks MUST use wildcard addresses only.
6.4. SCTP Authentication Extension 6.4. SCTP Authentication Extension
The SCTP authentication extension defined in [RFC4895] can be used The SCTP authentication extension defined in [RFC4895] can be used
with DTLS encapsulation, but does not provide any additional benefit. with DTLS encapsulation, but does not provide any additional benefit.
6.5. Partial Reliability Extension 6.5. Partial Reliability Extension
Partial reliability as defined in [RFC3758] can be used in Partial reliability as defined in [RFC3758] can be used in
combination with DTLS encapsulation. It is also possible to use combination with DTLS encapsulation. It is also possible to use
skipping to change at page 6, line 15 skipping to change at page 6, line 40
8. Security Considerations 8. Security Considerations
Security considerations for DTLS are specified in [RFC4347] and for Security considerations for DTLS are specified in [RFC4347] and for
SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP SCTP in [RFC4960], [RFC3758], and [RFC6525]. The combination of SCTP
and DTLS introduces no new security considerations. and DTLS introduces no new security considerations.
SCTP should not process the IP addresses used for the underlying SCTP should not process the IP addresses used for the underlying
communication since DTLS provides no guarantees about them. communication since DTLS provides no guarantees about them.
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. The processing of these messages does not add any security issue. When SCTP is carried over
messages for SCTP carried over a connection-less lower layer like IP, a connection-less lower layer like IPv4, IPv6, or UDP, processing of
IPv6 or UDP is required to protect nodes not supporting SCTP. Since these messages is required to protect other nodes not supporting
DTLS provides a connection-oriented lower layer, this kind of SCTP. Since DTLS provides a connection-oriented lower layer, this
protection is not necessary. kind of protection is not necessary.
9. Acknowledgments 9. Acknowledgments
The authors wish to thank David Black, Spencer Dawkins, Gorry The authors wish to thank David Black, Spencer Dawkins, Francis
Fairhurst, Christer Holmberg, Eric Rescorla, Joe Touch and Magnus Dupont, Gorry Fairhurst, Christer Holmberg, Eric Rescorla, Tom
Westerlund for their invaluable comments. Taylor, Joe Touch and 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.
skipping to change at page 7, line 39 skipping to change at page 8, line 18
[RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla,
"Authenticated Chunks for the Stream Control Transmission "Authenticated Chunks for the Stream Control Transmission
Protocol (SCTP)", RFC 4895, August 2007. Protocol (SCTP)", RFC 4895, August 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.
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", RFC 5245, April
2010.
[RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control [RFC6525] Stewart, R., Tuexen, M., and P. Lei, "Stream Control
Transmission Protocol (SCTP) Stream Reconfiguration", RFC Transmission Protocol (SCTP) Stream Reconfiguration", RFC
6525, February 2012. 6525, February 2012.
[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-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13 Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014. (work in progress), November 2014.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data Jesup, R., Loreto, S., and M. Tuexen, "WebRTC Data
Channels", draft-ietf-rtcweb-data-channel-12 (work in Channels", draft-ietf-rtcweb-data-channel-13 (work in
progress), September 2014. progress), January 2015.
[I-D.ietf-tsvwg-sctp-prpolicies] [I-D.ietf-tsvwg-sctp-prpolicies]
Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto, Tuexen, M., Seggelmann, R., Stewart, R., and S. Loreto,
"Additional Policies for the Partial Reliability Extension "Additional Policies for the Partial Reliability Extension
of the Stream Control Transmission Protocol", draft-ietf- of the Stream Control Transmission Protocol", draft-ietf-
tsvwg-sctp-prpolicies-05 (work in progress), November tsvwg-sctp-prpolicies-06 (work in progress), December
2014. 2014.
[I-D.ietf-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and a New Data Chunk for the Stream "Stream Schedulers and a New Data Chunk for the Stream
Control Transmission Protocol", draft-ietf-tsvwg-sctp- Control Transmission Protocol", draft-ietf-tsvwg-sctp-
ndata-01 (work in progress), July 2014. ndata-02 (work in progress), January 2015.
Appendix A. NOTE to the RFC-Editor Appendix A. NOTE to the RFC-Editor
Although the references to [I-D.ietf-tsvwg-sctp-prpolicies] and Although the references to [I-D.ietf-tsvwg-sctp-prpolicies] and
[I-D.ietf-tsvwg-sctp-ndata] are informative, put this document in [I-D.ietf-tsvwg-sctp-ndata] are informative, put this document in
REF-HOLD until these two references have been approved and update REF-HOLD until these two references have been approved and update
these references to the corresponding RFCs. these references to the corresponding RFCs.
Authors' Addresses Authors' Addresses
 End of changes. 22 change blocks. 
37 lines changed or deleted 63 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/