Tech-invite3GPPspaceIETFspace
96959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5389

Session Traversal Utilities for NAT (STUN)

Pages: 51
Obsoletes:  3489
Obsoleted by:  8489
Updated by:  73508553
Part 1 of 3 – Pages 1 to 12
None   None   Next

Top   ToC   RFC5389 - Page 1
Network Working Group                                       J. Rosenberg
Request for Comments: 5389                                         Cisco
Obsoletes: 3489                                                  R. Mahy
Category: Standards Track                                    P. Matthews
                                                            Unaffiliated
                                                                 D. Wing
                                                                   Cisco
                                                            October 2008


               Session Traversal Utilities for NAT (STUN)

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

Session Traversal Utilities for NAT (STUN) is a protocol that serves as a tool for other protocols in dealing with Network Address 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 also be used to check connectivity between two endpoints, and as a keep-alive protocol to maintain NAT bindings. STUN works with many existing NATs, and does not require any special behavior from them. STUN is not a NAT traversal solution by itself. Rather, it is a tool to be used in the context of a NAT traversal solution. This is an important change from the previous version of this specification (RFC 3489), which presented STUN as a complete solution. This document obsoletes RFC 3489.

Table of Contents

1. Introduction ....................................................4 2. Evolution from RFC 3489 .........................................4 3. Overview of Operation ...........................................5 4. Terminology .....................................................8 5. Definitions .....................................................8 6. STUN Message Structure .........................................10 7. Base Protocol Procedures .......................................12 7.1. Forming a Request or an Indication ........................12 7.2. Sending the Request or Indication .........................13
Top   ToC   RFC5389 - Page 2
         7.2.1. Sending over UDP ...................................13
         7.2.2. Sending over TCP or TLS-over-TCP ...................14
    7.3. Receiving a STUN Message ..................................16
         7.3.1. Processing a Request ...............................17
                7.3.1.1. Forming a Success or Error Response .......18
                7.3.1.2. Sending the Success or Error Response .....19
         7.3.2. Processing an Indication ...........................19
         7.3.3. Processing a Success Response ......................19
         7.3.4. Processing an Error Response .......................20
 8. FINGERPRINT Mechanism ..........................................20
 9. DNS Discovery of a Server ......................................21
 10. Authentication and Message-Integrity Mechanisms ...............22
    10.1. Short-Term Credential Mechanism ..........................22
         10.1.1. Forming a Request or Indication ...................23
         10.1.2. Receiving a Request or Indication .................23
         10.1.3. Receiving a Response ..............................24
    10.2. Long-Term Credential Mechanism ...........................24
         10.2.1. Forming a Request .................................25
                10.2.1.1. First Request ............................25
                10.2.1.2. Subsequent Requests ......................26
         10.2.2. Receiving a Request ...............................26
         10.2.3. Receiving a Response ..............................27
 11. ALTERNATE-SERVER Mechanism ....................................28
 12. Backwards Compatibility with RFC 3489 .........................28
    12.1. Changes to Client Processing .............................29
    12.2. Changes to Server Processing .............................29
 13. Basic Server Behavior .........................................30
 14. STUN Usages ...................................................30
 15. STUN Attributes ...............................................31
    15.1. MAPPED-ADDRESS ...........................................32
    15.2. XOR-MAPPED-ADDRESS .......................................33
    15.3. USERNAME .................................................34
    15.4. MESSAGE-INTEGRITY ........................................34
    15.5. FINGERPRINT ..............................................36
    15.6. ERROR-CODE ...............................................36
    15.7. REALM ....................................................38
    15.8. NONCE ....................................................38
    15.9. UNKNOWN-ATTRIBUTES .......................................38
    15.10. SOFTWARE ................................................39
    15.11. ALTERNATE-SERVER ........................................39
 16. Security Considerations .......................................39
    16.1. Attacks against the Protocol .............................39
         16.1.1. Outside Attacks ...................................39
         16.1.2. Inside Attacks ....................................40
    16.2. Attacks Affecting the Usage ..............................40
         16.2.1. Attack I: Distributed DoS (DDoS) against a
                 Target ............................................41
         16.2.2. Attack II: Silencing a Client .....................41
