draft-ietf-tram-stun-dtls-03.txt   draft-ietf-tram-stun-dtls-04.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Jive Communications Internet-Draft Jive Communications
Updates: 5389, 5928 (if approved) G. Salgueiro Updates: 5389, 5928 (if approved) G. Salgueiro
Intended status: Standards Track Cisco Systems Intended status: Standards Track Cisco Systems
Expires: December 1, 2014 May 30, 2014 Expires: December 25, 2014 June 23, 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-03 draft-ietf-tram-stun-dtls-04
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 December 1, 2014. This Internet-Draft will expire on December 25, 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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. 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 . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . 6
4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 5 4.5. NAT Behavior Discovery Usage . . . . . . . . . . . . . . 6
4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6 4.6. TURN Usage . . . . . . . . . . . . . . . . . . . . . . . 6
4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6 4.6.1. DTLS Support in TURN URIs . . . . . . . . . . . . . . 6
4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 7
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8 5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 9 7.1. S-NAPTR application protocol tag . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . 11
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
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 . . . . . . . . . . . . . . . . . 13
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 14 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 14
B.1. Modifications between ietf-tram-stun-dtls-02 and ietf- B.1. Modifications between ietf-tram-stun-dtls-03 and ietf-
tram-stun-dtls-03 . . . . . . . . . . . . . . . . . . . . 14 tram-stun-dtls-04 . . . . . . . . . . . . . . . . . . . . 14
B.2. Modifications between ietf-tram-stun-dtls-01 and ietf- B.2. Modifications between ietf-tram-stun-dtls-02 and ietf-
tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 14 tram-stun-dtls-03 . . . . . . . . . . . . . . . . . . . . 15
B.3. Modifications between ietf-tram-stun-dtls-00 and ietf- B.3. Modifications between ietf-tram-stun-dtls-01 and ietf-
tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 15 tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 15
B.4. Modifications between petithuguenin-tram-stun-dtls-00 and B.4. Modifications between ietf-tram-stun-dtls-00 and ietf-
ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 15 tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 16
B.5. Modifications between petithuguenin-tram-turn-dtls-00 and B.5. Modifications between petithuguenin-tram-stun-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 15 ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 B.6. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
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.
TLS-over-UDP (referred to as DTLS [RFC6347]) offers the same security DTLS-over-UDP (referred to in this document as simply DTLS [RFC6347])
advantages as TLS-over-TCP, but without the undesirable latency offers the same security advantages as TLS-over-TCP, but without the
concerns. undesirable latency concerns.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL" The key words "MUST", "MUST NOT", "REQUIRED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in [RFC2119] when in this document are to be interpreted as described in [RFC2119] when
they appear in ALL CAPS. When these words are not in ALL CAPS (such they appear in ALL CAPS. When these words are not in ALL CAPS (such
as "must" or "Must"), they have their usual English meanings, and are as "must" or "Must"), they have their usual English meanings, and are
not to be interpreted as RFC 2119 key words. not to be interpreted as RFC 2119 key words.
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. Instead of TLS_RSA_WITH_AES_128_CBC_SHA, verify the server identity. Instead of TLS_RSA_WITH_AES_128_CBC_SHA,
which is the default cipher suite for STUN over TLS, STUN over DTLS, which is the default cipher suite for STUN over TLS, implementations
at a minimum, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and of STUN over DTLS, and deployed clients and servers, MUST support
MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, and MAY support other
Perfect Forward Secrecy (PFS) cipher suites over non-PFS cipher ciphersuites. Perfect Forward Secrecy (PFS) cipher suites MUST be
suites. The same rules established in Section 7.2.2 of [RFC5389] for preferred over non-PFS cipher suites. Cipher suites with known
keeping open and closing TCP/TLS connections MUST be used as well for weaknesses, such as those based on (single) DES and RC4, MUST NOT be
DTLS associations. used. Implementations MUST disable TLS-level compression. The same
rules established in Section 7.2.2 of [RFC5389] for keeping open and
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 number
over TLS. However, the SRV procedures can be implemented to use a as STUN over TLS. However, the SRV procedures can be implemented to
different port (as described in Section 9 of [RFC5389]). When using use a different port (as described in Section 9 of [RFC5389]). When
SRV records, the service name MUST be set to "stuns" and the using SRV records, the service name MUST be set to "stuns" and the
application name to "udp". protocol name to "udp".
Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST Classic STUN [RFC3489] defines only UDP as a transport and DTLS MUST
NOT be used. Any STUN request or indication without the magic cookie NOT be used. Any STUN request or indication without the magic cookie
over DTLS MUST always result in an error. over DTLS MUST always result in an error.
4. STUN Usages 4. STUN Usages
[RFC5389] Section 7.2 states that STUN usages must specify which [RFC5389] Section 7.2 states that STUN usages must specify which
transport protocol is used. The following sections discuss if and transport protocol is used. The following sections discuss if and
how the existing STUN usages are used with DTLS as the transport. how the existing STUN usages are used with DTLS as the transport.
Future STUN usages MUST take into account DTLS as a transport and Future STUN usages MUST take into account DTLS as a transport and
discuss its applicability. discuss its applicability. In all cases, new STUN usages MUST
explicitly state if implementing the denial-of-service counter-
measure described in Section 4.2.1 of [RFC6347] is mandatory.
4.1. NAT Discovery Usage 4.1. NAT Discovery Usage
As stated by Section 13 of [RFC5389], "...TLS provides minimal As stated by Section 13 of [RFC5389], "...TLS provides minimal
security benefits..." for this particular STUN usage. DTLS will also security benefits..." for this particular STUN usage. DTLS will also
similarly offer only limited benefit. This is because the only similarly offer only limited benefit. This is because the only
mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED- mandatory attribute that is TLS/DTLS protected is the XOR-MAPPED-
ADDRESS, which is already known by an on-path attacker, since it is ADDRESS, which is already known by an on-path attacker, since it is
the same as the source address and port of the STUN request. On the the same as the source address and port of the STUN request. On the
other hand, using TLS/DTLS will prevent an active attacker to inject other hand, using TLS/DTLS will prevent an active attacker to inject
skipping to change at page 4, line 43 skipping to change at page 5, line 5
protect the SOFTWARE attribute, which can be used to find protect the SOFTWARE attribute, which can be used to find
vulnerabilities in STUN implementations. vulnerabilities in STUN implementations.
Regardless, this usage is rarely used by itself, since using TURN Regardless, this usage is rarely used by itself, since using TURN
[RFC5766] with ICE [RFC5245] is generally indispensable, and TURN [RFC5766] with ICE [RFC5245] is generally indispensable, and TURN
provides the same NAT Discovery feature as part of an Allocation provides the same NAT Discovery feature as part of an Allocation
creation. In fact, with ICE, the NAT Discovery usage is only used creation. In fact, with ICE, the NAT Discovery usage is only used
when there is no longer any resource available for new Allocations in when there is no longer any resource available for new Allocations in
the TURN server. the TURN server.
A STUN server implementing the NAT Discovery Usage and using DTLS
MUST implement the denial-of-service counter-measure described in
Section 4.2.1 of [RFC6347].
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. A STUN URI containing an of [RFC5389] to verify the server identity. A STUN URI containing an
IP address MUST be rejected, unless the domain is provided by the IP address MUST be rejected, unless the domain is provided by the
skipping to change at page 5, line 26 skipping to change at page 5, line 41
Adding DTLS on top of the connectivity check would delay, and Adding DTLS on top of the connectivity check would delay, and
consequently impair, the ICE process. There is, in fact, a proposal consequently impair, the ICE process. There is, in fact, a proposal
([I-D.thomson-rtcweb-ice-dtls]) to use the DTLS handshake used by the ([I-D.thomson-rtcweb-ice-dtls]) to use the DTLS handshake used by the
WebRTC SRTP streams as a replacement for the connectivity checks, WebRTC SRTP streams as a replacement for the connectivity checks,
proving that adding additional round-trips to ICE is undesirable. proving that adding additional round-trips to ICE is undesirable.
STUN URIs are not used with this usage. STUN URIs are not used with this usage.
4.3. Media Keep-Alive Usage 4.3. Media Keep-Alive Usage
The media keep-alive (described in Section 10 of [RFC5245]) runs When STUN Binding Indications are being used for media keep-alive
alongside an RTP or RTCP session. It is possible to send the media (described in Section 10 of xref target="RFC5245" />), it runs
alongside an RTP or RTCP session. It is possible to send these media
keep-alive packets inside a separately negotiated non-SRTP DTLS keep-alive packets inside a separately negotiated non-SRTP DTLS
session if DTLS-SRTP [RFC5764] is used, but that would add overhead, session if DTLS-SRTP [RFC5764] is used, but that would add overhead,
with minimal security benefit. with minimal security benefit.
STUN URIs are not used with this usage. STUN URIs are not used with this usage.
4.4. SIP Keep-Alive Usage 4.4. SIP Keep-Alive Usage
The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow. The SIP keep-alive (described in [RFC5626]) runs inside a SIP flow.
This flow would be protected if a SIP over DTLS transport mechanism This flow would be protected if a SIP over DTLS transport mechanism
skipping to change at page 6, line 7 skipping to change at page 6, line 25
The NAT Behavior Discovery usage is Experimental and to date has The NAT Behavior Discovery usage is Experimental and to date has
never being effectively deployed. Despite this, using DTLS would add never being effectively deployed. Despite this, using DTLS would add
the same security properties as for the NAT Discovery Usage the same security properties as for the NAT Discovery Usage
(Section 4.1). (Section 4.1).
The STUN URI can be used to access the NAT Discovery feature of a NAT The STUN URI can be used to access the NAT Discovery feature of a NAT
Behavior Discovery server, but accessing the full features would Behavior Discovery server, but accessing the full features would
require definition of a "stun-behaviors:" URI, which is out of scope require definition of a "stun-behaviors:" URI, which is out of scope
for this document. for this document.
A STUN server implementing the NAT Behavior Discovery Usage and using
DTLS MUST implement the denial-of-service counter-measure described
in Section 4.2.1 of [RFC6347].
4.6. TURN Usage 4.6. TURN Usage
TURN [RFC5766] defines three combinations of transports/allocations: TURN [RFC5766] defines three combinations of transports/allocations:
UDP/UDP, TCP/UDP and TLS/UDP. This document adds DTLS/UDP as a valid UDP/UDP, TCP/UDP and TLS/UDP. This document adds DTLS/UDP as a valid
combination. A TURN server using DTLS MUST implement the denial-of- combination. A TURN server using DTLS MUST implement the denial-of-
service counter-measure described in Section 4.2.1 of [RFC6347]. service counter-measure described in Section 4.2.1 of [RFC6347].
[RFC6062] states that TCP allocations cannot be obtained using a UDP [RFC6062] states that TCP allocations cannot be obtained using a UDP
association between client and server. The fact that DTLS uses UDP association between client and server. The fact that DTLS uses UDP
implies that TCP allocations MUST NOT be obtained using a DTLS implies that TCP allocations MUST NOT be obtained using a DTLS
association between client and server. association between client and server.
By default, TURN over DTLS uses port 5349, the same port as TURN over By default, TURN over DTLS uses port 5349, the same port number as
TLS. However, the SRV procedures can be implemented to use a TURN over TLS. However, the SRV procedures can be implemented to use
different port (as described in Section 6 of [RFC5766]. When using a different port (as described in Section 6 of [RFC5766]. When using
SRV records, the service name MUST be set to "turns" and the SRV records, the service name MUST be set to "turns" and the protocol
application name to "udp". 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 The <host> value MUST be used when using the rules in Section 7.2.2
skipping to change at page 10, line 15 skipping to change at page 10, line 37
Application Protocol Tag: turn.dtls Application Protocol Tag: turn.dtls
Intended Usage: See Section 4.6.2 Intended Usage: See Section 4.6.2
Interoperability considerations: N/A Interoperability considerations: N/A
Security considerations: See Section 6 Security considerations: See Section 6
Relevant publications: This document Relevant publications: This document
Contact information: Marc Petit-Huguenin Contact information: Marc Petit-Huguenin <petithug@acm.org>
Author/Change controller: The IESG Author/Change controller: The IESG
7.2. Service Name and Transport Protocol Port Number 7.2. Service Name and Transport Protocol Port Number
This specification contains the registration information for two This specification contains the registration information for two
Service Name and Transport Protocol Port Numbers in the "Service Service Name and Transport Protocol Port Numbers in the "Service
Names and Transport Protocol Port Numbers/Service Name and Transport Names and Transport Protocol Port Numbers/Service Name and Transport
Protocol Port Number" registry (in accordance with [RFC6335]). Protocol Port Number" registry (in accordance with [RFC6335]).
skipping to change at page 10, line 31 skipping to change at page 11, line 4
This specification contains the registration information for two This specification contains the registration information for two
Service Name and Transport Protocol Port Numbers in the "Service Service Name and Transport Protocol Port Numbers in the "Service
Names and Transport Protocol Port Numbers/Service Name and Transport Names and Transport Protocol Port Numbers/Service Name and Transport
Protocol Port Number" registry (in accordance with [RFC6335]). Protocol Port Number" registry (in accordance with [RFC6335]).
7.2.1. The stuns Service Name 7.2.1. The stuns Service Name
Service Name: stuns Service Name: stuns
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG Assignee: IESG
Contact: Marc Petit-Huguenin Contact: IETF Chair <chair@ietf.org>
Description: STUN over DTLS Description: STUN over DTLS
Reference: This document Reference: This document
Port Number: 5349 Port Number: 5349
7.2.2. The turns Service Name 7.2.2. The turns Service Name
Service Name: turns Service Name: turns
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG Assignee: IESG
Contact: Marc Petit-Huguenin Contact: IETF Chair <chair@ietf.org>
Description: TURN over DTLS Description: TURN over DTLS
Reference: This document Reference: This document
Port Number: 5349 Port Number: 5349
8. Acknowledgements 8. Acknowledgements
Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, and Thomas Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, Thomas
Stach for the comments, suggestions, and questions that helped Stach, Simon Josefsson, and Roni Even for the comments, suggestions,
improve this document. and questions that helped improve this document.
9. References 9. References
9.1. Normative References 9.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.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
skipping to change at page 14, line 18 skipping to change at page 14, line 44
| 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-02 and ietf-tram-stun- B.1. Modifications between ietf-tram-stun-dtls-03 and ietf-tram-stun-
dtls-04
o Add text to disable TLS compression.
o Add text to require usage of the DTLS cookie for NAT discovery and
NAT behavior discovery.
o Add text to so new usages talk about cookie usage.
o Change TLS-over-UDP to DTLS-over-UDP and use DTLS as alias for
DTLS over UDP..
o Use new text proposed by Simon Josefsson for the cipher suites.
o s/the same port/the same port number/
o s/application name/protocol name/
o Make clear that section 4.3 is only about the STUN Indication
method of media keep-alive.
o Changed contact information to IETF Chair in Port number template.
o Added email addresses in IANA templates.
B.2. Modifications between ietf-tram-stun-dtls-02 and ietf-tram-stun-
dtls-03 dtls-03
o Make it clear that both cipher suites are mandatory. o Make it clear that both cipher suites are mandatory.
o Clarify that the ciphers suites listed are replacing the TLS o Clarify that the ciphers suites listed are replacing the TLS
cipher suites. cipher suites.
o Change text so "mandatory" is not understood as compliance. o Change text so "mandatory" is not understood as compliance.
o Clarify that STUN URI are not to be used with some usages. o Clarify that STUN URI are not to be used with some usages.
skipping to change at page 14, line 40 skipping to change at page 15, line 43
o Fix incorrect interpretation of ICE media keep-alive (and fixed o Fix incorrect interpretation of ICE media keep-alive (and fixed
section #). section #).
o Explain that sending media keep-alive inside DTLS is possible if o Explain that sending media keep-alive inside DTLS is possible if
RFC 5764 is used. RFC 5764 is used.
o Added title/subtitle of IANA registries. o Added title/subtitle of IANA registries.
o Change to normatively update RFC 5389 and RFC 5928. o Change to normatively update RFC 5389 and RFC 5928.
B.2. Modifications between ietf-tram-stun-dtls-01 and ietf-tram-stun- B.3. Modifications between ietf-tram-stun-dtls-01 and ietf-tram-stun-
dtls-02 dtls-02
o Add text saying that PFS is preferred over non-PFS, to be in sync o Add text saying that PFS is preferred over non-PFS, to be in sync
with the decision in the rtcweb session in London. with the decision in the rtcweb session in London.
o Add text about IP address in STUN/TURN URIs. o Add text about IP address in STUN/TURN URIs.
o Nits o Nits
B.3. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun- B.4. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun-
dtls-01 dtls-01
o Update the mandatory cipher suites. o Update the mandatory cipher suites.
o Add 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 Close remaining opening items from previous draft. o Close remaining opening items from previous draft.
B.4. Modifications between petithuguenin-tram-stun-dtls-00 and ietf- B.5. 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.5. Modifications between petithuguenin-tram-turn-dtls-00 and B.6. 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. 30 change blocks. 
60 lines changed or deleted 103 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/