rfc3489.txt

this is simple sip stack.

Network Working Group                                       J. Rosenberg
Request for Comments: 3489                                 J. Weinberger
Category: Standards Track                                    dynamicsoft
                                                              C. Huitema
                                                               Microsoft
                                                                 R. Mahy
                                                                   Cisco
                                                              March 2003


        STUN - Simple Traversal of User Datagram Protocol (UDP)
               Through Network Address Translators (NATs)

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.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Abstract

   Simple Traversal of User Datagram Protocol (UDP) Through Network
   Address Translators (NATs) (STUN) is a lightweight protocol that
   allows applications to discover the presence and types of NATs and
   firewalls between them and the public Internet.  It also provides the
   ability for applications to determine the public Internet Protocol
   (IP) addresses allocated to them by the NAT.  STUN works with many
   existing NATs, and does not require any special behavior from them.
   As a result, it allows a wide variety of applications to work through
   existing NAT infrastructure.

Table of Contents

   1.   Applicability Statement ...................................    3
   2.   Introduction ..............................................    3
   3.   Terminology ...............................................    4
   4.   Definitions ...............................................    5
   5.   NAT Variations ............................................    5
   6.   Overview of Operation .....................................    6
   7.   Message Overview ..........................................    8
   8.   Server Behavior ...........................................   10
        8.1   Binding Requests ....................................   10



Rosenberg, et al.           Standards Track                     [Page 1]

RFC 3489                          STUN                        March 2003


        8.2   Shared Secret Requests ..............................   13
   9.   Client Behavior ...........................................   14
        9.1   Discovery ...........................................   15
        9.2   Obtaining a Shared Secret ...........................   15
        9.3   Formulating the Binding Request .....................   17
        9.4   Processing Binding Responses ........................   17
   10.  Use Cases .................................................   19
        10.1  Discovery Process ...................................   19
        10.2  Binding Lifetime Discovery ..........................   21
        10.3  Binding Acquisition .................................   23
   11.  Protocol Details ..........................................   24
        11.1  Message Header ......................................   25
        11.2  Message Attributes ..................................   26
              11.2.1  MAPPED-ADDRESS ..............................   27
              11.2.2  RESPONSE-ADDRESS ............................   27
              11.2.3  CHANGED-ADDRESS .............................   28
              11.2.4  CHANGE-REQUEST ..............................   28
              11.2.5  SOURCE-ADDRESS ..............................   28
              11.2.6  USERNAME ....................................   28
              11.2.7  PASSWORD ....................................   29
              11.2.8  MESSAGE-INTEGRITY ...........................   29
              11.2.9  ERROR-CODE ..................................   29
              11.2.10 UNKNOWN-ATTRIBUTES ..........................   31
              11.2.11 REFLECTED-FROM ..............................   31
   12.  Security Considerations ...................................   31
        12.1  Attacks on STUN .....................................   31
              12.1.1  Attack I: DDOS Against a Target .............   32
              12.1.2  Attack II: Silencing a Client ...............   32
              12.1.3  Attack III: Assuming the Identity of a Client   32
              12.1.4  Attack IV: Eavesdropping ....................   33
        12.2  Launching the Attacks ...............................   33
              12.2.1  Approach I: Compromise a Legitimate
                      STUN Server .................................   33
              12.2.2  Approach II: DNS Attacks ....................   34
              12.2.3  Approach III: Rogue Router or NAT ...........   34
              12.2.4  Approach IV: MITM ...........................   35
              12.2.5  Approach V: Response Injection Plus DoS .....   35
              12.2.6  Approach VI: Duplication ....................   35
        12.3  Countermeasures .....................................   36
        12.4  Residual Threats ....................................   37
   13.  IANA Considerations .......................................   38
   14.  IAB Considerations ........................................   38
        14.1  Problem Definition ..................................   38
        14.2  Exit Strategy .......................................   39
        14.3  Brittleness Introduced by STUN ......................   40
        14.4  Requirements for a Long Term Solution ...............   42
        14.5  Issues with Existing NAPT Boxes .....................   43
        14.6  In Closing ..........................................   43



Rosenberg, et al.           Standards Track                     [Page 2]

RFC 3489                          STUN                        March 2003


   15.  Acknowledgments ...........................................   44
   16.  Normative References ......................................   44
   17.  Informative References ....................................   44
   18.  Authors' Addresses ........................................   46
   19.  Full Copyright Statement...................................   47

1.  Applicability Statement

   This protocol is not a cure-all for the problems associated with NAT.
   It does not enable incoming TCP connections through NAT.  It allows
   incoming UDP packets through NAT, but only through a subset of
   existing NAT types.  In particular, STUN does not enable incoming UDP
   packets through symmetric NATs (defined below), which are common in
   large enterprises.  STUN's discovery procedures are based on
   assumptions on NAT treatment of UDP; such assumptions may prove
   invalid down the road as new NAT devices are deployed.  STUN does not
   work when it is used to obtain an address to communicate with a peer
   which happens to be behind the same NAT.  STUN does not work when the
   STUN server is not in a common shared address realm.  For a more
   complete discussion of the limitations of STUN, see Section 14.

