draft-ietf-tram-stunbis-01.txt   draft-ietf-tram-stunbis-02.txt 
TRAM M. Petit-Huguenin TRAM M. Petit-Huguenin
Internet-Draft Impedance Mismatch Internet-Draft Impedance Mismatch
Obsoletes: 5389 (if approved) G. Salgueiro Obsoletes: 5389 (if approved) G. Salgueiro
Intended status: Standards Track J. Rosenberg Intended status: Standards Track J. Rosenberg
Expires: August 21, 2015 D. Wing Expires: September 10, 2015 D. Wing
Cisco Cisco
R. Mahy R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
February 17, 2015 March 09, 2015
Session Traversal Utilities for NAT (STUN) Session Traversal Utilities for NAT (STUN)
draft-ietf-tram-stunbis-01 draft-ietf-tram-stunbis-02
Abstract Abstract
Session Traversal Utilities for NAT (STUN) is a protocol that serves Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them. existing NATs, and does not require any special behavior from them.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 August 21, 2015. This Internet-Draft will expire on September 10, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 9 5. STUN Message Structure . . . . . . . . . . . . . . . . . . . 9
6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 11 6. Base Protocol Procedures . . . . . . . . . . . . . . . . . . 11
6.1. Forming a Request or an Indication . . . . . . . . . . . 11 6.1. Forming a Request or an Indication . . . . . . . . . . . 11
6.2. Sending the Request or Indication . . . . . . . . . . . . 12 6.2. Sending the Request or Indication . . . . . . . . . . . . 12
6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 13 6.2.1. Sending over UDP or DTLS-over-UDP . . . . . . . . . . 13
6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 14 6.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . 14
6.2.3. Sending over SCTP-over-UDP or SCTP-over-DTLS-over-UDP 15 6.2.3. Sending over SCTP-over-UDP or SCTP-over-DTLS-over-UDP 15
6.2.4. Sending over TLS-over-TCP or DTLS-over-UDP or SCTP- 6.2.4. Sending over TLS-over-TCP or DTLS-over-UDP or SCTP-
over-DTLS-over-UDP . . . . . . . . . . . . . . . . . 16 over-DTLS-over-UDP . . . . . . . . . . . . . . . . . 17
6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 17 6.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 18
6.3.1. Processing a Request . . . . . . . . . . . . . . . . 18 6.3.1. Processing a Request . . . . . . . . . . . . . . . . 18
6.3.1.1. Forming a Success or Error Response . . . . . . . 19 6.3.1.1. Forming a Success or Error Response . . . . . . . 19
6.3.1.2. Sending the Success or Error Response . . . . . . 20 6.3.1.2. Sending the Success or Error Response . . . . . . 20
6.3.2. Processing an Indication . . . . . . . . . . . . . . 20 6.3.2. Processing an Indication . . . . . . . . . . . . . . 20
6.3.3. Processing a Success Response . . . . . . . . . . . . 20 6.3.3. Processing a Success Response . . . . . . . . . . . . 21
6.3.4. Processing an Error Response . . . . . . . . . . . . 21 6.3.4. Processing an Error Response . . . . . . . . . . . . 21
7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 21 7. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 22
8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 22 8. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 22
8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 22 8.1. STUN URI Scheme Semantics . . . . . . . . . . . . . . . . 23
9. Authentication and Message-Integrity Mechanisms . . . . . . . 23 9. Authentication and Message-Integrity Mechanisms . . . . . . . 24
9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 24 9.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 24
9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24 9.1.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 24
9.1.2. Forming a Request or Indication . . . . . . . . . . . 24 9.1.2. Forming a Request or Indication . . . . . . . . . . . 25
9.1.3. Receiving a Request or Indication . . . . . . . . . . 24 9.1.3. Receiving a Request or Indication . . . . . . . . . . 25
9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 26 9.1.4. Receiving a Response . . . . . . . . . . . . . . . . 26
9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26 9.1.5. Sending Subsequent Requests . . . . . . . . . . . . . 26
9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26 9.2. Long-Term Credential Mechanism . . . . . . . . . . . . . 26
9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 27 9.2.1. HMAC Key . . . . . . . . . . . . . . . . . . . . . . 27
9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 28 9.2.2. Forming a Request . . . . . . . . . . . . . . . . . . 28
9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 28 9.2.2.1. First Request . . . . . . . . . . . . . . . . . . 28
9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 28 9.2.2.2. Subsequent Requests . . . . . . . . . . . . . . . 28
9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 28 9.2.3. Receiving a Request . . . . . . . . . . . . . . . . . 29
9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 30 9.2.4. Receiving a Response . . . . . . . . . . . . . . . . 30
10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 31 10. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . 31
11. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 31 11. Backwards Compatibility with RFC 5389 . . . . . . . . . . . . 32
12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 32 12. Basic Server Behavior . . . . . . . . . . . . . . . . . . . . 32
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 32 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 33
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 33 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 34
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 34 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 35
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 35 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 35
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 36 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 36
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 36 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . 37
14.5. MESSAGE-INTEGRITY2 . . . . . . . . . . . . . . . . . . . 37 14.5. MESSAGE-INTEGRITY2 . . . . . . . . . . . . . . . . . . . 37
14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 38 14.6. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . 38
14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 38 14.7. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 39
14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.8. REALM . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.9. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . 40
14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 40 14.10. PASSWORD-ALGORITHMS . . . . . . . . . . . . . . . . . . 41
14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 41 14.11. PASSWORD-ALGORITHM . . . . . . . . . . . . . . . . . . . 41
14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 42 14.12. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 42
14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 42 14.13. SOFTWARE . . . . . . . . . . . . . . . . . . . . . . . . 42
14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 42 14.14. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 43
15. Security Considerations . . . . . . . . . . . . . . . . . . . 42 14.15. ALTERNATE-DOMAIN . . . . . . . . . . . . . . . . . . . . 43
15. Security Considerations . . . . . . . . . . . . . . . . . . . 43
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 43 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 43
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 43 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . 43
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 43 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . 44
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 44 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . 44
15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 44 15.2.1. Attack I: Distributed DoS (DDoS) against a Target . 45
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 45 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . 45
15.2.3. Attack III: Assuming the Identity of a Client . . . 45 15.2.3. Attack III: Assuming the Identity of a Client . . . 46
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 45 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . 46
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 45 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . 46
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 46 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . 46
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 46 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 46 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . 47
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 47 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . 47
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 48 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 48
17.4. Password Algorithm Registry . . . . . . . . . . . . . . 48 17.4. Password Algorithm Registry . . . . . . . . . . . . . . 49
17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 48 17.4.1. Password Algorithms . . . . . . . . . . . . . . . . 49
17.4.1.1. Salted SHA256 . . . . . . . . . . . . . . . . . 49 17.4.1.1. Salted SHA256 . . . . . . . . . . . . . . . . . 49
17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 49 17.5. STUN UDP and TCP Port Numbers . . . . . . . . . . . . . 49
18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 49 18. Changes since RFC 5389 . . . . . . . . . . . . . . . . . . . 50
19. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 49 19. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
20. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 49 19.1. Normative References . . . . . . . . . . . . . . . . . . 50
21. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 19.2. Informational References . . . . . . . . . . . . . . . . 52
21.1. Normative References . . . . . . . . . . . . . . . . . . 50
21.2. Informational References . . . . . . . . . . . . . . . . 52
Appendix A. C Snippet to Determine STUN Message Types . . . . . 53 Appendix A. C Snippet to Determine STUN Message Types . . . . . 53
Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 54 Appendix B. Release notes . . . . . . . . . . . . . . . . . . . 54
B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 54 B.1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . 54
B.2. Modifications between draft-ietf-tram-stunbis-01 and B.2. Modifications between draft-ietf-tram-stunbis-02 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 54 draft-ietf-tram-stunbis-01 . . . . . . . . . . . . . . . 54
B.3. Modifications between draft-salgueiro-tram-stunbis-02 and B.3. Modifications between draft-ietf-tram-stunbis-01 and
draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55
B.4. Modifications between draft-salgueiro-tram-stunbis-02 and B.4. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 55 draft-ietf-tram-stunbis-00 . . . . . . . . . . . . . . . 55
B.5. Modifications between draft-salgueiro-tram-stunbis-01 and B.5. Modifications between draft-salgueiro-tram-stunbis-02 and
draft-salgueiro-tram-stunbis-01 . . . . . . . . . . . . . 56
B.6. Modifications between draft-salgueiro-tram-stunbis-01 and
draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 56 draft-salgueiro-tram-stunbis-00 . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
The protocol defined in this specification, Session Traversal The protocol defined in this specification, Session Traversal
Utilities for NAT, provides a tool for dealing with NATs. It Utilities for NAT, provides a tool for dealing with NATs. It
provides a means for an endpoint to determine the IP address and port provides a means for an endpoint to determine the IP address and port
allocated by a NAT that corresponds to its private IP address and allocated by a NAT that corresponds to its private IP address and
port. It also provides a way for an endpoint to keep a NAT binding port. It also provides a way for an endpoint to keep a NAT binding
alive. With some extensions, the protocol can be used to do alive. With some extensions, the protocol can be used to do
connectivity checks between two endpoints [RFC5245], or to relay connectivity checks between two endpoints [RFC5245], or to relay
skipping to change at page 4, line 46 skipping to change at page 4, line 49
describes how STUN is utilized to achieve the NAT traversal solution. describes how STUN is utilized to achieve the NAT traversal solution.
Typically, a usage indicates when STUN messages get sent, which Typically, a usage indicates when STUN messages get sent, which
optional attributes to include, what server is used, and what optional attributes to include, what server is used, and what
authentication mechanism is to be used. Interactive Connectivity authentication mechanism is to be used. Interactive Connectivity
Establishment (ICE) [RFC5245] is one usage of STUN. SIP Outbound Establishment (ICE) [RFC5245] is one usage of STUN. SIP Outbound
[RFC5626] is another usage of STUN. In some cases, a usage will [RFC5626] is another usage of STUN. In some cases, a usage will
require extensions to STUN. A STUN extension can be in the form of require extensions to STUN. A STUN extension can be in the form of
new methods, attributes, or error response codes. More information new methods, attributes, or error response codes. More information
on STUN usages can be found in Section 13. on STUN usages can be found in Section 13.
Implementations and deployments of a STUN usage should follow the
recommendations in [I-D.ietf-uta-tls-bcp].
2. Overview of Operation 2. Overview of Operation
This section is descriptive only. This section is descriptive only.
/-----\ /-----\
// STUN \\ // STUN \\
| Server | | Server |
\\ // \\ //
\-----/ \-----/
skipping to change at page 12, line 29 skipping to change at page 12, line 29
packet. Consequently, for IPv4, the actual STUN message would need packet. Consequently, for IPv4, the actual STUN message would need
to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte to be less than 548 bytes (576 minus 20-byte IP header, minus 8-byte
UDP header, assuming no IP options are used). UDP header, assuming no IP options are used).
If the path MTU is unknown for DTLS-over-UDP, the rules described in If the path MTU is unknown for DTLS-over-UDP, the rules described in
the previous paragraph need to be adjusted to take into account the the previous paragraph need to be adjusted to take into account the
size of the (13-byte) DTLS Record header, the MAC size, and the size of the (13-byte) DTLS Record header, the MAC size, and the
padding size. padding size.
If a STUN client needs to send requests that are larger than the MTU, If a STUN client needs to send requests that are larger than the MTU,
or if an application envisions that a response would be larger then or if an application envisions that a response would be larger than
the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as the MTU, then it MUST use SCTP-over-UDP or SCTP-over-DTLS-over-UDP as
transport, unless the purpose of sending an oversized packet is to a transport, unless the purpose of sending an oversized packet is to
probe for MTU characteristics (see [RFC5780]). probe for MTU characteristics (see [RFC5780]).
Adding an ORIGIN attribute to a request, as specified in
[I-D.ietf-tram-stun-origin], may increase the size of a request
beyond the MTU such that it consequently triggers the use of SCTP-
over-UDP or SCTP-over-DTLS-over-UDP as a transport.
6.2. Sending the Request or Indication 6.2. Sending the Request or Indication
The agent then sends the request or indication. This document The agent then sends the request or indication. This document
specifies how to send STUN messages over UDP, TCP, TLS-over-TCP, specifies how to send STUN messages over UDP, TCP, TLS-over-TCP,
DTLS-over-UDP, SCTP-over-UDP, or SCTP-over-DTLS-over-UDP; other DTLS-over-UDP, SCTP-over-UDP, or SCTP-over-DTLS-over-UDP; other
transport protocols may be added in the future. The STUN usage must transport protocols may be added in the future. The STUN usage must
specify which transport protocol is used, and how the agent specify which transport protocol is used, and how the agent
determines the IP address and port of the recipient. Section 8 determines the IP address and port of the recipient. Section 8
describes a DNS-based method of determining the IP address and port describes a DNS-based method of determining the IP address and port
of a server that a usage may elect to use. STUN may be used with of a server that a usage may elect to use. STUN may be used with
anycast addresses, but only with UDP and in usages where anycast addresses, but only with UDP and in usages where
authentication is not used. authentication is not used.
At any time, a client MAY have multiple outstanding STUN requests At any time, a client MAY have multiple outstanding STUN requests
with the same STUN server (that is, multiple transactions in with the same STUN server (that is, multiple transactions in
progress, with different transaction IDs). Absent other limits to progress, with different transaction IDs). Absent other limits to
the rate of new transactions (such as those specified by ICE for the rate of new transactions (such as those specified by ICE for
connectivity checks or when STUN is run over TCP), a client SHOULD connectivity checks or when STUN is run over TCP), a client SHOULD
space new transactions to a server by RTO and SHOULD limit itself to space new parallel transactions to a server by RTO and SHOULD limit
ten outstanding transactions to the same server. itself to ten outstanding transactions to the same server.
Parallel transactions are defined as transactions that can be sent
independently of each other. Serial transactions, on the other hand,
are a series of transactions that are each dependent on the
completion of the previous transaction (e.g., the second transaction
of a long term authentication). In contrast to parallel
transactions, a client need not space new serial transactions to a
server by RTO.
6.2.1. Sending over UDP or DTLS-over-UDP 6.2.1. Sending over UDP or DTLS-over-UDP
When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it When running STUN over UDP or STUN over DTLS-over-UDP [RFC7350], it
is possible that the STUN message might be dropped by the network. is possible that the STUN message might be dropped by the network.
Reliability of STUN request/response transactions is accomplished Reliability of STUN request/response transactions is accomplished
through retransmissions of the request message by the client through retransmissions of the request message by the client
application itself. STUN indications are not retransmitted; thus, application itself. STUN indications are not retransmitted; thus,
indication transactions over UDP or DTLS-over-UDP are not reliable. indication transactions over UDP or DTLS-over-UDP are not reliable.
skipping to change at page 29, line 5 skipping to change at page 29, line 19
9.2.3. Receiving a Request 9.2.3. Receiving a Request
After the server has done the basic processing of a request, it After the server has done the basic processing of a request, it
performs the checks listed below in the order specified: performs the checks listed below in the order specified:
o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE- o If the message does not contain a MESSAGE-INTEGRITY or MESSAGE-
INTEGRITY2 attribute, the server MUST generate an error response INTEGRITY2 attribute, the server MUST generate an error response
with an error code of 401 (Unauthorized). This response MUST with an error code of 401 (Unauthorized). This response MUST
include a REALM value. It is RECOMMENDED that the REALM value be include a REALM value. It is RECOMMENDED that the REALM value be
the domain name of the provider of the STUN server. The response the domain name of the provider of the STUN server. The response
MUST include a NONCE, selected by the server. The server MAY MUST include a NONCE, selected by the server. The server MUST
ensure that the same NONCE cannot be selected for clients that use
different IP addresses and/or different ports. The server MAY
support alternate password algorithms, in which case it can list support alternate password algorithms, in which case it can list
them in preferential order in a PASSWORD-ALGORITHMS attribute. If them in preferential order in a PASSWORD-ALGORITHMS attribute. If
the server adds a PASSWORD-ALGORITHMS attribute it MUST prepend the server adds a PASSWORD-ALGORITHMS attribute it MUST prepend
the NONCE attribute value with the chracater string "obMatJos2". the NONCE attribute value with the character string "obMatJos2".
The response SHOULD NOT contain a USERNAME, MESSAGE-INTEGRITY or The response SHOULD NOT contain a USERNAME, MESSAGE-INTEGRITY or
MESSAGE-INTEGRITY2 attribute. MESSAGE-INTEGRITY2 attribute.
o If the message contains a MESSAGE-INTEGRITY or a MESSAGE- o If the message contains a MESSAGE-INTEGRITY or a MESSAGE-
INTEGRITY2 attribute, but is missing the USERNAME, REALM, or NONCE INTEGRITY2 attribute, but is missing the USERNAME, REALM, or NONCE
attribute, the server MUST generate an error response with an attribute, the server MUST generate an error response with an
error code of 400 (Bad Request). This response SHOULD NOT include error code of 400 (Bad Request). This response SHOULD NOT include
a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2 a USERNAME, NONCE, REALM, MESSAGE-INTEGRITY or MESSAGE-INTEGRITY2
attribute. attribute.
skipping to change at page 31, line 24 skipping to change at page 31, line 40
This section describes a mechanism in STUN that allows a server to This section describes a mechanism in STUN that allows a server to
redirect a client to another server. This extension is optional, and redirect a client to another server. This extension is optional, and
a usage must define if and when this extension is used. a usage must define if and when this extension is used.
A server using this extension redirects a client to another server by A server using this extension redirects a client to another server by
replying to a request message with an error response message with an replying to a request message with an error response message with an
error code of 300 (Try Alternate). The server MUST include an error code of 300 (Try Alternate). The server MUST include an
ALTERNATE-SERVER attribute in the error response. The error response ALTERNATE-SERVER attribute in the error response. The error response
message MAY be authenticated; however, there are uses cases for message MAY be authenticated; however, there are uses cases for
ALTERNATE-SERVER where authentication of the response is not possible ALTERNATE-SERVER where authentication of the response is not possible
or practical. or practical. If the transaction uses TLS or DTLS and if the
transaction is authenticated by a MESSAGE-INTEGRITY2 attribute and if
the server wants to redirect to a server that uses a different
certificate, then it MUST include an ALTERNATE-DOMAIN attribute
containing the subjectAltName of that certificate.
A client using this extension handles a 300 (Try Alternate) error A client using this extension handles a 300 (Try Alternate) error
code as follows. The client looks for an ALTERNATE-SERVER attribute code as follows. The client looks for an ALTERNATE-SERVER attribute
in the error response. If one is found, then the client considers in the error response. If one is found, then the client considers
the current transaction as failed, and reattempts the request with the current transaction as failed, and reattempts the request with
the server specified in the attribute, using the same transport the server specified in the attribute, using the same transport
protocol used for the previous request. That request, if protocol used for the previous request. That request, if
authenticated, MUST utilize the same credentials that the client authenticated, MUST utilize the same credentials that the client
would have used in the request to the server that performed the would have used in the request to the server that performed the
redirection. If the client has been redirected to a server on which redirection. If the transport protocol uses TLS or DTLS, then the
it has already tried this request within the last five minutes, it client looks for an ALTERNATE-DOMAIN attribute. If the attribute is
MUST ignore the redirection and consider the transaction to have found, the domain MUST be used to validate the cartificate. If the
failed. This prevents infinite ping-ponging between servers in case attribute is not found, the same domain that was used for the
of redirection loops. original request MUST be used to validate the certificate. If the
client has been redirected to a server on which it has already tried
this request within the last five minutes, it MUST ignore the
redirection and consider the transaction to have failed. This
prevents infinite ping-ponging between servers in case of redirection
loops.
11. Backwards Compatibility with RFC 3489 11. Backwards Compatibility with RFC 5389
In addition to the backward compatibility already described in In addition to the backward compatibility already described in
Section 12 of [RFC5389], DTLS MUST NOT be used with RFC 3489 STUN Section 12 of [RFC5389], DTLS MUST NOT be used with RFC 3489 STUN
[RFC3489] (also referred to as "classic STUN"). Any STUN request or [RFC3489] (also referred to as "classic STUN"). Any STUN request or
indication without the magic cookie (see Section 6 of [RFC5389]) over indication without the magic cookie (see Section 6 of [RFC5389]) over
DTLS MUST always result in an error. DTLS MUST always result in an error.
12. Basic Server Behavior 12. Basic Server Behavior
This section defines the behavior of a basic, stand-alone STUN This section defines the behavior of a basic, stand-alone STUN
skipping to change at page 35, line 25 skipping to change at page 35, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address (32 bits or 128 bits) | | Address (32 bits or 128 bits) |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Format of MAPPED-ADDRESS Attribute Figure 5: Format of MAPPED-ADDRESS Attribute
The address family can take on the following values: The address family can take on the following values:
0x01:IPv4 0x01:IPv4
0x02:IPv6 0x02:IPv6
The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be The first 8 bits of the MAPPED-ADDRESS MUST be set to 0 and MUST be
ignored by receivers. These bits are present for aligning parameters ignored by receivers. These bits are present for aligning parameters
on natural 32-bit boundaries. on natural 32-bit boundaries.
This attribute is used only by servers for achieving backwards This attribute is used only by servers for achieving backwards
compatibility with RFC 3489 [RFC3489] clients. compatibility with RFC 3489 [RFC3489] clients.
14.2. XOR-MAPPED-ADDRESS 14.2. XOR-MAPPED-ADDRESS
skipping to change at page 42, line 47 skipping to change at page 43, line 16
14.14. ALTERNATE-SERVER 14.14. ALTERNATE-SERVER
The alternate server represents an alternate transport address The alternate server represents an alternate transport address
identifying a different STUN server that the STUN client should try. identifying a different STUN server that the STUN client should try.
It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a It is encoded in the same way as MAPPED-ADDRESS, and thus refers to a
single server by IP address. The IP address family MUST be identical single server by IP address. The IP address family MUST be identical
to that of the source IP address of the request. to that of the source IP address of the request.
14.15. ALTERNATE-DOMAIN
The alternate domain represents the domain name that is used to
verify the IP address in the ALTERNATE-SERVER attribute when the
transport protocol uses TLS or DTLS.
The value of ALTERNATE-DOMAIN is variable length. It MUST be a UTF-8
[RFC3629] encoded sequence of less than 128 characters (which can be
as long as 763 bytes).
15. Security Considerations 15. Security Considerations
15.1. Attacks against the Protocol 15.1. Attacks against the Protocol
15.1.1. Outside Attacks 15.1.1. Outside Attacks
An attacker can try to modify STUN messages in transit, in order to An attacker can try to modify STUN messages in transit, in order to
cause a failure in STUN operation. These attacks are detected for cause a failure in STUN operation. These attacks are detected for
both requests and responses through the message-integrity mechanism, both requests and responses through the message-integrity mechanism,
using either a short-term or long-term credential. Of course, once using either a short-term or long-term credential. Of course, once
detected, the manipulated packets will be dropped, causing the STUN detected, the manipulated packets will be dropped, causing the STUN
transaction to effectively fail. This attack is possible only by an transaction to effectively fail. This attack is possible only by an
skipping to change at page 48, line 4 skipping to change at page 48, line 30
0x0014: REALM 0x0014: REALM
0x0015: NONCE 0x0015: NONCE
0x0020: XOR-MAPPED-ADDRESS 0x0020: XOR-MAPPED-ADDRESS
0xXXXX: PASSWORD-ALGORITHM 0xXXXX: PASSWORD-ALGORITHM
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8022: SOFTWARE 0x8022: SOFTWARE
0x8023: ALTERNATE-SERVER 0x8023: ALTERNATE-SERVER
0x8028: FINGERPRINT 0x8028: FINGERPRINT
0xXXXX: PASSSORD-ALGORITHMS 0xXXXX: PASSSORD-ALGORITHMS
0xXXXX: ALTERNATE-DOMAIN
STUN Attribute types in the first half of the comprehension-required STUN Attribute types in the first half of the comprehension-required
range (0x0000 - 0x3FFF) and in the first half of the comprehension- range (0x0000 - 0x3FFF) and in the first half of the comprehension-
optional range (0x8000 - 0xBFFF) are assigned by IETF Review optional range (0x8000 - 0xBFFF) are assigned by IETF Review
[RFC5226]. STUN Attribute types in the second half of the [RFC5226]. STUN Attribute types in the second half of the
comprehension-required range (0x4000 - 0x7FFF) and in the second half comprehension-required range (0x4000 - 0x7FFF) and in the second half
of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by of the comprehension-optional range (0xC000 - 0xFFFF) are assigned by
Designated Expert [RFC5226]. The responsibility of the expert is to Designated Expert [RFC5226]. The responsibility of the expert is to
verify that the selected codepoint(s) are not in use, and that the verify that the selected codepoint(s) are not in use, and that the
request is not for an abnormally large number of codepoints. request is not for an abnormally large number of codepoints.
Technical review of the extension itself is outside the scope of the Technical review of the extension itself is outside the scope of the
skipping to change at page 49, line 35 skipping to change at page 50, line 12
service, defined over TCP and UDP. The UDP port is not currently service, defined over TCP and UDP. The UDP port is not currently
defined; however, it is reserved for future use. defined; however, it is reserved for future use.
18. Changes since RFC 5389 18. Changes since RFC 5389
This specification obsoletes RFC 5389 [RFC5389]. This specification This specification obsoletes RFC 5389 [RFC5389]. This specification
differs from RFC 5389 in the following ways: differs from RFC 5389 in the following ways:
o o
19. Contributors 19. References
Christian Huitema and Joel Weinberger were original co-authors of RFC
3489.
20. Acknowledgements
The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work.
21. References
21.1. Normative References 19.1. Normative References
[I-D.ietf-tsvwg-sctp-dtls-encaps] [I-D.ietf-tsvwg-sctp-dtls-encaps]
Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS Jesup, R., Loreto, S., Stewart, R., and M. Tuexen, "DTLS
Encapsulation of SCTP Packets for RTCWEB", draft-ietf- Encapsulation of SCTP Packets for RTCWEB", draft-ietf-
tsvwg-sctp-dtls-encaps-00 (work in progress), February tsvwg-sctp-dtls-encaps-00 (work in progress), February
2013. 2013.
[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
skipping to change at page 52, line 5 skipping to change at page 52, line 9
to End-Host Communication", RFC 6951, May 2013. to End-Host Communication", RFC 6951, May 2013.
[RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit- [RFC7064] Nandakumar, S., Salgueiro, G., Jones, P., and M. Petit-
Huguenin, "URI Scheme for the Session Traversal Utilities Huguenin, "URI Scheme for the Session Traversal Utilities
for NAT (STUN) Protocol", RFC 7064, November 2013. for NAT (STUN) Protocol", RFC 7064, November 2013.
[RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport [RFC7350] Petit-Huguenin, M. and G. Salgueiro, "Datagram Transport
Layer Security (DTLS) as Transport for Session Traversal Layer Security (DTLS) as Transport for Session Traversal
Utilities for NAT (STUN)", RFC 7350, August 2014. Utilities for NAT (STUN)", RFC 7350, August 2014.
21.2. Informational References 19.2. Informational References
[I-D.ietf-tram-stun-origin]
Johnston, A., Uberti, J., Yoakum, J., and K. Singh, "An
Origin Attribute for the STUN Protocol", draft-ietf-tram-
stun-origin-05 (work in progress), February 2015.
[I-D.ietf-uta-tls-bcp]
Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-11 (work in progress), February 2015.
[I-D.veltri-sip-alt-auth] [I-D.veltri-sip-alt-auth]
Veltri, L., Salsano, S., and A. Polidoro, "HTTP digest Veltri, L., Salsano, S., and A. Polidoro, "HTTP digest
authentication using alternate password storage schemes", authentication using alternate password storage schemes",
draft-veltri-sip-alt-auth-00 (work in progress), April draft-veltri-sip-alt-auth-00 (work in progress), April
2008. 2008.
[KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time [KARN87] Karn, P. and C. Partridge, "Improving Round-Trip Time
Estimates in Reliable Transport Protocols", SIGCOMM 1987, Estimates in Reliable Transport Protocols", SIGCOMM 1987,
August 1987. August 1987.
skipping to change at page 54, line 11 skipping to change at page 54, line 24
int cls(int type) { int cls(int type) {
return (type & 0x0100) >> 7 | (type & 0x0010) >> 4; return (type & 0x0100) >> 7 | (type & 0x0010) >> 4;
} }
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. Open Issues B.1. Open Issues
1. Clean the IANA section. 1. Integrate RFC 5769 (stun vectors) as examples
2. Fix bug on retransmission RTO in section 7.2. B.2. Modifications between draft-ietf-tram-stunbis-02 and draft-ietf-
tram-stunbis-01
3. Integrate RFC 5769 (stun vectors) as examples o Prevent the server to allocate the same NONCE to clients with
different IP address and/or different port. This prevent sharing
the nonce between TURN allocations in TURN.
4. Clarify whether it's valid to share nonces across TURN o Add reference to draft-ietf-uta-tls-bcp
allocations.
5. Clarify nonce behavior for both invalid and expired nonces. o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of
Right now only expired nonces are described. Define a new the ALTERNATE-SERVER after a 300 over (D)TLS.
"invalid nonce" error code (presumably 438)
6. This question was raised: If a STUN (TURN) client receives a "300 o The RTP delay between transactions applies only to parallel
Try Alternate" response to a STUN request sent over TLS, it transactions, not to serial transactions. That prevents a 3RTT
should then connect to a different STUN server over TLS. What delay between the first transaction and the second transaction
subjectAltName should it expect in the redirected-to server's with long term authentication.
certificate?
7. Normatively reference the new ORIGIN RFC o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport.
B.2. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf- o Add a new attribute ALTERNATE-DOMAIN to verify the certificate of
the ALTERNATE-SERVER after a 300 over (D)TLS.
o The RTP delay between transactions applies only to parallel
transactions, not to serial transactions. That prevents a 3RTT
delay between the first transaction and the second transaction
with long term authentication.
o Add text saying ORIGIN can increase a request size beyond the MTU
and so require an SCTPoUDP transport.
o Move the Acknowledgments and Contributor sections to the end of
the document, in accordance with RFC 7322 section 4.
B.3. Modifications between draft-ietf-tram-stunbis-01 and draft-ietf-
tram-stunbis-00 tram-stunbis-00
o Add negotiation mechanism for new password algorithms. o Add negotiation mechanism for new password algorithms.
o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol. o Describe the MESSAGE-INTEGRITY/MESSAGE-INTEGRITY2 protocol.
o Add support for SCTP to solve the fragmentation problem. o Add support for SCTP to solve the fragmentation problem.
o Merge RFC 7350: o Merge RFC 7350:
skipping to change at page 55, line 18 skipping to change at page 55, line 46
* DNS discovery is done from the URI. * DNS discovery is done from the URI.
* Reorganized the text about default ports. * Reorganized the text about default ports.
o Add more C snippets. o Add more C snippets.
o Make clear that the cached RTO is discarded only if there is no o Make clear that the cached RTO is discarded only if there is no
new transations for 10 minutes. new transations for 10 minutes.
B.3. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.4. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
ietf-tram-stunbis-00 ietf-tram-stunbis-00
o Draft adopted as WG item. o Draft adopted as WG item.
B.4. Modifications between draft-salgueiro-tram-stunbis-02 and draft- B.5. Modifications between draft-salgueiro-tram-stunbis-02 and draft-
salgueiro-tram-stunbis-01 salgueiro-tram-stunbis-01
o Add definition of MESSAGE-INTEGRITY2. o Add definition of MESSAGE-INTEGRITY2.
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
skipping to change at page 56, line 5 skipping to change at page 56, line 34
o Update text and reference from RFC 2988 to RFC 6298. o Update text and reference from RFC 2988 to RFC 6298.
o s/The IAB has mandated/The IAB has suggested/ (Errata #3737). o s/The IAB has mandated/The IAB has suggested/ (Errata #3737).
o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972). o Fix the figure for the UNKNOWN-ATTRIBUTES (Errata #2972).
o Fix section number and make clear that the original domain name is o Fix section number and make clear that the original domain name is
used for the server certificate verification. This is consistent used for the server certificate verification. This is consistent
with what RFC 5922 (section 4) is doing. (Errata #2010) with what RFC 5922 (section 4) is doing. (Errata #2010)
B.5. Modifications between draft-salgueiro-tram-stunbis-01 and draft- B.6. Modifications between draft-salgueiro-tram-stunbis-01 and draft-
salgueiro-tram-stunbis-00 salgueiro-tram-stunbis-00
o Restore the RFC 5389 text. o Restore the RFC 5389 text.
o Add list of open issues. o Add list of open issues.
Acknowledgements
Thanks to Michael Tuexen, Tirumaleswar Reddy, Oleg Moskalenko, Simon
Perreault, and Benjamin Schwartz for the comments, suggestions, and
questions that helped improve this document.
The authors of RFC 5389 would like to thank Cedric Aoun, Pete
Cordell, Cullen Jennings, Bob Penfield, Xavier Marjou, Magnus
Westerlund, Miguel Garcia, Bruce Lowekamp, and Chris Sullivan for
their comments, and Baruch Sterman and Alan Hawrylyshen for initial
implementations. Thanks for Leslie Daigle, Allison Mankin, Eric
Rescorla, and Henning Schulzrinne for IESG and IAB input on this
work.
Contributors
Christian Huitema and Joel Weinberger were original co-authors of RFC
3489.
Authors' Addresses Authors' Addresses
Marc Petit-Huguenin Marc Petit-Huguenin
Impedance Mismatch Impedance Mismatch
Email: marc@petit-huguenin.org Email: marc@petit-huguenin.org
Gonzalo Salgueiro Gonzalo Salgueiro
Cisco Cisco
7200-12 Kit Creek Road 7200-12 Kit Creek Road
 End of changes. 55 change blocks. 
95 lines changed or deleted 167 lines changed or added

This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/