Top   ToC   RFC5389 - Page 3
         16.2.3. Attack III: Assuming the Identity of a Client .....42
         16.2.4. Attack IV: Eavesdropping ..........................42
    16.3. Hash Agility Plan ........................................42
 17. IAB Considerations ............................................42
 18. IANA Considerations ...........................................43
    18.1. STUN Methods Registry ....................................43
    18.2. STUN Attribute Registry ..................................43
    18.3. STUN Error Code Registry .................................44
    18.4. STUN UDP and TCP Port Numbers ............................45
 19. Changes since RFC 3489 ........................................45
 20. Contributors ..................................................47
 21. Acknowledgements ..............................................47
 22. References ....................................................47
    22.1. Normative References .....................................47
    22.2. Informative References ...................................48
 Appendix A. C Snippet to Determine STUN Message Types .............50
Top   ToC   RFC5389 - Page 4

1. Introduction

The protocol defined in this specification, Session Traversal Utilities for NAT, provides a tool for dealing with NATs. It 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 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 connectivity checks between two endpoints [MMUSIC-ICE], or to relay packets between two endpoints [BEHAVE-TURN]. In keeping with its tool nature, this specification defines an extensible packet format, defines operation over several transport protocols, and provides for two forms of authentication. STUN is intended to be used in context of one or more NAT traversal solutions. These solutions are known as STUN usages. Each usage describes how STUN is utilized to achieve the NAT traversal solution. Typically, a usage indicates when STUN messages get sent, which optional attributes to include, what server is used, and what authentication mechanism is to be used. Interactive Connectivity Establishment (ICE) [MMUSIC-ICE] is one usage of STUN. SIP Outbound [SIP-OUTBOUND] is another usage of STUN. In some cases, a usage will require extensions to STUN. A STUN extension can be in the form of new methods, attributes, or error response codes. More information on STUN usages can be found in Section 14.

2. Evolution from RFC 3489

STUN was originally defined in RFC 3489 [RFC3489]. That specification, sometimes referred to as "classic STUN", represented itself as a complete solution to the NAT traversal problem. In that solution, a client would discover whether it was behind a NAT, determine its NAT type, discover its IP address and port on the public side of the outermost NAT, and then utilize that IP address and port within the body of protocols, such as the Session Initiation Protocol (SIP) [RFC3261]. However, experience since the publication of RFC 3489 has found that classic STUN simply does not work sufficiently well to be a deployable solution. The address and port learned through classic STUN are sometimes usable for communications with a peer, and sometimes not. Classic STUN provided no way to discover whether it would, in fact, work or not, and it provided no remedy in cases where it did not. Furthermore, classic STUN's algorithm for classification of NAT types was found to be faulty, as many NATs did not fit cleanly into the types defined there.
Top   ToC   RFC5389 - Page 5
   Classic STUN also had a security vulnerability -- attackers could
   provide the client with incorrect mapped addresses under certain
   topologies and constraints, and this was fundamentally not solvable
   through any cryptographic means.  Though this problem remains with
   this specification, those attacks are now mitigated through the use
   of more complete solutions that make use of STUN.

   For these reasons, this specification obsoletes RFC 3489, and instead
   describes STUN as a tool that is utilized as part of a complete NAT
   traversal solution.  ICE [MMUSIC-ICE] is a complete NAT traversal
   solution for protocols based on the offer/answer [RFC3264]
   methodology, such as SIP.  SIP Outbound [SIP-OUTBOUND] is a complete
   solution for traversal of SIP 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 STUN) as a traversal solution, such usage
   is not described here and is strongly discouraged for the reasons
   described above.

   The on-the-wire protocol described here is changed only slightly from
   classic STUN.  The protocol now runs over TCP in addition to UDP.
   Extensibility was added to the protocol in a more structured way.  A
   magic cookie mechanism for demultiplexing STUN with application
   protocols was added by stealing 32 bits from the 128-bit transaction
   ID defined in RFC 3489, allowing the change to be backwards
   compatible.  Mapped addresses are encoded using a new exclusive-or
   format.  There are other, more minor changes.  See Section 19 for a
   more complete listing.

   Due to the change in scope, STUN has also been renamed from "Simple
   Traversal of UDP through NAT" to "Session Traversal Utilities for
   NAT".  The acronym remains STUN, which is all anyone ever remembers
   anyway.