2.  Introduction

   Network Address Translators (NATs), while providing many benefits,
   also come with many drawbacks.  The most troublesome of those
   drawbacks is the fact that they break many existing IP applications,
   and make it difficult to deploy new ones.  Guidelines have been
   developed [8] that describe how to build "NAT friendly" protocols,
   but many protocols simply cannot be constructed according to those
   guidelines.  Examples of such protocols include almost all peer-to-
   peer protocols, such as multimedia communications, file sharing and
   games.

   To combat this problem, Application Layer Gateways (ALGs) have been
   embedded in NATs.  ALGs perform the application layer functions
   required for a particular protocol to traverse a NAT.  Typically,
   this involves rewriting application layer messages to contain
   translated addresses, rather than the ones inserted by the sender of
   the message.  ALGs have serious limitations, including scalability,
   reliability, and speed of deploying new applications.  To resolve
   these problems, the Middlebox Communications (MIDCOM) protocol is
   being developed [9].  MIDCOM allows an application entity, such as an
   end client or network server of some sort (like a Session Initiation
   Protocol (SIP) proxy [10]) to control a NAT (or firewall), in order
   to obtain NAT bindings and open or close pinholes.  In this way, NATs
   and applications can be separated once more, eliminating the need for
   embedding ALGs in NATs, and resolving the limitations imposed by
   current architectures.



Rosenberg, et al.           Standards Track                     [Page 3]

RFC 3489                          STUN                        March 2003


   Unfortunately, MIDCOM requires upgrades to existing NAT and
   firewalls, in addition to application components.  Complete upgrades
   of these NAT and firewall products will take a long time, potentially
   years.  This is due, in part, to the fact that the deployers of NAT
   and firewalls are not the same people who are deploying and using
   applications.  As a result, the incentive to upgrade these devices
   will be low in many cases.  Consider, for example, an airport
   Internet lounge that provides access with a NAT.  A user connecting
   to the NATed network may wish to use a peer-to-peer service, but
   cannot, because the NAT doesn't support it.  Since the administrators
   of the lounge are not the ones providing the service, they are not
   motivated to upgrade their NAT equipment to support it, using either
   an ALG, or MIDCOM.

   Another problem is that the MIDCOM protocol requires that the agent
   controlling the middleboxes know the identity of those middleboxes,
   and have a relationship with them which permits control.  In many
   configurations, this will not be possible.  For example, many cable
   access providers use NAT in front of their entire access network.
   This NAT could be in addition to a residential NAT purchased and
   operated by the end user.  The end user will probably not have a
   control relationship with the NAT in the cable access network, and
   may not even know of its existence.

   Many existing proprietary protocols, such as those for online games
   (such as the games described in RFC 3027 [11]) and Voice over IP,
   have developed tricks that allow them to operate through NATs without
   changing those NATs.  This document is an attempt to take some of
   those ideas, and codify them into an interoperable protocol that can
   meet the needs of many applications.

   The protocol described here, Simple Traversal of UDP Through NAT
   (STUN), allows entities behind a NAT to first discover the presence
   of a NAT and the type of NAT, and then to learn the addresses
   bindings allocated by the NAT.  STUN requires no changes to NATs, and
   works with an arbitrary number of NATs in tandem between the
   application entity and the public Internet.

3.  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
   [1] and indicate requirement levels for compliant STUN
   implementations.






Rosenberg, et al.           Standards Track                     [Page 4]

RFC 3489                          STUN                        March 2003


4.  Definitions

   STUN Client: A STUN client (also just referred to as a client)
      is an entity that generates STUN requests.  A STUN client can
      execute on an end system, such as a user's PC, or can run in a
      network element, such as a conferencing server.

   STUN Server: A STUN Server (also just referred to as a server)
      is an entity that receives STUN requests, and sends STUN
      responses.  STUN servers are generally attached to the public
      Internet.

5.  NAT Variations

   It is assumed that the reader is familiar with NATs.  It has been
   observed that NAT treatment of UDP varies among implementations.  The
   four treatments observed in implementations are:

   Full Cone: A full cone NAT is one where all requests from the
      same internal IP address and port are mapped to the same external
      IP address and port.  Furthermore, any external host can send a
      packet to the internal host, by sending a packet to the mapped
      external address.

   Restricted Cone: A restricted cone NAT is one where all requests
      from the same internal IP address and port are mapped to the same
      external IP address and port.  Unlike a full cone NAT, an external
      host (with IP address X) can send a packet to the internal host
      only if the internal host had previously sent a packet to IP
      address X.

   Port Restricted Cone: A port restricted cone NAT is like a
      restricted cone NAT, but the restriction includes port numbers.
      Specifically, an external host can send a packet, with source IP
      address X and source port P, to the internal host only if the
      internal host had previously sent a packet to IP address X and
      port P.

   Symmetric: A symmetric NAT is one where all requests from the
      same internal IP address and port, to a specific destination IP
      address and port, are mapped to the same external IP address and
      port.  If the same host sends a packet with the same source
      address and port, but to a different destination, a different
      mapping is used.  Furthermore, only the external host that