draft-ietf-tsvwg-sctp-dtls-encaps-02.txt   draft-ietf-tsvwg-sctp-dtls-encaps-03.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: April 23, 2014 Adara Networks Expires: August 11, 2014 Adara Networks
R. Jesup R. Jesup
WorldGate Communications WorldGate Communications
S. Loreto S. Loreto
Ericsson Ericsson
October 20, 2013 February 7, 2014
DTLS Encapsulation of SCTP Packets DTLS Encapsulation of SCTP Packets
draft-ietf-tsvwg-sctp-dtls-encaps-02.txt draft-ietf-tsvwg-sctp-dtls-encaps-03.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. the Datagram Transport Layer Security (DTLS) protocol.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 23, 2014. This Internet-Draft will expire on August 11, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 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
skipping to change at page 2, line 29 skipping to change at page 2, line 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction 1. Introduction
1.1. Overview 1.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 or IPv6. This document specifies how SCTP is used on protocols IPv4 or IPv6. This document specifies how SCTP is used on
top of the Datagram Transport Layer Security (DTLS) protocol. This top of the Datagram Transport Layer Security (DTLS) protocol defined
encapsulation is used for example within the RTCWeb protocol suite in [RFC6347]. This encapsulation is used for example within the
(see [I-D.ietf-rtcweb-overview] for an overview) for transporting RTCWeb protocol suite (see [I-D.ietf-rtcweb-overview] for an
non-media data between browsers. The architecture of this stack is overview) for transporting non-media data between browsers. The
described in [I-D.ietf-rtcweb-data-channel]. architecture of this stack is described in
[I-D.ietf-rtcweb-data-channel].
1.2. Terminology 1.2. Terminology
This document uses the following terms: This document uses the following terms:
Association: An SCTP association. Association: An SCTP association.
Stream: A unidirectional stream of an SCTP association. It is Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by a stream identifier. uniquely identified by a stream identifier.
skipping to change at page 4, line 4 skipping to change at page 3, line 47
DTLS user to enforce that the corresponding IPv4 packet is sent with DTLS user to enforce that the corresponding IPv4 packet is sent with
the DF bit set. the DF bit set.
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.
5. SCTP Considerations 5. SCTP Considerations
5.1. Base Protocol 5.1. Base Protocol
SCTP as specified in [RFC4960] is used. However, the following SCTP as specified in [RFC4960] is used. However, the following
restrictions are necessary to reflect that the lower layer is the restrictions are necessary to reflect that the lower layer is the
connection oriented protocol DTLS instead of the connection less connection-oriented protocol DTLS instead of the connection less
protocol IPv4 and IPv6: protocol IPv4 and IPv6:
o A DTLS connection MUST be established before an SCTP association o A DTLS connection MUST be established before an SCTP association
can be set up. can be set up.
o All associations MUST be single-homed. o All associations MUST be single-homed.
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.
skipping to change at page 4, line 38 skipping to change at page 4, line 34
[RFC4821]. [RFC4821].
5.3. Dynamic Address Reconfiguration Extension 5.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, only wildcard addresses MUST be used in ASCONF chunks.
5.4. SCTP Authentication Extension 5.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 require any additional benefit. with DTLS encapsulation, but does not provide any additional benefit.
5.5. Partial Reliability Extension 5.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
additional PR-SCTP policies. additional PR-SCTP policies.
5.6. Stream Reset Extension 5.6. Stream Reset Extension
The SCTP stream reset extension defined in [RFC6525] can be used with The SCTP stream reset extension defined in [RFC6525] can be used with
DTLS encapsulation. It is used to reset streams and add streams DTLS encapsulation. It is used to reset streams and add streams
during the lifetime of the SCTP association. during the lifetime of the SCTP association.
5.7. Interleaving of Large User Message 5.7. Interleaving of Large User Messages
SCTP as defined in [RFC4960] does not support the interleaving of SCTP as defined in [RFC4960] does not support the interleaving of
large user messages that need to be fragmented and reassembled by the large user messages that need to be fragmented and reassembled by the
SCTP layer. The protocol extension defined in SCTP layer. The protocol extension defined in
[I-D.stewart-tsvwg-sctp-ndata] overcomes this limitation can can be [I-D.ietf-tsvwg-sctp-ndata] overcomes this limitation can can be used
used with DTLS encapsulation. with DTLS encapsulation.
6. IANA Considerations 6. IANA Considerations
This document requires no actions from IANA. This document requires no actions from IANA.
7. Security Considerations 7. Security Considerations
Security considerations for DTLS are specified in [RFC6347] and for Security considerations for DTLS are specified in [RFC6347] 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.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
Transmission Protocol (SCTP) Stream Reconfiguration", RFC Transmission Protocol (SCTP) Stream Reconfiguration", RFC
6525, February 2012. 6525, February 2012.
[I-D.ietf-rtcweb-overview] [I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for Brower- Alvestrand, H., "Overview: Real Time Protocols for Brower-
based Applications", draft-ietf-rtcweb-overview-08 (work based Applications", draft-ietf-rtcweb-overview-08 (work
in progress), September 2013. in progress), September 2013.
[I-D.ietf-rtcweb-data-channel] [I-D.ietf-rtcweb-data-channel]
Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data Jesup, R., Loreto, S., and M. Tuexen, "RTCWeb Data
Channels", draft-ietf-rtcweb-data-channel-05 (work in Channels", draft-ietf-rtcweb-data-channel-06 (work in
progress), July 2013. progress), October 2013.
[I-D.stewart-tsvwg-sctp-ndata] [I-D.ietf-tsvwg-sctp-ndata]
Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, "A
New Data Chunk for Stream Control Transmission Protocol", New Data Chunk for Stream Control Transmission Protocol",
draft-stewart-tsvwg-sctp-ndata-02 (work in progress), July draft-ietf-tsvwg-sctp-ndata-00 (work in progress),
2013. February 2014.
Authors' Addresses Authors' Addresses
Michael Tuexen Michael Tuexen
Muenster University of Applied Sciences Muenster University of Applied Sciences
Stegerwaldstrasse 39 Stegerwaldstrasse 39
48565 Steinfurt 48565 Steinfurt
DE DE
Email: tuexen@fh-muenster.de Email: tuexen@fh-muenster.de
 End of changes. 14 change blocks. 
20 lines changed or deleted 22 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/