3. Overview of Operation

This section is descriptive only.
Top   ToC   RFC5389 - Page 6
                               /-----\
                             // STUN  \\
                            |   Server  |
                             \\       //
                               \-----/




                          +--------------+             Public Internet
          ................|     NAT 2    |.......................
                          +--------------+



                          +--------------+             Private NET 2
          ................|     NAT 1    |.......................
                          +--------------+




                              /-----\
                            //  STUN \\
                           |    Client |
                            \\       //               Private NET 1
                              \-----/


                 Figure 1: One Possible STUN Configuration

   One possible STUN configuration is shown in Figure 1.  In this
   configuration, there are two entities (called STUN agents) that
   implement the STUN protocol.  The lower agent in the figure is the
   client, and is connected to private network 1.  This network connects
   to private network 2 through NAT 1.  Private network 2 connects to
   the public Internet through NAT 2.  The upper agent in the figure is
   the server, and resides on the public Internet.

   STUN is a client-server protocol.  It supports two types of
   transactions.  One is a request/response transaction in which a
   client sends a request to a server, and the server returns a
   response.  The second is an indication transaction in which either
   agent -- client or server -- sends an indication that generates no
   response.  Both types of transactions include a transaction ID, which
   is a randomly selected 96-bit number.  For request/response
Top   ToC   RFC5389 - Page 7
   transactions, this transaction ID allows the client to associate the
   response with the request that generated it; for indications, the
   transaction ID serves as a debugging aid.

   All STUN messages start with a fixed header that includes a method, a
   class, and the transaction ID.  The method indicates which of the
   various requests or indications this is; this specification defines
   just one method, Binding, but other methods are expected to be
   defined in other documents.  The class indicates whether this is a
   request, a success response, an error response, or an indication.
   Following the fixed header comes zero or more attributes, which are
   Type-Length-Value extensions that convey additional information for
   the specific message.

   This document defines a single method called Binding.  The Binding
   method can be used either in request/response transactions or in
   indication transactions.  When used in request/response transactions,
   the Binding method can be used to determine the particular "binding"
   a NAT has allocated to a STUN client.  When used in either request/
   response or in indication transactions, the Binding method can also
   be used to keep these "bindings" alive.

   In the Binding request/response transaction, a Binding request is
   sent from a STUN client to a STUN server.  When the Binding request
   arrives at the STUN server, it may have passed through one or more
   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
   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,
   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
   the server.  This is called a reflexive transport address.  The STUN
   server copies that source transport address into an XOR-MAPPED-
   ADDRESS attribute in the STUN Binding response and sends the Binding
   response back to the STUN client.  As this packet passes back through
   a NAT, the NAT will modify the destination transport address in the
   IP header, but the transport address in the XOR-MAPPED-ADDRESS
   attribute within the body of the STUN response will remain untouched.
   In this way, the client can learn its reflexive transport address
   allocated by the outermost NAT with respect to the STUN server.

   In some usages, STUN must be multiplexed with other protocols (e.g.,
   [MMUSIC-ICE], [SIP-OUTBOUND]).  In these usages, there must be a way
   to inspect a packet and determine if it is a STUN 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 sufficient, then STUN
   packets can also contain a FINGERPRINT value, which can further be
   used to distinguish the packets.
