draft-ietf-tram-stun-dtls-02.txt   draft-ietf-tram-stun-dtls-03.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Jive Communications Internet-Draft Jive Communications
Intended status: Standards Track G. Salgueiro Updates: 5389, 5928 (if approved) G. Salgueiro
Expires: November 2, 2014 Cisco Systems Intended status: Standards Track Cisco Systems
May 1, 2014 Expires: December 1, 2014 May 30, 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-02 draft-ietf-tram-stun-dtls-03
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 November 2, 2014. This Internet-Draft will expire on December 1, 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 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 . . . . . . . . . . . . . . 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 34 skipping to change at page 2, line 34
4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6 4.6.2. Resolution Mechanism for TURN over DTLS . . . . . . . 6
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 7
5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. turnuri . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8 5.2. rfc5766-turn-server . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . 12
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 13
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 13 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 14
B.1. Modifications between ietf-tram-stun-dtls-01 and ietf- B.1. Modifications between ietf-tram-stun-dtls-02 and ietf-
tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 13 tram-stun-dtls-03 . . . . . . . . . . . . . . . . . . . . 14
B.2. Modifications between ietf-tram-stun-dtls-00 and ietf- B.2. Modifications between ietf-tram-stun-dtls-01 and ietf-
tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 14 tram-stun-dtls-02 . . . . . . . . . . . . . . . . . . . . 14
B.3. Modifications between petithuguenin-tram-stun-dtls-00 and B.3. Modifications between ietf-tram-stun-dtls-00 and ietf-
ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 14 tram-stun-dtls-01 . . . . . . . . . . . . . . . . . . . . 15
B.4. Modifications between petithuguenin-tram-turn-dtls-00 and B.4. Modifications between petithuguenin-tram-stun-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 14 ietf-tram-stun-dtls-00 . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 B.5. Modifications between petithuguenin-tram-turn-dtls-00 and
petithuguenin-tram-stun-dtls-00 . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
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 35 skipping to change at page 3, line 38
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. STUN over DTLS MUST, at a minimum, verify the server identity. Instead of TLS_RSA_WITH_AES_128_CBC_SHA,
support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and MUST support which is the default cipher suite for STUN over TLS, STUN over DTLS,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS MUST prefer at a minimum, MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 and
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other Perfect Forward MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. STUN over DTLS
Secrecy (PFS) cipher suites over non-PFS cipher suites. The same MUST prefer TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 and any other
rules established in Section 7.2.2 of [RFC5389] for keeping open and Perfect Forward Secrecy (PFS) cipher suites over non-PFS cipher
closing TCP/TLS connections MUST be used as well for DTLS suites. The same rules established in Section 7.2.2 of [RFC5389] for
associations. 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 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 33 skipping to change at page 4, line 36
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
XOR-MAPPED-ADDRESS in responses. The TLS/DTLS transport will also XOR-MAPPED-ADDRESS in responses. The TLS/DTLS transport will also
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 TURN [RFC5766] Regardless, this usage is rarely used by itself, since using TURN
is generally mandatory to use with ICE [RFC5245], and TURN provides [RFC5766] with ICE [RFC5245] is generally indispensable, and TURN
the same NAT Discovery feature as part of an Allocation creation. In provides the same NAT Discovery feature as part of an Allocation
fact, with ICE, the NAT Discovery usage is only used when there is no creation. In fact, with ICE, the NAT Discovery usage is only used
longer any resource available for new Allocations in the TURN server. when there is no 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. A STUN URI containing an of [RFC5389] to verify the server identity. A STUN URI containing an
skipping to change at page 5, line 20 skipping to change at page 5, line 22
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.
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.
This usage MUST NOT be used with a STUN URI. 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 20 of [RFC5245]) runs The media keep-alive (described in Section 10 of [RFC5245]) runs
inside an RTP or RTCP session, so it is already protected if the RTP alongside an RTP or RTCP session. It is possible to send the media
or RTCP session is also protected (i.e., SRTP/SRTCP). Adding DTLS keep-alive packets inside a separately negotiated non-SRTP DTLS
inside the SRTP/SRTCP session would add overhead, with minimal session if DTLS-SRTP [RFC5764] is used, but that would add overhead,
security benefit. with minimal security benefit.
This usage MUST NOT be used with a STUN URI. 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
is implemented (such as described in [I-D.jennings-sip-dtls]). is implemented (such as described in [I-D.jennings-sip-dtls]).
This usage MUST NOT be used with a STUN URI. STUN URIs are not used with this usage.
4.5. NAT Behavior Discovery Usage 4.5. NAT Behavior Discovery Usage
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
skipping to change at page 9, line 44 skipping to change at page 9, line 50
The new S-NAPTR application protocol tag defined in this document as The new S-NAPTR application protocol tag defined in this document as
well as the modifications this document makes to the TURN resolution well as the modifications this document makes to the TURN resolution
mechanism described in [RFC5928] do not introduce any additional mechanism described in [RFC5928] do not introduce any additional
security considerations beyond those outlined in [RFC5928]. security considerations beyond those outlined in [RFC5928].
7. IANA Considerations 7. IANA Considerations
7.1. S-NAPTR application protocol tag 7.1. S-NAPTR application protocol tag
This specification contains the registration information for one This specification contains the registration information for one
S-NAPTR application protocol tag (in accordance with [RFC3958]). S-NAPTR application protocol tag in the "Straightforward-NAPTR
(S-NAPTR) Parameters/S-NAPTR Application Protocol Tags" registry (in
accordance with [RFC3958]).
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
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 accordance with Service Name and Transport Protocol Port Numbers in the "Service
[RFC6335]). Names and Transport Protocol Port Numbers/Service Name and Transport
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: Marc Petit-Huguenin
skipping to change at page 10, line 43 skipping to change at page 11, line 4
Service Name: turns Service Name: turns
Transport Protocol(s): UDP Transport Protocol(s): UDP
Assignee: IESG Assignee: IESG
Contact: Marc Petit-Huguenin Contact: Marc Petit-Huguenin
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, and Simon Perreault for the
comments, suggestions, and questions that helped improve this Thanks to Alan Johnston, Oleg Moskalenko, Simon Perreault, and Thomas
document. Stach for the comments, suggestions, 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 11, line 40 skipping to change at page 11, line 46
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client- [RFC5626] Jennings, C., Mahy, R., and F. Audet, "Managing Client-
Initiated Connections in the Session Initiation Protocol Initiated Connections in the Session Initiation Protocol
(SIP)", RFC 5626, October 2009. (SIP)", RFC 5626, October 2009.
[RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer
Security (DTLS) Extension to Establish Keys for the Secure
Real-time Transport Protocol (SRTP)", RFC 5764, May 2010.
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
Relays around NAT (TURN): Relay Extensions to Session Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT [RFC5928] Petit-Huguenin, M., "Traversal Using Relays around NAT
(TURN) Resolution Mechanism", RFC 5928, August 2010. (TURN) Resolution Mechanism", RFC 5928, August 2010.
[RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays [RFC6062] Perreault, S. and J. Rosenberg, "Traversal Using Relays
around NAT (TURN) Extensions for TCP Allocations", RFC around NAT (TURN) Extensions for TCP Allocations", RFC
6062, November 2010. 6062, November 2010.
skipping to change at page 13, line 49 skipping to change at page 14, line 18
| 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-01 and ietf-tram-stun- B.1. Modifications between ietf-tram-stun-dtls-02 and ietf-tram-stun-
dtls-03
o Make it clear that both cipher suites are mandatory.
o Clarify that the ciphers suites listed are replacing the TLS
cipher suites.
o Change text so "mandatory" is not understood as compliance.
o Clarify that STUN URI are not to be used with some usages.
o Fix incorrect interpretation of ICE media keep-alive (and fixed
section #).
o Explain that sending media keep-alive inside DTLS is possible if
RFC 5764 is used.
o Added title/subtitle of IANA registries.
o Change to normatively update RFC 5389 and RFC 5928.
B.2. 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.2. Modifications between ietf-tram-stun-dtls-00 and ietf-tram-stun- B.3. 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.3. Modifications between petithuguenin-tram-stun-dtls-00 and ietf- B.4. 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.4. Modifications between petithuguenin-tram-turn-dtls-00 and B.5. 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. 23 change blocks. 
50 lines changed or deleted 85 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/