draft-ietf-tram-stun-dtls-01.txt   draft-ietf-tram-stun-dtls-02.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Jive Communications Internet-Draft Jive Communications
Intended status: Standards Track G. Salgueiro Intended status: Standards Track G. Salgueiro
Expires: September 25, 2014 Cisco Systems Expires: November 2, 2014 Cisco Systems
March 24, 2014 May 1, 2014
Datagram Transport Layer Security (DTLS) as Transport for Session Datagram Transport Layer Security (DTLS) as Transport for Session
Traversal Utilities for NAT (STUN) Traversal Utilities for NAT (STUN)
draft-ietf-tram-stun-dtls-01 draft-ietf-tram-stun-dtls-02
Abstract Abstract
This document specifies the usage of Datagram Transport Layer This document specifies the usage of Datagram Transport Layer
Security (DTLS) as a transport protocol for Session Traversal Security (DTLS) as a transport protocol for Session Traversal
Utilities for NAT (STUN). It provides guidances on when and how to Utilities for NAT (STUN). It provides guidances on when and how to
use DTLS with the currently standardized STUN Usages. It also use DTLS with the currently standardized STUN Usages. It also
specifies modifications to the STUN URIs and TURN URIs and to the specifies modifications to the STUN URIs and TURN URIs and to the
TURN resolution mechanism to facilitate the resolution of STUN URIs TURN resolution mechanism to facilitate the resolution of STUN URIs
and TURN URIs into the IP address and port of STUN and TURN servers and TURN URIs into the IP address and port of STUN and TURN servers
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 September 25, 2014. This Internet-Draft will expire on November 2, 2014.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3 3. DTLS as Transport for STUN . . . . . . . . . . . . . . . . . 3
4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4 4.1. NAT Discovery Usage . . . . . . . . . . . . . . . . . . . 4
4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 4 4.1.1. DTLS Support in STUN URIs . . . . . . . . . . . . . . 4
4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5 4.2. Connectivity Check Usage . . . . . . . . . . . . . . . . 5
4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5 4.3. Media Keep-Alive Usage . . . . . . . . . . . . . . . . . 5
4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 5 4.4. SIP Keep-Alive Usage . . . . . . . . . . . . . . . . . . 5
4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5
4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6
skipping to change at page 2, line 40 skipping to change at page 2, line 40
7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9 7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9
7.2. Service Name and Transport Protocol Port Number . . . . . 10 7.2. Service Name and Transport Protocol Port Number . . . . . 10
7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10 7.2.1. The stuns Service Name . . . . . . . . . . . . . . . 10
7.2.2. The turns Service Name . . . . . . . . . . . . . . . 10 7.2.2. The turns Service Name . . . . . . . . . . . . . . . 10
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13
B.1. Modifications between ietf-tram-stun-dtls-00 and ietf- B.1. Modifications between ietf-tram-stun-dtls-01 and ietf-
tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 13 tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 13
B.2. Modifications between petithuguenin-tram-stun-dtls-00 and B.2. Modifications between ietf-tram-stun-dtls-00 and ietf-
tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 14
B.3. Modifications between petithuguenin-tram-stun-dtls-00 and
ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 14 ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 14
B.3. Modifications between petithuguenin-tram-turn-dtls-00 and B.4. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 14 petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
STUN [RFC5389] defines Transport Layer Security (TLS) over TCP STUN [RFC5389] defines Transport Layer Security (TLS) over TCP
(simply referred to as TLS [RFC5246]) as the transport for STUN due (simply referred to as TLS [RFC5246]) as the transport for STUN due
to additional security advantages it offers over plain UDP or TCP to additional security advantages it offers over plain UDP or TCP
transport. But TLS-over-TCP is not an optimal transport when STUN is transport. But TLS-over-TCP is not an optimal transport when STUN is
used for its originally intended purpose, which is to support used for its originally intended purpose, which is to support
multimedia sessions. This sub-optimality primarily stems from the multimedia sessions. This sub-optimality primarily stems from the
added latency incurred by the TCP-based head-of-line (HOL) blocking added latency incurred by the TCP-based head-of-line (HOL) blocking
problem coupled with additional TLS buffering (for integrity checks). problem coupled with additional TLS buffering (for integrity checks).
This is a well documented and understood transport limitation for This is a well documented and understood transport limitation for
secure real-time communications. secure real-time communications.
skipping to change at page 3, line 40 skipping to change at page 3, line 37
3. DTLS as Transport for STUN 3. DTLS as Transport for STUN
STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This STUN [RFC5389] defines three transports: UDP, TCP, and TLS. This
document adds DTLS as a valid transport for STUN. document adds DTLS as a valid transport for STUN.
STUN over DTLS MUST use the same retransmission rules as STUN over STUN over DTLS MUST use the same retransmission rules as STUN over
UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use UDP (as described in Section 7.2.1 of [RFC5389]). It MUST also use
the same rules that are described in Section 7.2.2 of [RFC5389] to the same rules that are described in Section 7.2.2 of [RFC5389] to
verify the server identity. STUN over DTLS MUST, at a minimum, verify the server identity. STUN over DTLS MUST, at a minimum,
support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. [[TODO: Do we want to specify TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS MUST prefer
that implementations MUST favor cipher suites which support PFS over TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward
non-PFS cipher suites]]. The same rules established in Section 7.2.2 Secrecy (PFS) cipher suites over non-PFS cipher suites. The same
of [RFC5389] for keeping open and closing TCP/TLS connections MUST be rules established in Section 7.2.2 of [RFC5389] for keeping open and
used as well for DTLS associations. closing TCP/TLS connections MUST be used as well for DTLS
associations.
In addition to the path MTU rules described in Section 7.1 of In addition to the path MTU rules described in Section 7.1 of
[RFC5389], if the path MTU is unknown, the actual STUN message needs [RFC5389], if the path MTU is unknown, the actual STUN message needs
to be adjusted to take into account the size of the (13-byte) DTLS to be adjusted to take into account the size of the (13-byte) DTLS
Record header, the MAC size, the padding size and the eventual Record header, the MAC size, the padding size and the eventual
compression applied to the payload. compression applied to the payload.
By default, STUN over DTLS MUST use port 5349, the same port as STUN By default, STUN over DTLS MUST use port 5349, the same port as STUN
over TLS. However, the SRV procedures can be implemented to use a over TLS. However, the SRV procedures can be implemented to use a
different port (as described in Section 9 of [RFC5389]). When using different port (as described in Section 9 of [RFC5389]). When using
skipping to change at page 4, line 50 skipping to change at page 4, line 47
longer any resource available for new Allocations in the TURN server. longer any resource available for new Allocations in the TURN server.
4.1.1. DTLS Support in STUN URIs 4.1.1. DTLS Support in STUN URIs
This document does not make any changes to the syntax of a STUN URI This document does not make any changes to the syntax of a STUN URI
[RFC7064]. As indicated in Section 3.2 of [RFC7064], secure [RFC7064]. As indicated in Section 3.2 of [RFC7064], secure
transports like STUN over TLS, and now STUN over DTLS, MUST use the transports like STUN over TLS, and now STUN over DTLS, MUST use the
"stuns" URI scheme. "stuns" URI scheme.
The <host> value MUST be used when using the rules in Section 7.2.2 The <host> value MUST be used when using the rules in Section 7.2.2
of [RFC5389] to verify the server identity. [[TODO: What happens if of [RFC5389] to verify the server identity. A STUN URI containing an
an IP address is used in the URI? Should we forbid that?]] IP address MUST be rejected, unless the domain is provided by the
same mechanism that provided the STUN URI, and that this domain name
can be passed to the verification code.
4.2. Connectivity Check Usage 4.2. Connectivity Check Usage
Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE- Using DTLS would hide the USERNAME, PRIORITY, USE-CANDIDATE, ICE-
CONTROLLED and ICE-CONTROLLING attributes. But because MESSAGE- CONTROLLED and ICE-CONTROLLING attributes. But because MESSAGE-
INTEGRITY protects the entire STUN response using a password that is INTEGRITY protects the entire STUN response using a password that is
known only by looking at the SDP exchanged, it is not possible for an known only by looking at the SDP exchanged, it is not possible for an
attacker to inject an incorrect XOR-MAPPED-ADDRESS, which would attacker to inject an incorrect XOR-MAPPED-ADDRESS, which would
subsequently be used as a peer reflexive candidate. subsequently be used as a peer reflexive candidate.
skipping to change at page 6, line 31 skipping to change at page 6, line 31
application name to "udp". application name to "udp".
4.6.1. DTLS Support in TURN URIs 4.6.1. DTLS Support in TURN URIs
This document does not make any changes to the syntax of a TURN URI This document does not make any changes to the syntax of a TURN URI
[RFC7065]. As indicated in Section 3 of [RFC7065], secure transports [RFC7065]. As indicated in Section 3 of [RFC7065], secure transports
like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI like TURN over TLS, and now TURN over DTLS, MUST use the "turns" URI
scheme. When using the "turns" URI scheme to designate TURN over scheme. When using the "turns" URI scheme to designate TURN over
DTLS, the transport value of the TURN URI, if set, MUST be "udp". DTLS, the transport value of the TURN URI, if set, MUST be "udp".
The <host> value MUST be used when using the rules in Section 7.2.2
of [RFC5389] to verify the server identity. A TURN URI containing an
IP address MUST be rejected, unless the domain is provided by the
same mechanism that provided the TURN URI, and that this domain name
can be passed to the verification code.
4.6.2. Resolution Mechanism for TURN over DTLS 4.6.2. Resolution Mechanism for TURN over DTLS
This document defines a new Straightforward Naming Authority Pointer This document defines a new Straightforward Naming Authority Pointer
(S-NAPTR) application protocol tag: "turn.dtls". (S-NAPTR) application protocol tag: "turn.dtls".
The <transport> component, as provisioned or resulting from the The <transport> component, as provisioned or resulting from the
parsing of a TURN URI, is passed without modification to the TURN parsing of a TURN URI, is passed without modification to the TURN
resolution mechanism defined in Section 3 of [RFC5928], but with the resolution mechanism defined in Section 3 of [RFC5928], but with the
following alterations to that algorithm: following alterations to that algorithm:
o The acceptable values for transport name are extended with the o The acceptable values for transport name are extended with the
addition of "dtls". addition of "dtls".
o The acceptable values in the ordered list of supported TURN o The acceptable values in the ordered list of supported TURN
transports is extended with the addition of "Datagram Transport transports is extended with the addition of "Datagram Transport
Layer Security (DTLS)". Layer Security (DTLS)".
o The resolution algorithm ckeck rules list is extended with the o The resolution algorithm check rules list is extended with the
addition of the following step: addition of the following step:
If <secure> is true and <transport> is defined as "udp" but the If <secure> is true and <transport> is defined as "udp" but the
list of TURN transports supported by the application does not list of TURN transports supported by the application does not
contain DTLS, then the resolution MUST stop with an error. contain DTLS, then the resolution MUST stop with an error.
o The 5th rule of the resolution algorithm check rules list is o The 5th rule of the resolution algorithm check rules list is
modified to read like this: modified to read like this:
If <secure> is true and <transport> is not defined but the list If <secure> is true and <transport> is not defined but the list
skipping to change at page 13, line 44 skipping to change at page 13, line 49
| 1 | DTLS | 192.0.2.1 | 5349 | | 1 | DTLS | 192.0.2.1 | 5349 |
| 2 | TLS | 192.0.2.1 | 5349 | | 2 | TLS | 192.0.2.1 | 5349 |
+-------+----------+------------+------+ +-------+----------+------------+------+
Table 2 Table 2
Appendix B. Release notes Appendix B. Release notes
This section must be removed before publication as an RFC. This section must be removed before publication as an RFC.
B.1. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun- B.1. Modifications between ietf-tram-stun-dtls-01 and ietf-tram-stun-
dtls-02
o Add text saying that PFS is preferred over non-PFS, to be in sync
with the decision in the rtcweb session in London.
o Add text about IP address in STUN/TURN URIs.
o Nits
B.2. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun-
dtls-01 dtls-01
o Updated the mandatory cipher suites. o Update the mandatory cipher suites.
o Added a new open item to determine if we want to specify favoring o Add a new open item to determine if we want to specify favoring
cipher suites which support PFS over non-PFS cipher suites. cipher suites which support PFS over non-PFS cipher suites.
o Closed remaining opening items from previous draft. o Close remaining opening items from previous draft.
B.2. Modifications between petithuguenin-tram-stun-dtls-00 and ietf- B.3. Modifications between petithuguenin-tram-stun-dtls-00 and ietf-
tram-stun-dtls-00 tram-stun-dtls-00
o Draft renamed after WG adoption. o Draft renamed after WG adoption.
B.3. Modifications between petithuguenin-tram-turn-dtls-00 and B.4. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 petithuguenin-tram-stun-dtls-00
o Add RFC 6982 information for rfc5766-turn-server project. o Add RFC 6982 information for rfc5766-turn-server project.
o Rename the draft as TURN is now just one of the usages. o Rename the draft as TURN is now just one of the usages.
o Remove the references in the abstract to make idnits happy. o Remove the references in the abstract to make idnits happy.
o No longer updates other standard drafts. o No longer updates other standard drafts.
 End of changes. 17 change blocks. 
24 lines changed or deleted 44 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/