Top   ToC   RFC5389 - Page 8
   STUN defines a set of optional procedures that a usage can decide to
   use, called mechanisms.  These mechanisms include DNS discovery, a
   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
   credential mechanism, are defined in this specification.  Each usage
   specifies the mechanisms allowed with that usage.

   In the long-term credential mechanism, the client and server share a
   pre-provisioned username and password and perform a digest challenge/
   response exchange inspired by (but differing in details) to the one
   defined for HTTP [RFC2617].  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 [MMUSIC-ICE] the two endpoints use out-of-band
   signaling to exchange a username and password.  These are used to
   integrity protect and authenticate the request and response.  There
   is no challenge or nonce used.

4. Terminology

In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant STUN implementations.

5. Definitions

STUN Agent: A STUN agent is an entity that implements the STUN protocol. The entity can be either a STUN client or a STUN server. STUN Client: A STUN client is an entity that sends STUN requests and receives STUN responses. A STUN client can also send indications. In this specification, the terms STUN client and client are synonymous. STUN Server: A STUN server is an entity that receives STUN requests and sends STUN responses. A STUN server can also send indications. In this specification, the terms STUN server and server are synonymous. Transport Address: The combination of an IP address and port number (such as a UDP or TCP port number).
Top   ToC   RFC5389 - Page 9
   Reflexive Transport Address:  A transport address learned by a client
      that identifies that client as seen by another host on an IP
      network, typically a STUN server.  When there is an intervening
      NAT between the client and the other host, the reflexive transport
      address represents the mapped address allocated to the client on
      the public side of the NAT.  Reflexive transport addresses are
      learned from the mapped address attribute (MAPPED-ADDRESS or XOR-
      MAPPED-ADDRESS) in STUN responses.

   Mapped Address:  Same meaning as reflexive address.  This term is
      retained only for historic reasons and due to the naming of the
      MAPPED-ADDRESS and XOR-MAPPED-ADDRESS attributes.

   Long-Term Credential:  A username and associated password that
      represent a shared secret between client and server.  Long-term
      credentials are generally granted to the client when a subscriber
      enrolls in a service and persist until the subscriber leaves the
      service or explicitly changes the credential.

   Long-Term Password:  The password from a long-term credential.

   Short-Term Credential:  A temporary username and associated password
      that represent a shared secret between client and server.  Short-
      term credentials are obtained through some kind of protocol
      mechanism between the client and server, preceding the STUN
      exchange.  A short-term credential has an explicit temporal scope,
      which may be based on a specific amount of time (such as 5
      minutes) or on an event (such as termination of a SIP dialog).
      The specific scope of a short-term credential is defined by the
      application usage.

   Short-Term Password:  The password component of a short-term
      credential.

   STUN Indication:  A STUN message that does not receive a response.

   Attribute:  The STUN term for a Type-Length-Value (TLV) object that
      can be added to a STUN message.  Attributes are divided into two
      types: comprehension-required and comprehension-optional.  STUN
      agents can safely ignore comprehension-optional attributes they
      don't understand, but cannot successfully process a message if it
      contains comprehension-required attributes that are not
      understood.

   RTO:  Retransmission TimeOut, which defines the initial period of
      time between transmission of a request and the first retransmit of
      that request.
Top   ToC   RFC5389 - Page 10

6. STUN Message Structure

