draft-ietf-behave-rfc3489bis-07.txt   draft-ietf-behave-rfc3489bis-08.txt 
BEHAVE Working Group J. Rosenberg BEHAVE Working Group J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3489 (if approved) C. Huitema Obsoletes: 3489 (if approved) C. Huitema
Intended status: Standards Track Microsoft Intended status: Standards Track Microsoft
Expires: January 9, 2008 R. Mahy Expires: January 28, 2008 R. Mahy
Plantronics Plantronics
P. Matthews P. Matthews
Avaya Avaya
D. Wing D. Wing
Cisco Cisco
July 8, 2007 July 27, 2007
Session Traversal Utilities for (NAT) (STUN) Session Traversal Utilities for (NAT) (STUN)
draft-ietf-behave-rfc3489bis-07 draft-ietf-behave-rfc3489bis-08
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008. This Internet-Draft will expire on January 28, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
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 NAT traversal. It can as a tool for other protocols in dealing with NAT traversal. It can
be used by an endpoint to determine the IP address and port allocated be used by an endpoint to determine the IP address and port allocated
skipping to change at page 2, line 24 skipping to change at page 2, line 24
3489), which presented STUN as a complete solution. 3489), which presented STUN as a complete solution.
This document obsoletes RFC 3489. This document obsoletes RFC 3489.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Evolution from RFC 3489 . . . . . . . . . . . . . . . . . . . 4 2. Evolution from RFC 3489 . . . . . . . . . . . . . . . . . . . 4
3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 8
6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 10 6. STUN Message Structure . . . . . . . . . . . . . . . . . . . . 9
7. Base Protocol Procedures . . . . . . . . . . . . . . . . . . . 12 7. Base Protocol Procedures . . . . . . . . . . . . . . . . . . . 12
7.1. Forming a Request or an Indication . . . . . . . . . . . 12 7.1. Forming a Request or an Indication . . . . . . . . . . . 12
7.2. Sending the Request or Indication . . . . . . . . . . . . 13 7.2. Sending the Request or Indication . . . . . . . . . . . . 12
7.2.1. Sending over UDP . . . . . . . . . . . . . . . . . . . 13 7.2.1. Sending over UDP . . . . . . . . . . . . . . . . . . . 12
7.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . . 14 7.2.2. Sending over TCP or TLS-over-TCP . . . . . . . . . . . 13
7.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 15 7.3. Receiving a STUN Message . . . . . . . . . . . . . . . . 15
7.3.1. Processing a Request . . . . . . . . . . . . . . . . . 16 7.3.1. Processing a Request . . . . . . . . . . . . . . . . . 16
7.3.1.1. Forming a Success or Error Response . . . . . . . 17 7.3.1.1. Forming a Success or Error Response . . . . . . . 16
7.3.1.2. Sending the Success or Error Response . . . . . . 17 7.3.1.2. Sending the Success or Error Response . . . . . . 17
7.3.2. Processing an Indication . . . . . . . . . . . . . . . 18 7.3.2. Processing an Indication . . . . . . . . . . . . . . . 17
7.3.3. Processing a Success Response . . . . . . . . . . . . 18 7.3.3. Processing a Success Response . . . . . . . . . . . . 17
7.3.4. Processing an Error Response . . . . . . . . . . . . . 18 7.3.4. Processing an Error Response . . . . . . . . . . . . . 18
8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 19 8. FINGERPRINT Mechanism . . . . . . . . . . . . . . . . . . . . 18
9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 19 9. DNS Discovery of a Server . . . . . . . . . . . . . . . . . . 19
10. Authentication and Message-Integrity Mechanisms . . . . . . . 20 10. Authentication and Message-Integrity Mechanisms . . . . . . . 20
10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 21 10.1. Short-Term Credential Mechanism . . . . . . . . . . . . . 20
10.1.1. Forming a Request or Indication . . . . . . . . . . . 21 10.1.1. Forming a Request or Indication . . . . . . . . . . . 21
10.1.2. Receiving a Request or Indication . . . . . . . . . . 21 10.1.2. Receiving a Request or Indication . . . . . . . . . . 21
10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 22 10.1.3. Receiving a Response . . . . . . . . . . . . . . . . . 22
10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 23 10.2. Long-term Credential Mechanism . . . . . . . . . . . . . 22
10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 24 10.2.1. Forming a Request . . . . . . . . . . . . . . . . . . 23
10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 24 10.2.1.1. First Request . . . . . . . . . . . . . . . . . . 24
10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 24 10.2.1.2. Subsequent Requests . . . . . . . . . . . . . . . 24
10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 24 10.2.2. Receiving a Request . . . . . . . . . . . . . . . . . 24
10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 25 10.2.3. Receiving a Response . . . . . . . . . . . . . . . . . 25
11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 26 11. ALTERNATE-SERVER Mechanism . . . . . . . . . . . . . . . . . . 25
12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 26 12. Backwards Compatibility with RFC 3489 . . . . . . . . . . . . 26
12.1. Changes to Client Processing . . . . . . . . . . . . . . 27 12.1. Changes to Client Processing . . . . . . . . . . . . . . 27
12.2. Changes to Server Processing . . . . . . . . . . . . . . 27 12.2. Changes to Server Processing . . . . . . . . . . . . . . 27
13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 28 13. STUN Usages . . . . . . . . . . . . . . . . . . . . . . . . . 27
14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 29 14. STUN Attributes . . . . . . . . . . . . . . . . . . . . . . . 28
14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 30 14.1. MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . . . 29
14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 31 14.2. XOR-MAPPED-ADDRESS . . . . . . . . . . . . . . . . . . . 30
14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 32 14.3. USERNAME . . . . . . . . . . . . . . . . . . . . . . . . 31
14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 32 14.4. MESSAGE-INTEGRITY . . . . . . . . . . . . . . . . . . . . 31
14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 33 14.5. FINGERPRINT . . . . . . . . . . . . . . . . . . . . . . . 32
14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 33 14.6. ERROR-CODE . . . . . . . . . . . . . . . . . . . . . . . 32
14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 34 14.7. REALM . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.8. NONCE . . . . . . . . . . . . . . . . . . . . . . . . . . 34
14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 35 14.9. UNKNOWN-ATTRIBUTES . . . . . . . . . . . . . . . . . . . 34
14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.10. SERVER . . . . . . . . . . . . . . . . . . . . . . . . . 35
14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 36 14.11. ALTERNATE-SERVER . . . . . . . . . . . . . . . . . . . . 35
15. Security Considerations . . . . . . . . . . . . . . . . . . . 36 15. Security Considerations . . . . . . . . . . . . . . . . . . . 35
15.1. Attacks against the Protocol . . . . . . . . . . . . . . 36 15.1. Attacks against the Protocol . . . . . . . . . . . . . . 35
15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 36 15.1.1. Outside Attacks . . . . . . . . . . . . . . . . . . . 36
15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 36 15.1.2. Inside Attacks . . . . . . . . . . . . . . . . . . . . 36
15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 36 15.2. Attacks Affecting the Usage . . . . . . . . . . . . . . . 36
15.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 37 15.2.1. Attack I: DDoS Against a Target . . . . . . . . . . . 37
15.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 37 15.2.2. Attack II: Silencing a Client . . . . . . . . . . . . 37
15.2.3. Attack III: Assuming the Identity of a Client . . . . 37 15.2.3. Attack III: Assuming the Identity of a Client . . . . 37
15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 38 15.2.4. Attack IV: Eavesdropping . . . . . . . . . . . . . . . 37
15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 38 15.3. Hash Agility Plan . . . . . . . . . . . . . . . . . . . . 38
16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 38 16. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 38
17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39 17.1. STUN Methods Registry . . . . . . . . . . . . . . . . . . 39
17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 39 17.2. STUN Attribute Registry . . . . . . . . . . . . . . . . . 39
17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 40 17.3. STUN Error Code Registry . . . . . . . . . . . . . . . . 40
18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 40 18. Changes Since RFC 3489 . . . . . . . . . . . . . . . . . . . . 40
19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 19. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 20. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
20.1. Normative References . . . . . . . . . . . . . . . . . . 42 20.1. Normative References . . . . . . . . . . . . . . . . . . 42
20.2. Informational References . . . . . . . . . . . . . . . . 43 20.2. Informational References . . . . . . . . . . . . . . . . 42
Appendix A. C Snippet to Determine STUN Message Types . . . . . . 44 Appendix A. C Snippet to Determine STUN Message Types . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 46
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 toolkit of functions for dealing with Utilities for NAT, provides a tool for dealing with NATs. It
NATs. It provides a means for an endpoint to determine the IP provides a means for an endpoint to determine the IP address and port
address and port allocated by a NAT that corresponds to its private allocated by a NAT that corresponds to its private IP address and
IP address and port. It also provides a way for an endpoint to keep port. It also provides a way for an endpoint to keep a NAT binding
a NAT binding alive. With some extensions, the protocol can be used alive. With some extensions, the protocol can be used to do
to do connectivity checks between two endpoints connectivity checks between two endpoints [I-D.ietf-mmusic-ice], or
[I-D.ietf-mmusic-ice], or to relay packets between two endpoints to relay packets between two endpoints [I-D.ietf-behave-turn].
[I-D.ietf-behave-turn].
In keeping with its toolkit nature, this specification defines an In keeping with its tool nature, this specification defines an
extensible packet format, defines operation over several transport extensible packet format, defines operation over several transport
protocols, and provides for two forms of authentication. protocols, and provides for two forms of authentication.
STUN is intended to be used in context of one or more NAT traversal STUN is intended to be used in context of one or more NAT traversal
solutions. These solutions are known as STUN usages. Each usage solutions. These solutions are known as STUN usages. Each usage
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) [I-D.ietf-mmusic-ice] is one usage of ICE. SIP Establishment (ICE) [I-D.ietf-mmusic-ice] is one usage of ICE. SIP
skipping to change at page 5, line 9 skipping to change at page 5, line 8
discover whether it would, in fact, work or not, and it provided no discover whether it would, in fact, work or not, and it provided no
remedy in cases where it did not. Furthermore, classic STUN's remedy in cases where it did not. Furthermore, classic STUN's
algorithm for classification of NAT types was found to be faulty, as algorithm for classification of NAT types was found to be faulty, as
many NATs did not fit cleanly into the types defined there. Classic many NATs did not fit cleanly into the types defined there. Classic
STUN also had security vulnerabilities which required an extremely STUN also had security vulnerabilities which required an extremely
complicated mechanism to address, and despite the complexity of the complicated mechanism to address, and despite the complexity of the
mechanism, were not fully remedied. mechanism, were not fully remedied.
For these reasons, this specification obsoletes RFC 3489, and instead For these reasons, this specification obsoletes RFC 3489, and instead
describes STUN as a tool that is utilized as part of a complete NAT describes STUN as a tool that is utilized as part of a complete NAT
traversal solution. ICE is a complete NAT traversal solutions for traversal solution. ICE is a complete NAT traversal solution for
protocols based on the offer/answer [RFC3264] methodology, such as protocols based on the offer/answer [RFC3264] methodology, such as
SIP. SIP Outbound is a complete solution for traversal of SIP SIP. SIP Outbound is a complete solution for traversal of SIP
signaling, and it uses STUN in a very different way. Though it is signaling, and it uses STUN in a very different way. Though it is
possible that a protocol may be able to use STUN by itself (classic possible that a protocol may be able to use STUN by itself (classic
STUN) as a traversal solution, such usage is not described here and STUN) as a traversal solution, such usage is not described here and
is strongly discouraged for the reasons described above. is strongly discouraged for the reasons described above.
The on-the-wire protocol described here is changed only slightly from The on-the-wire protocol described here is changed only slightly from
classic STUN. The protocol now runs over TCP in addition to UDP. classic STUN. The protocol now runs over TCP in addition to UDP.
Extensibility was added to the protocol in a more structured way. A Extensibility was added to the protocol in a more structured way. A
skipping to change at page 7, line 5 skipping to change at page 7, line 5
randomly selected 96-bit number. For request/response transactions, randomly selected 96-bit number. For request/response transactions,
this transaction ID allows the client to associate the response with this transaction ID allows the client to associate the response with
the request that generated it; for indications, this simply serves as the request that generated it; for indications, this simply serves as
a debugging aid. a debugging aid.
All STUN messages start with a fixed header that includes a method, a All STUN messages start with a fixed header that includes a method, a
class, and the transaction ID. The method indicates which of the class, and the transaction ID. The method indicates which of the
various requests or indications this is; this specification defines various requests or indications this is; this specification defines
just one method, Binding, but other methods are expected to be just one method, Binding, but other methods are expected to be
defined in other documents. The class indicates whether this is a defined in other documents. The class indicates whether this is a
request, a (success) response, an error response, or an indication. request, a success response, an error response, or an indication.
Following the fixed header comes zero or more attributes, which are Following the fixed header comes zero or more attributes, which are
type-length-value extensions that convey additional information for type-length-value extensions that convey additional information for
the specific message. the specific message.
This document defines a single method called Binding. The Binding This document defines a single method called Binding. The Binding
method can be used either in request/response transactions or in method can be used either in request/response transactions or in
indication transactions. When used in request/response transactions, indication transactions. When used in request/response transactions,
the Binding method can be used to determine the particular "binding" the Binding method can be used to determine the particular "binding"
a NAT has allocated to a STUN client. When used in either request/ a NAT has allocated to a STUN client. When used in either request/
response or in indication transactions, the Binding method can also response or in indication transactions, the Binding method can also
skipping to change at page 7, line 31 skipping to change at page 7, line 31
NATs between the STUN client and the STUN server (in Figure 1, there NATs between the STUN client and the STUN server (in Figure 1, there
were two such NATs). As the Binding Request message passes through a were two such NATs). As the Binding Request message passes through a
NAT, the NAT will modify the source transport address (that is, the NAT, the NAT will modify the source transport address (that is, the
source IP address and the source port) of the packet. As a result, source IP address and the source port) of the packet. As a result,
the source transport address of the request received by the server the source transport address of the request received by the server
will be the public IP address and port created by the NAT closest to will be the public IP address and port created by the NAT closest to
the server. This is called a reflexive transport address. The STUN the server. This is called a reflexive transport address. The STUN
server copies that source transport address into an XOR-MAPPED- server copies that source transport address into an XOR-MAPPED-
ADDRESS attribute in the STUN Binding Response and sends the Binding ADDRESS attribute in the STUN Binding Response and sends the Binding
Response back to the the STUN client. As this packet passes back Response back to the the STUN client. As this packet passes back
through a NAT, the NAT will modify the destination transport address, through a NAT, the NAT will modify the destination transport address
but the transport address in the XOR-MAPPED-ADDRESS attribute within in the IP header, but the transport address in the XOR-MAPPED-ADDRESS
the body of the STUN response will remain untouched. In this way, attribute within the body of the STUN response will remain untouched.
the client can learn its reflexive transport address allocated by the In this way, the client can learn its reflexive transport address
outermost NAT with respect to the STUN server. allocated by the outermost NAT with respect to the STUN server.
In some usages, STUN must be multiplexed with other protocols (e.g., In some usages, STUN must be multiplexed with other protocols (e.g.,
[I-D.ietf-mmusic-ice], [I-D.ietf-sip-outbound]). In these usages, [I-D.ietf-mmusic-ice], [I-D.ietf-sip-outbound]). In these usages,
there must be a way to inspect a packet and determine if it is a STUN there must be a way to inspect a packet and determine if it is a STUN
packet or not. STUN provides two fields in the STUN header with packet or not. STUN provides three fields in the STUN header with
fixed values that can be used for this purpose. If this is not fixed values that can be used for this purpose. If this is not
sufficient, then STUN packets can also contain a FINGERPRINT value sufficient, then STUN packets can also contain a FINGERPRINT value
which can further be used to distinguish the packets. which can further be used to distinguish the packets.
STUN has optional mechanisms for providing authentication and message STUN defines a set of optional procedures that a usage can decide to
integrity when required. These mechanisms revolve around the use of use, called mechanisms. These mechanisms include DNS discovery, a
a username, password, and message-integrity value. Two of these redirection technique to an alternate server, a fingerprint attribute
for demultiplexing, and two authentication and message integrity
exchanges. The authentication mechanisms revolve around the use of a
username, password, and message-integrity value. Two authentication
mechanisms, the long-term credential mechanism and the short-term mechanisms, the long-term credential mechanism and the short-term
credential mechanism, are defined in this specification. Each usage credential mechanism, are defined in this specification. Each usage
specifies the mechanisms allowed with that usage. specifies the mechanisms allowed with that usage.
In the short-term credential mechanism, the client and the server
exchange a username and password through some out-of-band method
prior to the STUN exchange. For example, in the ICE usage
[I-D.ietf-mmusic-ice] the two endpoints use out-of-band signaling to
exchange a username and password. The client then includes the
username and a message-integrity value in the request message, where
the message-integrity value is computed as a cryptographic hash of
the message contents and the password. If the server replies with a
success response, then the response will include a message-integrity
value (computed using the same username and password), but the
username is not included. Error responses are not message-integrity
protected.
In the long-term credential mechanism, the client and server share a In the long-term credential mechanism, the client and server share a
pre-provisioned username and password and perform a digest challenge/ pre-provisioned username and password and perform a digest challenge/
response exchange inspired by (but differing in details) to the one response exchange inspired by (but differing in details) to the one
defined for HTTP [RFC2617]. Initially, the client sends a request defined for HTTP [RFC2617]. In the short-term credential mechanism,
message (e.g., a Binding Request) without any username or message- the client and the server exchange a username and password through
integrity value included. The server replies with an error response some out-of-band method prior to the STUN exchange. For example, in
indicating that the request must be authenticated. This error the ICE usage [I-D.ietf-mmusic-ice] the two endpoints use out-of-band
response includes a realm value and a nonce value. The client then signaling to exchange a username and password. These are used to
uses the realm value to help it select a username and password (for integrity protect and authenticate the request and response. There
example, the client might have a number of username and password is no challenge or nonce used.
combinations stored, each one keyed by a different realm value). The
client then retries the request, this time including the realm, the
username, the nonce, and a message-integrity value in the request,
where the message-integrity value is computed as a cryptographic hash
of the message contents and the password. The nonce is provided by
the server and merely echoed by the client into the request. It is
chosen by the server such that it encodes information about the
client, the time-of-day, or other parameters. In this way, if an
attacker should attempt to replay the request, the server would find
the nonce invalid, and then reject the request. If the server
replies with a success response, then the response will include a
message-integrity value (computed using the same username and
password), but realm, username, and nonce are not included. Error
responses are not message-integrity protected. If the client has
further requests to send, it can try to reuse the same username,
realm, and nonce values. If the server does not accept them, it will
reply with an error response giving a realm and nonce value again.
4. Terminology 4. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED", In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119
[RFC2119] and indicate requirement levels for compliant STUN [RFC2119] and indicate requirement levels for compliant STUN
implementations. implementations.
5. Definitions 5. Definitions
skipping to change at page 13, line 18 skipping to change at page 12, line 39
required unless the usage specifies otherwise. required unless the usage specifies otherwise.
7.2. Sending the Request or Indication 7.2. Sending the Request or Indication
The client then sends the request to the server. This document The client then sends the request to the server. This document
specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP; specifies how to send STUN messages over UDP, TCP, or TLS-over-TCP;
other transport protocols may be added in the future. The STUN usage other transport protocols may be added in the future. The STUN usage
must specify which transport protocol is used, and how the client must specify which transport protocol is used, and how the client
determines the IP address and port of the server. Section 9 determines the IP address and port of the server. Section 9
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 which a usage may elect to use. of a server which a usage may elect to use. STUN may be used with
anycast addresses, but only with UDP and in usages where
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). progress, with different transaction ids).
7.2.1. Sending over UDP 7.2.1. Sending over UDP
When running STUN over UDP it is possible that the STUN message might When running STUN over UDP it is possible that the STUN message might
be dropped by the network. Reliability of STUN request/response be dropped by the network. Reliability of STUN request/response
transactions is accomplished through retransmissions of the request transactions is accomplished through retransmissions of the request
message by the client application itself. STUN indications are not message by the client application itself. STUN indications are not
retransmitted; thus indication transactions over UDP are not retransmitted; thus indication transactions over UDP are not
reliable. reliable.
A client SHOULD retransmit a STUN request message starting with an A client SHOULD retransmit a STUN request message starting with an
interval of RTO ("Retransmission TimeOut"), doubling after each interval of RTO ("Retransmission TimeOut"), doubling after each
retransmission. The RTO is an estimate of the round-trip-time, and retransmission. The RTO is an estimate of the round-trip-time, and
is computed as described in RFC 2988 [RFC2988], with two exceptions. is computed as described in RFC 2988 [RFC2988], with two exceptions.
First, the initial value for RTO SHOULD be configurable (rather than First, the initial value for RTO SHOULD be configurable (rather than
the 3s recommended in RFC 2988). In fixed- line access links, a the 3s recommended in RFC 2988) and SHOULD be greater than 100ms. In
value of 100ms is RECOMMENDED. Secondly, the value of RTO MUST NOT fixed- line access links, a value of 100ms is RECOMMENDED. Secondly,
be rounded up to the nearest second. Rather, a 1ms accuracy MUST be the value of RTO MUST NOT be rounded up to the nearest second.
maintained. As with TCP, the usage of Karn's algorithm is Rather, a 1ms accuracy MUST be maintained. As with TCP, the usage of
RECOMMENDED. When applied to STUN, it means that RTT estimates Karn's algorithm is RECOMMENDED. When applied to STUN, it means that
SHOULD NOT be computed from STUN transactions which result in the RTT estimates SHOULD NOT be computed from STUN transactions which
retransmission of a request. result in the retransmission of a request.
The value for RTO SHOULD be cached by an client after the completion The value for RTO SHOULD be cached by an client after the completion
of the transaction, and used as the starting value for RTO for the of the transaction, and used as the starting value for RTO for the
next transaction to the same server (based on equality of IP next transaction to the same server (based on equality of IP
address). The value SHOULD be considered stale and discarded after address). The value SHOULD be considered stale and discarded after
10 minutes. 10 minutes.
Retransmissions continue until a response is received, or until a Retransmissions continue until a response is received, or until a
total of 7 requests have been sent. If, after the last request, a total of 7 requests have been sent. If, after the last request, a
duration equal to 16 times the RTO has passed without a response, the duration equal to 16 times the RTO has passed without a response, the
skipping to change at page 14, line 49 skipping to change at page 14, line 22
2818 [RFC2818]. Those procedures assume the client is dereferencing 2818 [RFC2818]. Those procedures assume the client is dereferencing
a URI. For purposes of usage with this specification, the client a URI. For purposes of usage with this specification, the client
treats the domain name or IP address used in Section 8.1 as the host treats the domain name or IP address used in Section 8.1 as the host
portion of the URI that has been dereferenced. If DNS was not used, portion of the URI that has been dereferenced. If DNS was not used,
the client MUST be configured with a set of authorized domains whose the client MUST be configured with a set of authorized domains whose
certificates will be accepted. certificates will be accepted.
Reliability of STUN over TCP and TLS-over-TCP is handled by TCP Reliability of STUN over TCP and TLS-over-TCP is handled by TCP
itself, and there are no retransmissions at the STUN protocol level. itself, and there are no retransmissions at the STUN protocol level.
However, for a request/response transaction, if the client has not However, for a request/response transaction, if the client has not
received a response after 7900ms, it considers the transaction to received a response 7900ms after it sent the SYN to establish the
have timed out. This value has been chosen to equalize the TCP and connection, it considers the transaction to have timed out. This
UDP timeouts for the default initial RTO. value has been chosen to equalize the TCP and UDP timeouts for the
default initial RTO.
In addition, if the client is unable to establish the TCP connection, In addition, if the client is unable to establish the TCP connection,
or the TCP connection is reset or fails before a response is or the TCP connection is reset or fails before a response is
received, any request/response transaction in progress is considered received, any request/response transaction in progress is considered
to have failed to have failed
The client MAY send multiple transactions over a single TCP (or TLS- The client MAY send multiple transactions over a single TCP (or TLS-
over-TCP) connection, and it MAY send another request before over-TCP) connection, and it MAY send another request before
receiving a response to the previous. The client SHOULD keep the receiving a response to the previous. The client SHOULD keep the
connection open until it connection open until it
skipping to change at page 16, line 33 skipping to change at page 16, line 9
the agent. Unknown comprehension-required attributes cause the agent. Unknown comprehension-required attributes cause
processing that depends on the message-class and is described below. processing that depends on the message-class and is described below.
At this point, further processing depends on the message class of the At this point, further processing depends on the message class of the
request. request.
7.3.1. Processing a Request 7.3.1. Processing a Request
If the request contains one or more unknown comprehension-required If the request contains one or more unknown comprehension-required
attributes, the server replies with an error response with an error attributes, the server replies with an error response with an error
code of 420 Unknown attributes, and includes an UNKNOWN-ATTRIBUTES code of 420 (Unknown Attribute), and includes an UNKNOWN-ATTRIBUTES
attribute in the response that lists the unknown comprehension- attribute in the response that lists the unknown comprehension-
required attributes. required attributes.
The server then does any additional checking that the method or the The server then does any additional checking that the method or the
specific usage requires. If all the checks succeed, the server specific usage requires. If all the checks succeed, the server
formulates a success response as described below. formulates a success response as described below.
If the request uses UDP transport and is a retransmission of a If the request uses UDP transport and is a retransmission of a
request for which the server has already generated a success response request for which the server has already generated a success response
within the last 10 seconds, the server MUST retransmit the same within the last 10 seconds, the server MUST retransmit the same
skipping to change at page 17, line 19 skipping to change at page 16, line 43
rules of section 6. The method of the response is the same as that rules of section 6. The method of the response is the same as that
of the request, and the message class is either "Success Response" or of the request, and the message class is either "Success Response" or
"Error Response". "Error Response".
For an error response, the server MUST add an ERROR-CODE attribute For an error response, the server MUST add an ERROR-CODE attribute
containing the error code specified in the processing above. The containing the error code specified in the processing above. The
reason phrase is not fixed, but SHOULD be something suitable for the reason phrase is not fixed, but SHOULD be something suitable for the
error code. For certain errors, additional attributes are added to error code. For certain errors, additional attributes are added to
the message. These attributes are spelled out in the description the message. These attributes are spelled out in the description
where the error code is specified. For example, for an error code of where the error code is specified. For example, for an error code of
420 Unknown Attribute, the server MUST include an UNKNOWN-ATTRIBUTES 420 (Unknown Attribute), the server MUST include an UNKNOWN-
attribute. Certain authentication errors also cause attributes to be ATTRIBUTES attribute. Certain authentication errors also cause
added (see Section 10). Extensions may define other errors and/or attributes to be added (see Section 10). Extensions may define other
additional attributes to add in error cases. errors and/or additional attributes to add in error cases.
If the server authenticated the request using an authentication If the server authenticated the request using an authentication
mechanism, then the server SHOULD add the appropriate authentication mechanism, then the server SHOULD add the appropriate authentication
attributes to the response (see Section 10). attributes to the response (see Section 10).
The server also adds any attributes required by the specific method The server also adds any attributes required by the specific method
or usage. In addition, the server SHOULD add a SERVER attribute to or usage. In addition, the server SHOULD add a SERVER attribute to
the message. the message.
For the Binding method, no additional checking is required unless the For the Binding method, no additional checking is required unless the
skipping to change at page 19, line 11 skipping to change at page 18, line 35
attempt. attempt.
The processing at this point depends on the error-code, the method, The processing at this point depends on the error-code, the method,
and the usage; the following are the default rules: and the usage; the following are the default rules:
o If the error code is 300 through 399, the client SHOULD consider o If the error code is 300 through 399, the client SHOULD consider
the transaction as failed unless the ALTERNATE-SERVER extension is the transaction as failed unless the ALTERNATE-SERVER extension is
being used. See Section 11. being used. See Section 11.
o If the error code is 400 through 499, the client declares the o If the error code is 400 through 499, the client declares the
transaction failed; in the case of 420, the response should transaction failed; in the case of 420 (Unknown Attribute), the
contain a UNKNOWN-ATTRIBUTES attribute that gives additional response should contain a UNKNOWN-ATTRIBUTES attribute that gives
information. additional information.
o If the error code is 500 through 599, the client MAY resend the o If the error code is 500 through 599, the client MAY resend the
request; clients that do so MUST limit the number of times they do request; clients that do so MUST limit the number of times they do
this. Any other error code causes the client to consider the this.
transaction failed.
Any other error code causes the client to consider the transaction
failed.
8. FINGERPRINT Mechanism 8. FINGERPRINT Mechanism
This section describes an optional mechanism for STUN that aids in This section describes an optional mechanism for STUN that aids in
distinguishing STUN messages from packets of other protocols when the distinguishing STUN messages from packets of other protocols when the
two are multiplexed on the same transport address. This mechanism is two are multiplexed on the same transport address. This mechanism is
optional, and a STUN usage must describe if and when it is used. optional, and a STUN usage must describe if and when it is used.
In some usages, STUN messages are multiplexed on the same transport In some usages, STUN messages are multiplexed on the same transport
address as other protocols, such as RTP. In order to apply the address as other protocols, such as RTP. In order to apply the
skipping to change at page 21, line 8 skipping to change at page 20, line 31
transaction, since the request or indication MUST NOT be sent unless transaction, since the request or indication MUST NOT be sent unless
SRV records provided a transport address specifically for TLS. SRV records provided a transport address specifically for TLS.
10. Authentication and Message-Integrity Mechanisms 10. Authentication and Message-Integrity Mechanisms
This section defines two mechanisms for STUN that a client and server This section defines two mechanisms for STUN that a client and server
can use to provide authentication and message-integrity; these two can use to provide authentication and message-integrity; these two
mechanisms are known as the short-term credential mechanism and the mechanisms are known as the short-term credential mechanism and the
long-term credential mechanism. These two mechanisms are optional, long-term credential mechanism. These two mechanisms are optional,
and each usage must specify if and when these mechanisms are used. and each usage must specify if and when these mechanisms are used.
An overview of these two mechanisms is given in . Consequently, both clients and servers will know which mechanism (if
any) to follow based on knowledge of which usage applies. For
example, a STUN server on the public Internet supporting ICE would
have no authentication, whereas the STUN server functionality in an
agent supporting connectivity checks would utilize short term
credentials. An overview of these two mechanisms is given in
Section 3.
Each mechanism specifies the additional processing required to use Each mechanism specifies the additional processing required to use
that mechanism, extending the processing specified in Section 7. The that mechanism, extending the processing specified in Section 7. The
additional processing occurs in three different places: when forming additional processing occurs in three different places: when forming
a message; when receiving a message immediately after the the basic a message; when receiving a message immediately after the the basic
checks have been performed; and when doing the detailed processing of checks have been performed; and when doing the detailed processing of
error responses. error responses.
10.1. Short-Term Credential Mechanism 10.1. Short-Term Credential Mechanism
skipping to change at page 21, line 51 skipping to change at page 21, line 33
10.1.2. Receiving a Request or Indication 10.1.2. Receiving a Request or Indication
After the agent has done the basic processing of a message, the agent After the agent has done the basic processing of a message, the agent
performs the checks listed below in order specified: performs the checks listed below in order specified:
o If the message does not contain both a MESSAGE-INTEGRITY and a o If the message does not contain both a MESSAGE-INTEGRITY and a
USERNAME attribute: USERNAME attribute:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 400. of 400 (Bad Request).
* If the message is an indication, the server MUST silently * If the message is an indication, the server MUST silently
discard the indication. discard the indication.
o If the USERNAME does not contain a username value currently valid o If the USERNAME does not contain a username value currently valid
within the server: within the server:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 401. of 401 (Unauthorized).
* If the message is an indication, the server MUST silently * If the message is an indication, the server MUST silently
discard the indication. discard the indication.
o Using the password associated with the username, compute the value o Using the password associated with the username, compute the value
for the message-integrity as described in Section 14.4. If the for the message-integrity as described in Section 14.4. If the
resulting value does not match the contents of the MESSAGE- resulting value does not match the contents of the MESSAGE-
INTEGRITY attribute: INTEGRITY attribute:
* If the message is a request, the server MUST reject the request * If the message is a request, the server MUST reject the request
with an error response. This response MUST use an error code with an error response. This response MUST use an error code
of 431. of 401 (Unauthorized).
* If the message is an indication, the server MUST silently * If the message is an indication, the server MUST silently
discard the indication. discard the indication.
If these checks pass, the server continues to process the request or If these checks pass, the server continues to process the request or
indication. Any response generated by the server MUST include the indication. Any response generated by the server MUST include the
MESSAGE-INTEGRITY attribute, computed using the username and password MESSAGE-INTEGRITY attribute, computed using the password utilized to
utilized to authenticate the request. authenticate the request. The response MUST NOT contain the USERNAME
attribute.
If any of the checks fail, the server MUST NOT include a MESSAGE- If any of the checks fail, the server MUST NOT include a MESSAGE-
INTEGRITY or USERNAME attribute in the error response. INTEGRITY or USERNAME attribute in the error response. This is
because, in these failure cases, the server cannot determine the
shared secret necessary to compute MESSAGE-INTEGRITY.
10.1.3. Receiving a Response 10.1.3. Receiving a Response
The processing here takes place prior to the processing in
Section 7.3.3 or Section 7.3.4.
The client looks for the MESSAGE-INTEGRITY attribute in the response. The client looks for the MESSAGE-INTEGRITY attribute in the response.
If present, the client computes the message integrity over the If present, the client computes the message integrity over the
response as defined in Section 14.4, using the same password it response as defined in Section 14.4, using the same password it
utilized for the request. If the resulting value matches the utilized for the request. If the resulting value matches the
contents of the MESSAGE-INTEGRITY attribute, the response is contents of the MESSAGE-INTEGRITY attribute, the response is
considered authenticated. If the value does not match, or if considered authenticated. If the value does not match, or if
MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if MESSAGE-INTEGRITY was absent, the response MUST be discarded, as if
it was never received. This means that retransmits, if applicable, it was never received. This means that retransmits, if applicable,
will continue. will continue.
skipping to change at page 24, line 52 skipping to change at page 24, line 37
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: o If the message:
* does not contain a MESSAGE-INTEGRITY attribute, * does not contain a MESSAGE-INTEGRITY attribute,
* OR, it contains a USERNAME whose value is not a valid username, * OR, it contains a USERNAME whose value is not a valid username,
the server MUST generate an error response with an error code of the server MUST generate an error response with an error code of
401. This response MUST include a REALM value. It is RECOMENDED 401 (Unauthorized). This response MUST include a REALM value. It
that the REALM value by the domain name of the provider of the is RECOMMENDED that the REALM value be the domain name of the
STUN server. The response MUST include a NONCE, selected by the provider of the STUN server. The response MUST include a NONCE,
server. selected by the server.
o If the message contains a MESSAGE-INTEGRITY attribute, but is o If the message contains a MESSAGE-INTEGRITY attribute, but is
missing the USERNAME, REALM or NONCE attributes, the server MUST missing the USERNAME, REALM or NONCE attributes, the server MUST
generate an error response with an error code of 400. generate an error response with an error code of 400 (Bad
Request).
o If the NONCE is no longer valid, the server MUST generate an error o If the NONCE is no longer valid, the server MUST generate an error
response with an error code of 438 (Stale Nonce). This response response with an error code of 438 (Stale Nonce). This response
MUST include a NONCE and REALM attribute. MUST include a NONCE and REALM attribute.
o Using the password associated with the username in the USERNAME o Using the password associated with the username in the USERNAME
attribute, compute the value for the message-integrity as attribute, compute the value for the message-integrity as
described in Section 14.4. If the resulting value does not match described in Section 14.4. If the resulting value does not match
the contents of the MESSAGE-INTEGRITY attribute, the server MUST the contents of the MESSAGE-INTEGRITY attribute, the server MUST
reject the request with an error response. This response MUST use reject the request with an error response. This response MUST use
an error code of 401. It MUST include a REALM and NONCE an error code of 401 (Unauthorized). It MUST include a REALM and
attribute. NONCE attribute.
If these checks pass, the server continues to process the request or If these checks pass, the server continues to process the request or
indication. Any response generated by the server MUST include the indication. Any response generated by the server MUST include the
MESSAGE-INTEGRITY attribute, computed using the username and password MESSAGE-INTEGRITY attribute, computed using the username and password
utilized to authenticate the request. The REALM, NONCE, and USERNAME utilized to authenticate the request. The REALM, NONCE, and USERNAME
attributes SHOULD NOT be included. attributes SHOULD NOT be included.
10.2.3. Receiving a Response 10.2.3. Receiving a Response
The processing here takes place prior to the processing in
Section 7.3.3 or Section 7.3.4.
If the response is an error response, with an error code of 401 If the response is an error response, with an error code of 401
(Unauthorized), the client SHOULD retry the request with a new (Unauthorized), the client SHOULD retry the request with a new
transaction. This request MUST contain a USERNAME, determined by the transaction. This request MUST contain a USERNAME, determined by the
client as the appropriate username for the REALM from the error client as the appropriate username for the REALM from the error
response. The request MUST contain the REALM, copied from the error response. The request MUST contain the REALM, copied from the error
response. The request MUST contain the NONCE, copied from the error response. The request MUST contain the NONCE, copied from the error
response. The request MUST contain the MESSAGE-INTEGRITY attribute, response. The request MUST contain the MESSAGE-INTEGRITY attribute,
computed using the password associated with the username in the computed using the password associated with the username in the
USERNAME attribute. The client MUST NOT perform this retry if it is USERNAME attribute. The client MUST NOT perform this retry if it is
not changing the USERNAME or REALM or its associated password, from not changing the USERNAME or REALM or its associated password, from
the previous attempt. the previous attempt.
If the response is an error response with an error code of 438, the If the response is an error response with an error code of 438 (Stale
client MUST retry the request, using the new NONCE supplied in the Nonce), the client MUST retry the request, using the new NONCE
438 response. This retry MUST also include the USERNAME, REALM and supplied in the 438 (Stale Nonce) response. This retry MUST also
MESSAGE-INTEGRITY. include the USERNAME, REALM and MESSAGE-INTEGRITY.
The client looks for the MESSAGE-INTEGRITY attribute in the response The client looks for the MESSAGE-INTEGRITY attribute in the response
(either success or failure). If present, the client computes the (either success or failure). If present, the client computes the
message integrity over the response as defined in Section 14.4, using message integrity over the response as defined in Section 14.4, using
the same password it utilized for the request. If the resulting the same password it utilized for the request. If the resulting
value matches the contents of the MESSAGE-INTEGRITY attribute, the value matches the contents of the MESSAGE-INTEGRITY attribute, the
response is considered authenticated. If the value does not match, response is considered authenticated. If the value does not match,
or if MESSAGE-INTEGRITY was absent, the response MUST be discarded, or if MESSAGE-INTEGRITY was absent, the response MUST be discarded,
as if it was never received. This means that retransmits, if as if it was never received. This means that retransmits, if
applicable, will continue. applicable, will continue.
skipping to change at page 27, line 13 skipping to change at page 26, line 43
because "classic STUN" was only used in a few specific ways. For the because "classic STUN" was only used in a few specific ways. For the
purposes of this extension, the important changes are the following. purposes of this extension, the important changes are the following.
In RFC 3489: In RFC 3489:
o UDP was the only supported transport; o UDP was the only supported transport;
o The field that is now the Magic Cookie field was a part of the o The field that is now the Magic Cookie field was a part of the
transaction id field, and transaction ids were 128 bits long; transaction id field, and transaction ids were 128 bits long;
o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding o The XOR-MAPPED-ADDRESS attribute did not exist, and the Binding
method used the MAPPED-ADDRESS attribute instead method used the MAPPED-ADDRESS attribute instead;
o There were two comprehension-required attributes, RESPONSE-ADDRESS o There were two comprehension-required attributes, RESPONSE-ADDRESS
and CHANGE-REQUEST, that have been removed from this and CHANGE-REQUEST, that have been removed from this
specification. specification;
* These attributes are now part of the NAT Behavior Discovery * These attributes are now part of the NAT Behavior Discovery
usage. usage.
12.1. Changes to Client Processing 12.1. Changes to Client Processing
A client that wants to interoperate with a [RFC3489] server SHOULD A client that wants to interoperate with a [RFC3489] server SHOULD
send a request message that uses the Binding method, contains no send a request message that uses the Binding method, contains no
attributes, and uses UDP as the transport protocol to the server. If attributes, and uses UDP as the transport protocol to the server. If
successful, the success response received from the server will successful, the success response received from the server will
skipping to change at page 28, line 8 skipping to change at page 27, line 35
The client might, in rare situations, include either the RESPONSE- The client might, in rare situations, include either the RESPONSE-
ADDRESS or CHANGE-REQUEST attributes. In these situations, the ADDRESS or CHANGE-REQUEST attributes. In these situations, the
server will view these as unknown comprehension-required attributes server will view these as unknown comprehension-required attributes
and reply with an error response. Since the mechanisms utilizing and reply with an error response. Since the mechanisms utilizing
those attributes are no longer supported, this behavior is those attributes are no longer supported, this behavior is
acceptable. acceptable.
13. STUN Usages 13. STUN Usages
STUN by itself is not a solution to the NAT traversal problem. STUN by itself is not a solution to the NAT traversal problem.
Rather, STUN defines a toolkit of functions that can be used inside a Rather, STUN defines a tool that can be used inside a larger
larger solution. The term "STUN Usage" is used for any solution that solution. The term "STUN Usage" is used for any solution that uses
uses STUN as a component. STUN as a component.
At the time of writing, three STUN usages are defined: Interactive At the time of writing, three STUN usages are defined: Interactive
Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Client- Connectivity Establishment (ICE) [I-D.ietf-mmusic-ice], Client-
initiated connections for SIP [I-D.ietf-sip-outbound], and NAT initiated connections for SIP [I-D.ietf-sip-outbound], and NAT
Behavior Discovery [I-D.ietf-behave-nat-behavior-discovery]. Other Behavior Discovery [I-D.ietf-behave-nat-behavior-discovery]. Other
STUN usages may be defined in the future. STUN usages may be defined in the future.
A STUN usage defines how STUN is actually utilized - when to send A STUN usage defines how STUN is actually utilized - when to send
requests, what to do with the responses, and which optional requests, what to do with the responses, and which optional
procedures defined here (or in an extension to STUN) are to be used. procedures defined here (or in an extension to STUN) are to be used.
skipping to change at page 32, line 24 skipping to change at page 31, line 38
behavior interferes with the operation of STUN and also causes behavior interferes with the operation of STUN and also causes
failure of STUN's message integrity checking. failure of STUN's message integrity checking.
14.3. USERNAME 14.3. USERNAME
The USERNAME attribute is used for message integrity. It identifies The USERNAME attribute is used for message integrity. It identifies
the username and password combination used in the message integrity the username and password combination used in the message integrity
check. check.
The value of USERNAME is a variable length value. It MUST contain a The value of USERNAME is a variable length value. It MUST contain a
UTF-8 encoded sequence of less than 128 characters. UTF-8 encoded sequence of less than 128 characters (which can be as
long as 763 bytes).
14.4. MESSAGE-INTEGRITY 14.4. MESSAGE-INTEGRITY
The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of The MESSAGE-INTEGRITY attribute contains an HMAC-SHA1 [RFC2104] of
the STUN message. The MESSAGE-INTEGRITY attribute can be present in the STUN message. The MESSAGE-INTEGRITY attribute can be present in
any STUN message type. Since it uses the SHA1 hash, the HMAC will be any STUN message type. Since it uses the SHA1 hash, the HMAC will be
20 bytes. The text used as input to HMAC is the STUN message, 20 bytes. The text used as input to HMAC is the STUN message,
including the header, up to and including the attribute preceding the including the header, up to and including the attribute preceding the
MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT MESSAGE-INTEGRITY attribute. With the exception of the FINGERPRINT
attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore attribute, which appears after MESSAGE-INTEGRITY, agents MUST ignore
all other attributes that follow MESSAGE-INTEGRITY. all other attributes that follow MESSAGE-INTEGRITY.
The key used as input to HMAC is the password. The key used as input to HMAC is the password.
Since the hash is computed over the entire STUN message, it includes Based on the rules above, the hash includes the length field from the
the length field from the STUN message header. This length indicates STUN message header. This length indicates the length of the entire
the length of the entire message, including the MESSAGE-INTEGRITY message, including the MESSAGE-INTEGRITY attribute itself.
attribute itself. Consequently, the MESSAGE-INTEGRITY attribute MUST Consequently, the MESSAGE-INTEGRITY attribute MUST be inserted into
be inserted into the message (with dummy content) prior to the the message (with dummy content) prior to the computation of the
computation of the integrity check. Once the computation is integrity check. Once the computation is performed, the value of the
performed, the value of the attribute can be filled in. This ensures attribute can be filled in. This ensures the length has the correct
the length has the correct value when the hash is performed. value when the hash is performed. Similarly, when validating the
Similarly, when validating the MESSAGE-INTEGRITY, the length field MESSAGE-INTEGRITY, the length field should be adjusted to point to
should be adjusted to point to the end of the MESSAGE-INTEGRITY the end of the MESSAGE-INTEGRITY attribute prior to calculating the
attribute prior to calculating the HMAC. Such adjustment is HMAC. Such adjustment is necessary when attributes, such as
necessary when attributes, such as FINTERPRINT, appear after MESSAGE- FINTERPRINT, appear after MESSAGE-INTEGRITY.
INTEGRITY.
14.5. FINGERPRINT 14.5. FINGERPRINT
The FINGERPRINT attribute may be present in all STUN messages. The The FINGERPRINT attribute may be present in all STUN messages. The
value of the attribute is computed as the CRC-32 of the STUN message value of the attribute is computed as the CRC-32 of the STUN message
up to (but excluding) the FINGERPRINT attribute itself, xor-d with up to (but excluding) the FINGERPRINT attribute itself, xor-d with
the 32 bit value 0x5354554e (the XOR helps in cases where an the 32 bit value 0x5354554e (the XOR helps in cases where an
application packet is also using CRC-32 in it). The 32 bit CRC is application packet is also using CRC-32 in it). The 32 bit CRC is
the one defined in ITU V.42 [ITU.V42.1994], which has a generator the one defined in ITU V.42 [ITU.V42.1994], which has a generator
polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1. polynomial of x32+x26+x23+x22+x16+x12+x11+x10+x8+x7+x5+x4+x2+x+1.
skipping to change at page 33, line 37 skipping to change at page 32, line 52
14.6. ERROR-CODE 14.6. ERROR-CODE
The ERROR-CODE attribute is used in Error Response messages. It The ERROR-CODE attribute is used in Error Response messages. It
contains a numeric error code value in the range of 300 to 699 plus a contains a numeric error code value in the range of 300 to 699 plus a
textual reason phrase encoded in UTF-8, and is consistent in its code textual reason phrase encoded in UTF-8, and is consistent in its code
assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The assignments and semantics with SIP [RFC3261] and HTTP [RFC2616]. The
reason phrase is meant for user consumption, and can be anything reason phrase is meant for user consumption, and can be anything
appropriate for the error code. Recommended reason phrases for the appropriate for the error code. Recommended reason phrases for the
defined error codes are presented below. The reason phrase MUST be a defined error codes are presented below. The reason phrase MUST be a
UTF-8 encoded sequence of less than 128 characters. UTF-8 encoded sequence of less than 128 characters (which can be as
long as 763 bytes).
To facilitate processing, the class of the error code (the hundreds To facilitate processing, the class of the error code (the hundreds
digit) is encoded separately from the rest of the code. digit) is encoded separately from the rest of the code.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved, should be 0 |Class| Number | | Reserved, should be 0 |Class| Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reason Phrase (variable) .. | Reason Phrase (variable) ..
skipping to change at page 34, line 14 skipping to change at page 33, line 30
and 6. The number represents the error code modulo 100, and its and 6. The number represents the error code modulo 100, and its
value MUST be between 0 and 99. value MUST be between 0 and 99.
The following error codes, along with their recommended reason The following error codes, along with their recommended reason
phrases (in brackets) are defined: phrases (in brackets) are defined:
300 Try Alternate: The client should contact an alternate server for 300 Try Alternate: The client should contact an alternate server for
this request. This error response MUST only be sent if the this request. This error response MUST only be sent if the
request included a USERNAME attribute and a valid MESSAGE- request included a USERNAME attribute and a valid MESSAGE-
INTEGRITY attribute; otherwise it MUST NOT be sent and error INTEGRITY attribute; otherwise it MUST NOT be sent and error
code 400 is suggested. This error response MUST be protected code 400 (Bad Request) is suggested. This error response MUST
with the MESSAGE-INTEGRITY attribute, and receivers MUST be protected with the MESSAGE-INTEGRITY attribute, and receivers
validate the MESSAGE-INTEGRITY of this response before MUST validate the MESSAGE-INTEGRITY of this response before
redirecting themselves to an alternate server. redirecting themselves to an alternate server.
Note: failure to generate and validate message-integrity Note: failure to generate and validate message-integrity
for a 300 response allows an on-path attacker to falsify a for a 300 response allows an on-path attacker to falsify a
300 response thus causing subsequent STUN messages to be 300 response thus causing subsequent STUN messages to be
sent to a victim. sent to a victim.
400 Bad Request: The request was malformed. The client SHOULD NOT 400 Bad Request: The request was malformed. The client SHOULD NOT
retry the request without modification from the previous retry the request without modification from the previous
attempt. The server may not be able to generate a valid attempt. The server may not be able to generate a valid
skipping to change at page 35, line 4 skipping to change at page 34, line 23
500 Server Error: The server has suffered a temporary error. The 500 Server Error: The server has suffered a temporary error. The
client should try again. client should try again.
14.7. REALM 14.7. REALM
The REALM attribute may be present in requests and responses. It The REALM attribute may be present in requests and responses. It
contains text which meets the grammar for "realm-value" as described contains text which meets the grammar for "realm-value" as described
in RFC 3261 [RFC3261] but without the double quotes and their in RFC 3261 [RFC3261] but without the double quotes and their
surrounding whitespace. That is, it is an unquoted realm-value. It surrounding whitespace. That is, it is an unquoted realm-value. It
MUST be a UTF-8 encoded sequence of less than 128 characters. MUST be a UTF-8 encoded sequence of less than 128 characters (which
can be as long as 763 bytes).
Presence of the REALM attribute in a request indicates that long-term Presence of the REALM attribute in a request indicates that long-term
credentials are being used for authentication. Presence in certain credentials are being used for authentication. Presence in certain
error responses indicates that the server wishes the client to use a error responses indicates that the server wishes the client to use a
long-term credential for authentication. long-term credential for authentication.
14.8. NONCE 14.8. NONCE
The NONCE attribute may be present in requests and responses. It The NONCE attribute may be present in requests and responses. It
contains a sequence of qdtext or quoted-pair, which are defined in contains a sequence of qdtext or quoted-pair, which are defined in
RFC 3261 [RFC3261]. See RFC 2617 [RFC2617], Section 4.3, for RFC 3261 [RFC3261]. See RFC 2617 [RFC2617], Section 4.3, for
guidance on selection of nonce values in a server. It MUST be less guidance on selection of nonce values in a server. It MUST be less
than 128 characters. than 128 characters (which can be as long as 763 bytes).
14.9. UNKNOWN-ATTRIBUTES 14.9. UNKNOWN-ATTRIBUTES
The UNKNOWN-ATTRIBUTES attribute is present only in an error response The UNKNOWN-ATTRIBUTES attribute is present only in an error response
when the response code in the ERROR-CODE attribute is 420. when the response code in the ERROR-CODE attribute is 420.
The attribute contains a list of 16 bit values, each of which The attribute contains a list of 16 bit values, each of which
represents an attribute type that was not understood by the server. represents an attribute type that was not understood by the server.
0 1 2 3 0 1 2 3
skipping to change at page 35, line 48 skipping to change at page 35, line 29
last attribute. In this version of the specification, the normal last attribute. In this version of the specification, the normal
padding rules for attributes are used instead. padding rules for attributes are used instead.
14.10. SERVER 14.10. SERVER
The server attribute contains a textual description of the software The server attribute contains a textual description of the software
being used by the server, including manufacturer and version number. being used by the server, including manufacturer and version number.
The attribute has no impact on operation of the protocol, and serves The attribute has no impact on operation of the protocol, and serves
only as a tool for diagnostic and debugging purposes. The value of only as a tool for diagnostic and debugging purposes. The value of
SERVER is variable length. It MUST be a UTF-8 encoded sequence of SERVER is variable length. It MUST be a UTF-8 encoded sequence of
less than 128 characters less than 128 characters (which can be as long as 763 bytes).
14.11. ALTERNATE-SERVER 14.11. ALTERNATE-SERVER
The alternate server represents an alternate transport address The alternate server represents an alternate transport address
identifying a different STUN server which the STUN client should try. identifying a different STUN server which 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.
skipping to change at page 36, line 25 skipping to change at page 36, line 8
MESSAGE-INTEGRITY attribute. This prevents it from being used in MESSAGE-INTEGRITY attribute. This prevents it from being used in
denial-of-service attacks. denial-of-service attacks.
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 prevented 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. using either a short term or long term credential. Of course, once
detected, the manipulated packets will be dropped, causing the STUN
transaction to effectively fail. This attack is possible only by an
on-path attacker.
An attacker that can observe, but not modify STUN messages in-transit An attacker that can observe, but not modify STUN messages in-transit
(for example, an attacker present on a shared access medium, such as (for example, an attacker present on a shared access medium, such as
Wi-Fi), can see a STUN request, and then immediately send a STUN Wi-Fi), can see a STUN request, and then immediately send a STUN
response, typically an error response, in order to disrupt STUN response, typically an error response, in order to disrupt STUN
processing. This attack is also prevented for messages that utilize processing. This attack is also prevented for messages that utilize
MESSAGE-INTEGRITY. However, some error responses, those related to MESSAGE-INTEGRITY. However, some error responses, those related to
authentication in particular, cannot be protected by MESSAGE- authentication in particular, cannot be protected by MESSAGE-
INTEGRITY. When STUN itself is run over a secure transport protocol INTEGRITY. When STUN itself is run over a secure transport protocol
(e.g., TLS), these attacks are completely mitigated. (e.g., TLS), these attacks are completely mitigated.
15.1.2. Inside Attacks 15.1.2. Inside Attacks
A rogue client may try to launch a DoS attack against a server by A rogue client may try to launch a DoS attack against a server by
sending it a large number of STUN requests. Fortunately, STUN sending it a large number of STUN requests. Fortunately, STUN
requests can be processed statelessly by a server, making such requests can be processed statelessly by a server, making such
attacks hard to launch. attacks hard to launch.
A rogue client may use a STUN server as a reflector, sending it
requests with a falsified source IP address and port. In such a
case, the response would be delivered to that source IP and port.
There is no amplification with this attack, and it is mitigated by
ingress source address filtering.
15.2. Attacks Affecting the Usage 15.2. Attacks Affecting the Usage
This section lists attacks that might be launched against a usage of This section lists attacks that might be launched against a usage of
STUN. Each STUN usage must consider whether these attacks are STUN. Each STUN usage must consider whether these attacks are
applicable to it, and if so, discuss counter-measures. applicable to it, and if so, discuss counter-measures.
Most of the attacks in this section revolve around an attacker Most of the attacks in this section revolve around an attacker
modifying the reflexive address learned by a STUN client through a modifying the reflexive address learned by a STUN client through a
Binding Request/Binding Response transaction. Since the usage of the Binding Request/Binding Response transaction. Since the usage of the
reflexive address is a function of the usage, the applicability and reflexive address is a function of the usage, the applicability and
skipping to change at page 37, line 51 skipping to change at page 37, line 41
receive any of the packets it expects to receive when it hands out receive any of the packets it expects to receive when it hands out
the reflexive address. This exploitation is not very interesting for the reflexive address. This exploitation is not very interesting for
the attacker. It impacts a single client, which is frequently not the attacker. It impacts a single client, which is frequently not
the desired target. Moreover, any attacker that can mount the attack the desired target. Moreover, any attacker that can mount the attack
could also deny service to the client by other means, such as could also deny service to the client by other means, such as
preventing the client from receiving any response from the STUN preventing the client from receiving any response from the STUN
server, or even a DHCP server. server, or even a DHCP server.
15.2.3. Attack III: Assuming the Identity of a Client 15.2.3. Attack III: Assuming the Identity of a Client
This attack is similar to attack III. However, the faked reflexive This attack is similar to attack II. However, the faked reflexive
address points to the attacker itself. This allows the attacker to address points to the attacker itself. This allows the attacker to
receive traffic which was destined for the client. receive traffic which was destined for the client.
15.2.4. Attack IV: Eavesdropping 15.2.4. Attack IV: Eavesdropping
In this attack, the attacker forces the client to use a reflexive In this attack, the attacker forces the client to use a reflexive
address that routes to itself. It then forwards any packets it address that routes to itself. It then forwards any packets it
receives to the client. This attack would allow the attacker to receives to the client. This attack would allow the attacker to
observe all packets sent to the client. However, in order to launch observe all packets sent to the client. However, in order to launch
the attack, the attacker must have already been able to observe the attack, the attacker must have already been able to observe
skipping to change at page 38, line 42 skipping to change at page 38, line 33
old message-integrity attribute will be deprecated by another old message-integrity attribute will be deprecated by another
specification, and clients will cease including it in requests. specification, and clients will cease including it in requests.
16. IAB Considerations 16. IAB Considerations
The IAB has studied the problem of "Unilateral Self Address Fixing" The IAB has studied the problem of "Unilateral Self Address Fixing"
(UNSAF), which is the general process by which a client attempts to (UNSAF), which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism (RFC3424 through a collaborative protocol reflection mechanism (RFC3424
[RFC3424]). STUN can be used to perform this function using a [RFC3424]). STUN can be used to perform this function using a
BindingRequest/BindingResponse transaction if one agent is behind a Binding Request/Response transaction if one agent is behind a NAT and
NAT and the other is on the public side of the NAT. the other is on the public side of the NAT.
The IAB has mandated that protocols developed for this purpose The IAB has mandated that protocols developed for this purpose
document a specific set of considerations. Because some STUN usages document a specific set of considerations. Because some STUN usages
provide UNSAF functions (such as ICE [I-D.ietf-mmusic-ice] ), and provide UNSAF functions (such as ICE [I-D.ietf-mmusic-ice] ), and
others do not (such as SIP Outbound [I-D.ietf-sip-outbound]), answers others do not (such as SIP Outbound [I-D.ietf-sip-outbound]), answers
to these considerations need to be addressed by the usages to these considerations need to be addressed by the usages
themselves. themselves.
17. IANA Considerations 17. IANA Considerations
skipping to change at page 41, line 7 skipping to change at page 40, line 31
[RFC2434]. The specification must carefully consider how clients [RFC2434]. The specification must carefully consider how clients
that do not understand this error code will process it before that do not understand this error code will process it before
granting the request. See the rules in Section 7.3.4. granting the request. See the rules in Section 7.3.4.
18. Changes Since RFC 3489 18. Changes Since RFC 3489
This specification obsoletes RFC3489 [RFC3489]. This specification This specification obsoletes RFC3489 [RFC3489]. This specification
differs from RFC3489 in the following ways: differs from RFC3489 in the following ways:
o Removed the notion that STUN is a complete NAT traversal solution. o Removed the notion that STUN is a complete NAT traversal solution.
STUN is now a toolkit that can be used to produce a NAT traversal STUN is now a tool that can be used to produce a NAT traversal
solution. As a consequence, changed the name of the protocol to solution. As a consequence, changed the name of the protocol to
Session Traversal Utilities for NAT. Session Traversal Utilities for NAT.
o Introduced the concept of STUN usages, and described what a usage o Introduced the concept of STUN usages, and described what a usage
of STUN must document. of STUN must document.
o Removed the usage of STUN for NAT type detection and binding o Removed the usage of STUN for NAT type detection and binding
lifetime discovery. These techniques have proven overly brittle lifetime discovery. These techniques have proven overly brittle
due to wider variations in the types of NAT devices than described due to wider variations in the types of NAT devices than described
in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS, in this document. Removed the RESPONSE-ADDRESS, CHANGED-ADDRESS,
 End of changes. 62 change blocks. 
167 lines changed or deleted 159 lines changed or added

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