STUN messages are encoded in binary using network-oriented format (most significant byte or octet first, also commonly known as big- endian). The transmission order is described in detail in Appendix B of RFC 791 [RFC0791]. Unless otherwise noted, numeric constants are in decimal (base 10). All STUN messages MUST start with a 20-byte header followed by zero or more Attributes. The STUN header contains a STUN message type, magic cookie, transaction ID, and message length. 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 0| STUN Message Type | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Magic Cookie | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Transaction ID (96 bits) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Format of STUN Message Header The most significant 2 bits of every STUN message MUST be zeroes. This can be used to differentiate STUN packets from other protocols when STUN is multiplexed with other protocols on the same port. The message type defines the message class (request, success response, failure response, or indication) and the message method (the primary function) of the STUN message. Although there are four message classes, there are only two types of transactions in STUN: request/response transactions (which consist of a request message and a response message) and indication transactions (which consist of a single indication message). Response classes are split into error and success responses to aid in quickly processing the STUN message.
Top   ToC   RFC5389 - Page 11
   The message type field is decomposed further into the following
   structure:

                        0                 1
                        2  3  4 5 6 7 8 9 0 1 2 3 4 5

                       +--+--+-+-+-+-+-+-+-+-+-+-+-+-+
                       |M |M |M|M|M|C|M|M|M|C|M|M|M|M|
                       |11|10|9|8|7|1|6|5|4|0|3|2|1|0|
                       +--+--+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3: Format of STUN Message Type Field

   Here the bits in the message type field are shown as most significant
   (M11) through least significant (M0).  M11 through M0 represent a 12-
   bit encoding of the method.  C1 and C0 represent a 2-bit encoding of
   the class.  A class of 0b00 is a request, a class of 0b01 is an
   indication, a class of 0b10 is a success response, and a class of
   0b11 is an error response.  This specification defines a single
   method, Binding.  The method and class are orthogonal, so that for
   each method, a request, success response, error response, and
   indication are possible for that method.  Extensions defining new
   methods MUST indicate which classes are permitted for that method.

   For example, a Binding request has class=0b00 (request) and
   method=0b000000000001 (Binding) and is encoded into the first 16 bits
   as 0x0001.  A Binding response has class=0b10 (success response) and
   method=0b000000000001, and is encoded into the first 16 bits as
   0x0101.

      Note: This unfortunate encoding is due to assignment of values in
      [RFC3489] that did not consider encoding Indications, Success, and
      Errors using bit fields.

   The magic cookie field MUST contain the fixed value 0x2112A442 in
   network byte order.  In RFC 3489 [RFC3489], this field was part of
   the transaction ID; placing the magic cookie in this location allows
   a server to detect if the client will understand certain attributes
   that were added in this revised specification.  In addition, it aids
   in distinguishing STUN packets from packets of other protocols when
   STUN is multiplexed with those other protocols on the same port.

   The transaction ID is a 96-bit identifier, used to uniquely identify
   STUN transactions.  For request/response transactions, the
   transaction ID is chosen by the STUN client for the request and
   echoed by the server in the response.  For indications, it is chosen
   by the agent sending the indication.  It primarily serves to
   correlate requests with responses, though it also plays a small role
Top   ToC   RFC5389 - Page 12
   in helping to prevent certain types of attacks.  The server also uses
   the transaction ID as a key to identify each transaction uniquely
   across all clients.  As such, the transaction ID MUST be uniformly
   and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be
   cryptographically random.  Resends of the same request reuse the same
   transaction ID, but the client MUST choose a new transaction ID for
   new transactions unless the new request is bit-wise identical to the
   previous request and sent from the same transport address to the same
   IP address.  Success and error responses MUST carry the same
   transaction ID as their corresponding request.  When an agent is
   acting as a STUN server and STUN client on the same port, the
   transaction IDs in requests sent by the agent have no relationship to
   the transaction IDs in requests received by the agent.

   The message length MUST contain the size, in bytes, of the message
   not including the 20-byte STUN header.  Since all STUN attributes are
   padded to a multiple of 4 bytes, the last 2 bits of this field are
   always zero.  This provides another way to distinguish STUN packets
   from packets of other protocols.

   Following the STUN fixed portion of the header are zero or more
   attributes.  Each attribute is TLV (Type-Length-Value) encoded.  The
   details of the encoding, and of the attributes themselves are given
   in Section 15.



(page 12 continued on part 2)

Next Section