Skip to main content

NAT Behavior Discovery Using Session Traversal Utilities for NAT (STUN)
draft-ietf-behave-nat-behavior-discovery-08

The information below is for an old version of the document that is already published as an RFC.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 5780.
Authors Derek MacDonald , Bruce Lowekamp
Last updated 2020-01-21 (Latest revision 2009-09-27)
Replaces draft-macdonald-behave-nat-behavior-discovery
RFC stream Internet Engineering Task Force (IETF)
Intended RFC status Experimental
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 5780 (Experimental)
Action Holders
(None)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD Magnus Westerlund
Send notices to (None)
draft-ietf-behave-nat-behavior-discovery-08
BEHAVE                                                      D. MacDonald
Internet-Draft                               CounterPath Solutions, Inc.
Intended status: Experimental                                B. Lowekamp
Expires: March 31, 2010                                        MYMIC LLC
                                                      September 27, 2009

                   NAT Behavior Discovery Using STUN
              draft-ietf-behave-nat-behavior-discovery-08

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on March 31, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 1]
Internet-Draft           NAT Behavior Discovery           September 2009

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   This specification defines an experimental usage of the Session
   Traversal Utilities for NAT (STUN) Protocol that discovers the
   presence and current behaviour of NATs and firewalls between the STUN
   client and the STUN server.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 2]
Internet-Draft           NAT Behavior Discovery           September 2009

Table of Contents

   1.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Example Diagnostic Use . . . . . . . . . . . . . . . . . .  7
     2.2.  Example Use with P2P Overlays  . . . . . . . . . . . . . .  7
     2.3.  Experimental Success . . . . . . . . . . . . . . . . . . .  9
   3.  Overview of Operations . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Determining NAT Mapping  . . . . . . . . . . . . . . . . . 10
     3.2.  Determining NAT Filtering  . . . . . . . . . . . . . . . . 11
     3.3.  Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11
     3.4.  Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
     3.5.  Determining Fragment Handling  . . . . . . . . . . . . . . 12
     3.6.  Detecting a Generic Application Level Gateways (ALG) . . . 12
   4.  Discovery Process  . . . . . . . . . . . . . . . . . . . . . . 12
     4.1.  Source Port Selection  . . . . . . . . . . . . . . . . . . 13
     4.2.  Checking for UDP Connectivity with the STUN Server . . . . 14
     4.3.  Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
     4.4.  Determining NAT Filtering Behavior . . . . . . . . . . . . 15
     4.5.  Combining and Ordering Tests . . . . . . . . . . . . . . . 15
     4.6.  Binding Lifetime Discovery . . . . . . . . . . . . . . . . 16
   5.  Client Behavior  . . . . . . . . . . . . . . . . . . . . . . . 17
     5.1.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . 18
     5.2.  Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
   6.  Server Behavior  . . . . . . . . . . . . . . . . . . . . . . . 19
     6.1.  Preparing the Response . . . . . . . . . . . . . . . . . . 19
   7.  New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 21
     7.1.  Representing Transport Addresses . . . . . . . . . . . . . 21
     7.2.  CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 22
     7.3.  RESPONSE-ORIGIN  . . . . . . . . . . . . . . . . . . . . . 22
     7.4.  OTHER-ADDRESS  . . . . . . . . . . . . . . . . . . . . . . 22
     7.5.  RESPONSE-PORT  . . . . . . . . . . . . . . . . . . . . . . 23
     7.6.  PADDING  . . . . . . . . . . . . . . . . . . . . . . . . . 23
   8.  IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
     8.1.  Problem Definition . . . . . . . . . . . . . . . . . . . . 24
     8.2.  Exit Strategy  . . . . . . . . . . . . . . . . . . . . . . 24
     8.3.  Brittleness Introduced by STUN NAT Behavior Discovery  . . 24
     8.4.  Requirements for a Long Term Solution  . . . . . . . . . . 25
     8.5.  Issues with Existing NAPT Boxes  . . . . . . . . . . . . . 25
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 25
     9.1.  STUN Attribute Registry  . . . . . . . . . . . . . . . . . 25
     9.2.  SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 26
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 26
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
     12.2. Informative References . . . . . . . . . . . . . . . . . . 27
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 28

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 3]
Internet-Draft           NAT Behavior Discovery           September 2009

     A.1.  from draft-macdonald-behave-nat-behavior-diagnostics-00  . 28
     A.2.  from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 28
     A.3.  from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 28
     A.4.  from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 29
     A.5.  from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 29
     A.6.  from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 29
     A.7.  from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 30
     A.8.  from draft-ietf-behave-nat-behavior-discovery-06 . . . . . 30
     A.9.  from draft-ietf-behave-nat-behavior-discovery-07 . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 4]
Internet-Draft           NAT Behavior Discovery           September 2009

1.  Applicability

   This experimental NAT Behavior Discovery STUN usage provides
   information about a NAT device's observable transient behavior; it
   determines a NAT's behavior with regard to the STUN server used and
   the particular client ports used at the instant the test is run.
   This STUN usage does not allow an application behind a NAT to make an
   absolute determination of the NAT's characteristics.  NAT devices do
   not behave consistently enough to predict future behaviour with any
   guarantee.  Applications requiring reliable reach between two
   particular endpoints must establish a communication channel through
   NAT using another technique.  IETF has proposed standards including
   ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for
   establishing communication channels when a publicly accessible
   rendezvous service is available.

   The primary uses envisioned for the STUN attributes included in this
   draft are diagnostics and real-time tuning of applications.  The
   techniques possible with this usage are powerful diagnostic tools in
   the hands of a network administrator or system programmer trying to
   determine the causes of network failure; particularly when behavior
   varies by load, destination, or other factors that may be related to
   NAT behavior.

   This draft also proposes experimental usage of these attributes for
   real-time optimization of parameters for protocols in situations
   where a publicly accessible rendezvous service is not available.
   Such a use of these techniques is only possible when the results are
   applied as an optimization and a reliable fallback is available in
   case the NAT's behavior becomes more restrictive than determined by
   the Behavior Discovery tests.  One possible application is role
   selection in P2P networks based on statistical experience with
   establishing direct connections and diagnosing NAT behavior with a
   variety of peers.  The experimental question is whether such a test
   is useful.  If a node trying to join an overlay as a full peer when
   its NAT prevents sufficient connectivity and then withdrawing is
   expensive or leads to unreliable or poorly performing operation, then
   even if the behavior discovery check is only "correct" 75% of the
   time, its relative cheapness may make it very useful for optimizing
   the behavior of the overlay network.  Section 2.2 describes this
   experimental application in more detail and discusses how to evaluate
   its success or failure.

   The applications of this STUN usage differ from the original use of
   STUN (originally RFC3489 [RFC3489], now RFC5389 [RFC3489]).  This
   specification acknowledges that the information gathered in this
   usage is not, and cannot be, correct 100% of the time, whereas STUN
   focused only on getting information that could be known to be correct

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 5]
Internet-Draft           NAT Behavior Discovery           September 2009

   and static.

   This specification can also be compared to ICE.  ICE requires a
   fallback to TURN be available wheras 3489-based applications tried to
   determine in advance whether they would need a relay and what their
   peer reflexive address will be, which is not generally achievable.
   be, which are both impossible.  This STUN usage requires an
   application using it to have a fallback, but unlike ICE's focus on
   the problems inherent in VoIP sessions, doesn't assume that it will
   only be used to establish a connection between a single pair of
   machines, and so alternative fallback mechanisms may make sense.  For
   example, in a P2P application it may be possible to simply switch out
   of the role where such connections need to be established or to
   select an alternative indirect route if the peer discovers that, in
   practice, 10% of its connection attempts fail.

   It is submitted to the Internet community as an experimental protocol
   that, when applied with appropriate statistical underpinnings and
   application behavior that is ultimately based on experienced
   connectivity patterns, can lead to more stability and increased
   performance than is available without the knowledge it provides.

   If a standards document specifies the use of any portion of this STUN
   usage, that document MUST describe how incorrect information derived
   using these methods will be managed, either through identifying when
   a NAT's behavior changed or because the protocol uses such knowledge
   as an optimization but remains functional when the NAT's behavior
   changes.  The referencing document MUST also define when the fallback
   mechanism will be invoked.  Applications in different domains may
   vary greatly in how agressively the fallback mechanism is utilized,
   so there must be a clear defintion of when the fallback mechanism is
   invoked.

2.  Introduction

   The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a
   mechanism to discover the reflexive transport address toward the STUN
   server, using the Binding Request.  This specification defines the
   NAT Behavior Discovery STUN usage, which allows a STUN client to
   probe the current behaviour of the NAT/Firewall devices between the
   client and the STUN server.  This usage defines new STUN attributes
   for the Binding Request and Binding Response.

   Many NAT/FW devices do not behave consistently and will change their
   behaviour under load and over time.  Applications requiring high
   reliability must be prepared for the NAT's behaviour to become more
   restrictive.  Specifically, it has been found that under load NATs

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 6]
Internet-Draft           NAT Behavior Discovery           September 2009

   may transition to the most restrictive filtering and mapping
   behaviour and shorten the lifetime of new and existing bindings.  In
   short, applications can discover how bad things currently are, but
   not how bad things will get.

   Despite this limitation, instantaneous observations are often quite
   useful in troubleshooting network problems, and repeated tests over
   time, or in known load situations, may be used to characterize a
   NAT's behavior.  In particular, in the hands of a person
   knowledgeable about the needs of an application and the nodes an
   application needs to communicate with, it can be a powerful tool.

2.1.  Example Diagnostic Use

   Applications that work well in the lab, but fail in a deployment, are
   notoriously common within distributed systems.  There are few systems
   developers who have not had the experience of searching to determine
   the difference in the environments for insight as to what real-
   network behavior was missed in the testing lab.  The behavior
   discovery usage offers a powerful tool that can be used to check NAT
   and firewall behavior as the application is running.  For example, an
   application could be designed to perform Behavior Discovery tests
   whenever it experiences significant communications problems when
   running.  Such analysis might be included as part of the diagnostic
   information logged by the application.

   As they are being used to detect instantaneous behavior for analysis
   by an experienced developer or administrator, there are relatively
   few concerns about this application of the NAT Behavior Discovery
   STUN usage.  However, the user should be aware that

   o  adding new traffic to new destinations (STUN servers) has the
      potential to itself change the behavior of a NAT and

   o  the user must be careful to select a STUN server that is
      appropriately located, ideally collocated (or even integrated)
      with the communication partners of the application in question,
      for the results to be applicable to the network conditions
      experienced by the application.

2.2.  Example Use with P2P Overlays

   An application could use Behavior Discovery in a Peer-to-Peer (P2P)
   protocol to determine if a particular endpoint is a reasonable
   candidate to participate as a peer or supernode (defined here as a
   peer in the overlay that offers services, including message routing,
   to other members or clients of the overlay network).  This P2P
   network application is willing to select supernodes that might be

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 7]
Internet-Draft           NAT Behavior Discovery           September 2009

   located behind NATs to avoid the cost of dedicated servers.  A
   supernode candidate requires that its NAT(s) offer(s) Endpoint-
   Independent Filtering.  It might periodically re-run tests and would
   remove itself as a supernode if its NAT/FW chain lost this
   characteristic.  These tests could be run with other supernodes
   acting as STUN servers as well as with dedicated STUN servers.  As
   many P2P algorithms tolerate non-transitive connectivity between a
   portion of their peers, guaranteed pair-wise reliable reach might be
   sacrificed in order to distribute the P2P overlay's load across peers
   that can be directly contacted by the majority of users.

   Consider an example from a hypothetical P2P protocol in more detail:
   When P2P node A starts up, it tests its NAT(s) relative to other
   peers already in the overlay.  If the results of its testing indicate
   A is behind a "good" NAT (with endpoint-independent mapping and
   filtering), A will join the overlay and establish connections with
   appropriate peers in the overlay to join the overlay's topology.
   Although A is reachable by routing messages across the overlay
   topology, A will also include in its communication with other nodes
   that they may reach it directly using its reflexive IP address (or
   addresses) that A discovered in its initial testing.  Suppose that
   later, node B wants to send a message to A, and B is not a neighbor
   of A in the overlay topology.  B may send the message directly to A's
   IP address and start a timer.  If B doesn't receive a response within
   a certain amount of time, then it routes the message to A across the
   overlay instead and includes a flag that indicates a direct
   connection was attempted but failed.  (Alternatively, B could
   simultaneously send the message to A's IP address and across the
   overlay, which guarantees minimum response latency, but can waste
   bandwidth.)  A over time observes the percentage of successful direct
   messages it receives out of those attempted.  If the percentage of
   successful direct connections is below some threshold (perhaps 75%),
   then A may stop advertising for direct connections because it has
   determined in practice that its NATs are not providing sufficiently
   reliable connectivity to justify the cost of attempting the direct
   message.  But if the percentage is high enough, A continues to
   advertise because the successful direct connections are improving the
   overlay's performance by reducing the routing load imposed on the
   overlay.  If at some point, A's NAT(s) changes behavior, A will
   notice a change in its percentage of successful direct connections
   and may re-evaluate its decision to advertise a public address.  In
   this hypothetical example, Behavior Discovery is used for A's initial
   operating mode selection, but the actual decision for whether to
   continue advertising that public IP/port pair is made based on actual
   operating data.  The results of the behavior-discovery usage are also
   used as a performance optimization, as A is at all times able to
   establish connectivity through the overlay if the attempted direct
   connection fails.

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 8]
Internet-Draft           NAT Behavior Discovery           September 2009

   Use of Behavior Discovery for such an application requires:

   o  Use of a protocol capable of offering reliable end-user
      performance using unreliable links between peers.

   o  A protocol offering a reliable fallback to connections attempted
      based on the results of Behavior Discovery probing.

   o  The application is deployed behind NATs that provide Endpoint-
      Independent Filtering and that remain in this mode for an amount
      of time sufficient for the application to identify their behavior,
      distribute this information to the rest of the overlay, and
      provide useful work for the application.

   This draft is experimental as applications implementing open
   protocols have yet to be deployed in such environments to demonstrate
   that these three requirements have been met.  However, anecdotal
   evidence suggests that NATs targeted at households and small
   businesses have stable behaviour, especially when there are few
   clients behind them.  Numerous P2P applications have been deployed
   that appear to have these properties, although their protocols have
   not yet been subjected to rigorous evaluation by standards bodies.

2.3.  Experimental Success

   The criteria for an application to successfully demonstrate use of
   the NAT Behavior Discovery STUN usage would include:

   o  An implementation that relies on this usage to determine its run-
      time behavior, most likely using it to determine an initial choice
      of options that are then adjusted based on experience with its
      network connections.

   o  The implementation must either demonstrate its applicability in
      environments where it is realistic to expect a provider to deploy
      dedicated STUN servers with multiple IP addresses, or it must
      demonstrate duplicating the behavior of such a dedicated STUN
      server with two nodes that share the role of providing the
      address-changing operations required by this usage.

   o  Experimental evidence that the application of this usage results
      in improved behavior of the application in real-world conditions.
      The exact metrics for this improvement may vary, some
      possibilities include: faster convergence to the proper
      parameters, less work to set up initial connections, fewer
      reconfigurations required after startup, etc.

MacDonald & Lowekamp     Expires March 31, 2010                 [Page 9]
Internet-Draft           NAT Behavior Discovery           September 2009

   o  A protocol specification that defines how the implementation
      applies this usage.

   The P2P scenario described above is a likely experimental test case
   for this usage, but others applications are possible as well.

3.  Overview of Operations

   In a typical configuration, a STUN client is connected to a private
   network and through one or more NATs to the public Internet.  The
   client is configured with the address of a STUN server on the public
   Internet.  The Behavior Discovery usage makes use of SRV records so
   that a server may use a different transport address for this usage
   than for other usages.  This usage does not provide backward
   compatibility with RFC3489 [RFC3489] for either clients or servers.
   Implementors of clients that wish to be compliant with RFC3489
   servers should see that specification.  Implementors of servers
   SHOULD NOT include support for RFC3489 clients as the original uses
   of that protocol have been deprecated.

   Because the STUN forbids a server from creating a new TCP or TCP/TLS
   connection to the client, many tests apply only to UDP.  The
   applicability of the various tests is indicated below.

   The STUN NAT Behavior Discovery usage defines new attributes on the
   STUN Binding Request and STUN Binding Response that allow these
   messages to be used to diagnose the current behavior of the NAT(s)
   between the client and server.

   This section provides a descriptive overview of the typical use of
   these attributes.  Normative behavior is described in Sections 5, 6
   and 7.

3.1.  Determining NAT Mapping

   A client behind a NAT wishes to determine if the NAT it is behind is
   currently using endpoint-independent, address-dependent, or address
   and port-dependent mapping[RFC4787].  The client performs a series of
   tests that make use of the OTHER-ADDRESS attribute; these tests are
   described in detail in Section 4.  These tests send binding requests
   to the alternate address and port of the STUN server to determine
   mapping behaviour.  These tests can be used for UDP, TCP, or TCP/TLS
   connections.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 10]
Internet-Draft           NAT Behavior Discovery           September 2009

3.2.  Determining NAT Filtering

   A client behind a NAT wishes to determine if the NAT it is behind is
   currently using endpoint-independent, address-dependent, or address
   and port-dependent filtering[RFC4787].  The client performs a series
   of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST
   attributes; these tests are described in Section 4.  These tests
   request responses from the alternate address and port of the STUN
   server; a precondition to these tests is that no binding be
   established to the alternate address and port.  See below for more
   information.  Because the NAT does not know that the alternate
   address and port belong to the same server as the primary address and
   port, it treats these responses the same as it would those from any
   other host on the Internet.  Therefore, the success of the binding
   responses sent from the alternate address and port indicate whether
   the NAT is currently performing endpoint-independent filtering,
   address-dependent filtering, or address and port-dependent filtering.
   This test applies only to UDP datagrams.

3.3.  Binding Lifetime Discovery

   Many systems, such as VoIP, rely on being able to keep a connection
   open between a client and server or between peers of a P2P system.
   Because NAT bindings expire over time, keepalive messages must be
   sent across the connection to preserve it.  Because keepalives impose
   some overhead on the network and servers, reducing the frequency of
   keepalives can be useful.

   A normal request-response protocol cannot be used to test binding
   lifetime because the initial request resets the binding timer.
   Behavior Discover defines the RESPONSE-PORT attribute to allow the
   client and server to set up a "control channel" using one port on the
   client that is used to test the binding lifetime of a different port
   allocated on the client.  More generally, RESPONSE-PORT allows the
   client to allocate two ports and request that responses to queries
   sent from one port be delivered to the other.  The client uses its
   second port and the STUN server's alternate address to check if an
   existing binding that hasn't had traffic sent on it is still open
   after time T. This approach is described in detail in Section 4.6.
   This test applies only to UDP datagrams.

3.4.  Diagnosing NAT Hairpinning

   STUN Binding Requests allow a client to determine whether it is
   behind a NAT that supports hairpinning of connections.  To perform
   this test, the client first sends a Binding Request to its STUN
   server to determine its mapped address.  The client then sends a STUN
   Binding Request to this mapped address from a different port.  If the

MacDonald & Lowekamp     Expires March 31, 2010                [Page 11]
Internet-Draft           NAT Behavior Discovery           September 2009

   client receives its own request, the NAT hairpins connections.  This
   test applies to UDP, TCP, or TCP/TLS connections.

3.5.  Determining Fragment Handling

   Some NATs exhibit different behavior when forwarding fragments than
   when forwarding a single-frame datagram.  In particular, some NATs do
   not hairpin fragments at all and some platforms discard fragments
   under load.  To diagnose this behavior, STUN messages may be sent
   with the PADDING attribute, which simply inserts additional space
   into the message.  By forcing the STUN message to be divided into
   multiple fragments, the NAT's behavior can be observed.

   All of the previous tests can be performed with PADDING if a NAT's
   fragment behavior is important for an application, or only those
   tests which are most interesting to the application can be retested.
   PADDING only applies to UDP datagrams.  PADDING can not be used with
   RESPONSE-PORT.

3.6.  Detecting a Generic Application Level Gateways (ALG)

   A number of NAT boxes are now being deployed into the market which
   try to provide "generic" ALG functionality.  These generic ALGs hunt
   for IP addresses, either in text or binary form within a packet, and
   rewrite them if they match a binding.  This behavior can be detected
   because the STUN server returns both the MAPPED-ADDRESS and XOR-
   MAPPED-ADDRESS in the same response.  If the result in the two does
   not match, there is a NAT with a generic ALG in the path.  This test
   apples to UDP and TCP, but not TLS over TCP connections.

4.  Discovery Process

   This section provides a descriptive overview of how the NAT Behavior
   Discovery usage primitives allow checks to be made to discover the
   current behaviour of the NAT or NATs an application is behind.  These
   tests can only give the instantaneous behaviour of a NAT; it has been
   found that NATs can change behaviour under load and over time.  The
   results of these tests therefore can be regarded as upper bounds---an
   application must assume that NAT behaviour can become more
   restrictive at any time.  Results from tests performed using a
   particular port on the client may also not indicate the behavior
   experienced by a different port, as described inSection 4.1.

   Definitions for NAT filtering and mapping behaviour are from
   [RFC4787].  The tests described here are for UDP connectivity, NAT
   mapping behaviour, NAT filtering behaviour, and NAT binding lifetime
   discovery; additional tests could be designed using this usage's

MacDonald & Lowekamp     Expires March 31, 2010                [Page 12]
Internet-Draft           NAT Behavior Discovery           September 2009

   mechanisms.  The tests described below include only tests that can be
   performed using a client with a single IP address.  A client with
   multiple IP addresses (or multiple clients collaborating) behind the
   same NAT can combine their probes to test additional aspects of NAT
   behavior, such as port overloading.  This section provides a
   descriptive overview of how the primitives provided by the STUN
   attributes in this specification may be used to perform behavior
   tests.

   Normative specifications for the attributes are defined in later
   sections.

4.1.  Source Port Selection

   Proper source port selection is important to ensuring the usefulness
   and accuracy of the Behavior Discovery tests.  There are two
   preconditions for tests:

   o  Because mapping behavior can vary on a port-by-port basis, an
      application should perform its tests using the source port
      intended for use by the application whenever possible.  If it
      intends to use multiple source ports, it should repeat these tests
      for each source port.  Such tests should be performed sequentially
      to reduce load on the NAT.

   o  Because the results of some diagnostic checks depend on previous
      state in the NAT created by prior traffic, the tests should be
      performed using a source port that has not generated recent
      traffic.  Therefore the application should use a random source
      port or ensure that no traffic has previously occurred on the
      selected port prior to performing tests, generally by allocating a
      port and holding it unused for at least 15 minutes prior to the
      tests.

   Ensuring both of these preconditions can be challenging, particularly
   for a device or application wishing to perform Behavior Discovery
   tests at startup.  The following guidelines are suggested for
   reducing the likelihood of problems:

   o  An application intended to operate behind a NAT should not attempt
      to allocate a specific or well-known port.  Because such software
      must be designed to interoperate using whatever port is mapped to
      it by the NAT, the specific port is unnecessary.  Instead, on
      startup a random port should be selected (see below for
      recommended ranges).  An application, particularly on an embedded
      device, should not rely on the host operating system to select the
      next available port, because that might result in the application
      receiving the same port on each restart.  An application using the

MacDonald & Lowekamp     Expires March 31, 2010                [Page 13]
Internet-Draft           NAT Behavior Discovery           September 2009

      same port between restarts may not receive accurate results from
      Behavior Discovery tests that are intended to test state-related
      behavior of NATs, such as filtering and binding lifetime.

   o  An application requiring multiple ports, such as separate ports
      for control and media, should allocate those ports on startup when
      possible.  Even if there is no immediate need for media flow, if
      Behavior Discovery tests will be run on those ports, allocating
      them early will allow them to be left idle, increasing the chance
      of obtaining accurate results from Behavior Discovery tests.

   o  Although the most reliable results are obtained when performing
      tests with the specific ports that the application will use, in
      many cases an application will need to allocate and use ports
      without being able to perform complete Behavior Discovery tests on
      those ports.  In those cases, an application should randomly
      select its ports from a range likely to receive the same treatment
      by the NAT.  This document recommends ranges of 32768-49151, which
      is the upper end of IANA's Registered Ports range, and 49152-
      65535, which is IANA's Dynamic and/or Private port range, for
      random selection.  To attempt to characterize a NAT's general
      treatment of ports in these ranges, a small number of ports within
      a range can be randomly selected and characterized.

   Those tests particularly sensistive to prior state on a NAT will be
   indicated below.

4.2.  Checking for UDP Connectivity with the STUN Server

   The client sends a STUN Binding Request to a server.  This causes the
   server to send the response back to the address and port that the
   request came from.  If this test yields no response, the client knows
   right away that it does not have UDP connectivity with the STUN
   server.  This test requires only STUN [RFC5389] functionality.

4.3.  Determining NAT Mapping Behavior

   This will require at most three tests.  In test I, the client
   performs the UDP connectivity test.  The server will return its
   alternate address and port in OTHER-ADDRESS in the binding response.
   If OTHER-ADDRESS is not returned, the server does not support this
   usage and this test cannot be run.  The client examines the XOR-
   MAPPED-ADDRESS attribute.  If this address and port are the same as
   the local IP address and port of the socket used to send the request,
   the client knows that it is not NATed and the effective mapping will
   be Endpoint-Independent.

   In test II, the client sends a Binding Request to the alternate

MacDonald & Lowekamp     Expires March 31, 2010                [Page 14]
Internet-Draft           NAT Behavior Discovery           September 2009

   address, but primary port.  If the XOR-MAPPED-ADDRESS in the Binding
   Response is the same as test I the NAT currently has Endpoint-
   Independent Mapping.  If not, test III is performed: the client sends
   a Binding Request to the alternate address and port.  If the XOR-
   MAPPED-ADDRESS matches test II, the NAT currently has Address-
   Dependent Mapping; if it doesn't match it currently has Address and
   Port-Dependent Mapping.

4.4.  Determining NAT Filtering Behavior

   This will also require at most three tests.  These tests are
   sensitive to prior state on the NAT.

   In test I, the client performs the UDP connectivity test.  The server
   will return its alternate address and port in OTHER-ADDRESS in the
   binding response.  If OTHER-ADDRESS is not returned, the server does
   not support this usage and this test cannot be run.

   In test II, the client sends a binding request to the primary address
   of the server with the CHANGE-REQUEST attribute set to change-port
   and change-IP.  This will cause the server to send its response from
   its alternate IP address and alternate port.  If the client receives
   a response the current behaviour of the NAT is Endpoint-Independent
   Filtering.

   If no response is received, test III must be performed to distinguish
   between Address-Dependent Filtering and Address and Port-Dependent
   Filtering.  In test III, the client sends a binding request to the
   original server address with CHANGE-REQUEST set to change-port.  If
   the client receives a response the current behaviour is Address-
   Dependent Filtering; if no response is received the current behaviour
   is Address and Port-Dependent Filtering.

4.5.  Combining and Ordering Tests

   Clients may wish to combine and parallelize these tests to reduce the
   number of packets sent and speed the discovery process.  For example,
   test I of the filtering and mapping tests also checks if UDP is
   blocked.  Furthermore, an application or user may not need as much
   detail as these sample tests provide.  For example, establishing
   connectivity between nodes becomes significantly more difficult if a
   NAT has any behavior other than endpoint-independent mapping, which
   requires only test I and II of Section 4.3.  An application
   determining its NAT does not always provide independent mapping might
   notify the user if no relay is configured, whereas an application
   behind a NAT that provides endpoint-independent mapping might not
   notify the user until a subsequent connection actually fails or might
   provide a less urgent notification that no relay is configured.  Such

MacDonald & Lowekamp     Expires March 31, 2010                [Page 15]
Internet-Draft           NAT Behavior Discovery           September 2009

   a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but
   it does provide some information regarding whether ICE is likely to
   be successful establishing non-relayed connections.

   Care must be taken when combining and parallelizing tests, due to the
   sensitivity of certain tests to prior state on the NAT and because
   some NAT devices have an upper limit on how quickly bindings will be
   allocated.  Section 5 restricts the rate at which clients may begin
   new STUN transactions.

4.6.  Binding Lifetime Discovery

   STUN can also be used to probe the lifetimes of the bindings created
   by the NAT.  Such tests are sensitive to prior state on the NAT.  For
   many NAT devices, an absolute refresh interval cannot be determined;
   bindings might be closed quicker under heavy load or might not behave
   as the tests suggest.  For this reason applications that require
   reliable bindings must send keep-alives as frequently as required by
   all NAT devices that will be encountered.  Suggested refresh
   intervals are outside the scope of this document.  ICE
   [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have
   suggested refresh intervals.

   Determining the binding lifetime relies on two separate source ports
   being used to send STUN Binding Requests to the STUN server.  The
   general approach is that the client uses a source port X to send a
   single Binding Request.  After a period of time during which source
   port X is not used, the client uses a second source port Y to send a
   Binding Request to the STUN server that indicates the response should
   be sent to the binding established to port X. If the binding for port
   X has timed out, that response will not be received.  By varying the
   time between the original Binding Request sent from X and the
   subsequent request sent from Y, the client can determine the binding
   lifetime.

   To determine the binding lifetime, the client first sends a Binding
   Request to the server from a particular source port, X. This creates
   a binding in the NAT.  The response from the server contains a
   MAPPED-ADDRESS attribute, providing the public address and port on
   the NAT.  Call this Pa and Pp, respectively.  The client then starts
   a timer with a value of T seconds.  When this timer fires, the client
   sends another Binding Request to the server, using the same
   destination address and port, but from a different source port, Y.
   This request contains an RESPONSE-PORT attribute, set to Pp, to
   request the response be delivered to (Pa,Pp).  This will create a new
   binding on the NAT, and cause the STUN server to send a Binding
   Response that would match the old binding, (Pa,Pp), if it still
   exists.  If the client receives the Binding Response on port X, it

MacDonald & Lowekamp     Expires March 31, 2010                [Page 16]
Internet-Draft           NAT Behavior Discovery           September 2009

   knows that the binding has not expired.  If the client receives the
   Binding Response on port Y (which is possible if the old binding
   expired, and the NAT allocated the same public address and port to
   the new binding), or receives no response at all, it knows that the
   binding has expired.

   Because some NATs only refresh bindings when outbound traffic is
   sent, the client must resend a binding request from the original
   source port before beginning a second test with a different value of
   T. The client can find the value of the binding lifetime by doing a
   binary search through T, arriving eventually at the value where the
   response is not received for any timer greater than T, but is
   received for any timer less than T. Note also that the binding
   refresh behavior (outbound only or all traffic) can be determined by
   sending multiple Binding Requests from port Y without refreshes from
   the original source port X.

   This discovery process takes quite a bit of time and is something
   that will typically be run in the background on a device once it
   boots.

   It is possible that the client can get inconsistent results each time
   this process is run.  For example, if the NAT should reboot, or be
   reset for some reason, the process may discover a lifetime than is
   shorter than the actual one.  Binding lifetime may also be dependent
   on the traffic load on the NAT.  For this reason, implementations are
   encouraged to run the test numerous times and be prepared to get
   inconsistent results.

   Like the other diagnostics, this test is inherently unstable.  In
   particular, an overloaded NAT might reduce binding lifetime to shed
   load.  A client might find this diagnostic useful at startup, for
   example setting the initial keepalive interval on its connection to
   the server to 10 seconds while beginning this check.  After
   determining the current lifetime, the keepalive interval used by the
   connection to the server can be set to this appropriate value.
   Subsequent checks of the binding lifetime can then be performed using
   the keepalives in the server connection.  The STUN Keepalive Usage
   [I-D.ietf-sip-outbound] provides a response that confirms the
   connection is open and allows the client to check that its mapped
   address has not changed.  As that provides both the keepalive action
   and diagnostic that it is working, it should be preferred over any
   attempt to characterize the connection by a secondary technique.

5.  Client Behavior

   Unless otherwise specified here, all procedures for preparing,

MacDonald & Lowekamp     Expires March 31, 2010                [Page 17]
Internet-Draft           NAT Behavior Discovery           September 2009

   sending, and processing messages as described in the STUN Binding
   Usage [RFC5389] are followed.

   As support for RESPONSE-PORT is optional a client MUST be prepared to
   receive a 420 (Unknown Attribute) error to requests that include
   RESPONSE-PORT.  Support for OTHER-ADDRESS and CHANGE-REQUEST is
   optional, but MUST be supported by servers advertised via SRV, as
   described below.  This is to allow the use of PADDING and RESPONSE-
   PORT in applications where servers do not have multiple IP addresses.
   Clients MUST be prepared to receive a 420 for requests that include
   CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding
   Response messages from the server.

   If an application makes use of the NAT Behavior Discovery STUN usage
   by multiplexing it in a flow with application traffic, a FINGERPRINT
   attribute SHOULD be included unless it is always possible to
   distinguish a STUN message from an application message based on their
   header.

   When PADDING is used, it SHOULD be equal to the MTU of the outgoing
   interface.

   Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
   unless they are using authentication with a provider of STUN servers
   that is aware of the topology requirements of the tests being
   performed.

   A client SHOULD NOT generate more than ten new STUN transactions per
   second and SHOULD pace them such that the RTOs do not synchronize the
   retransmissions of each transaction.

5.1.  Discovery

   Unless the user or application is aware of the transport address of a
   STUN server supporting the NAT Behavior Discovery usage through other
   means, a client is configured with the domain name of the provider of
   the STUN servers.  The domain is resolved to a transport address
   using SRV procedures [RFC2782].  The mechanism for configuring the
   client with the domain name of the STUN servers or of acquiring a
   specific transport address is out of scope for this document.

   For the Behavior Discovery Usage the service name is "stun-behavior"
   for UDP and TCP.  The service name is "stun-behaviors" for TLS over
   TCP.  Only "tcp" is defined as a protocol for "stun-behaviors".
   Other aspects of handling failures and default ports are followed as
   described in STUN [RFC5389].

MacDonald & Lowekamp     Expires March 31, 2010                [Page 18]
Internet-Draft           NAT Behavior Discovery           September 2009

5.2.  Security

   Servers MAY require authentication before allowing a client to make
   use of its services.  The method for obtaining these credentials,
   should the server require them, is outside the scope of this usage.
   Presumably, the administrator or application relying on this usage
   should have its own method for obtaining credentials.  If the client
   receives a 401 (Unauthorized) Response to a Request, then it must
   either acquire the appropriate credential from the application before
   retrying or report a permanent failure.  Procedures for encoding the
   MESSAGE-INTEGRITY attribute for a request are described in STUN
   [RFC5389].

6.  Server Behavior

   Unless otherwise specified here, all procedures for preparing,
   sending, and processing messages as described for the STUN Binding
   Usage of STUN [RFC5389] are followed.

   A server implementing the NAT Behavior Discovery usage SHOULD be
   configured with two separate IP addresses on the public Internet.  On
   startup, the server SHOULD allocate a pair of ports for each of the
   UDP, TCP, and TCP/TLS transport protocols, such that it can send and
   receive datagrams using the same ports on each IP address (normally a
   wildcard binding accomplishes this).  TCP and TCP/TLS MUST use
   different ports.  If a server cannot allocate the same ports on two
   different IP address, then it MUST NOT include an OTHER-ADDRESS
   attribute in any Response and MUST respond with a 420 (Unknown
   Attribute) to any Request with a CHANGE-REQUEST attribute.  A server
   with only one IP address MUST NOT be advertised using the SRV service
   name "stun-behavior" or "stun-behaviors".

6.1.  Preparing the Response

   After performing all authentication and verification steps the server
   begins processing specific to this Usage if the Request contains any
   request attributes defined in this document: RESPONSE-PORT, CHANGE-
   REQUEST, or PADDING.  If the Request does not contain any attributes
   from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are still
   included in the response.

   The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in
   its Response.

   If the Request contains CHANGE-REQUEST attribute and the server does
   not have an alternate address and port as described above, the server
   MUST generate an error response of type 420.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 19]
Internet-Draft           NAT Behavior Discovery           September 2009

   The source address and port of the Binding Response depend on the
   value of the CHANGE-REQUEST attribute and on the address and port the
   Binding Request was received on, and are summarized in Table 1.

   Let A1 and A2 be the two IP addresses used by the server and P1 and
   P2 be the ports used by the server.  Let Da represent the destination
   IP address of the Binding Request (which will be either A1 or A2),
   and Dp represent the destination port of the Binding Request (which
   will be either P1 or P2).  Let Ca represent the other address, so
   that if Da is A1, Ca is A2.  If Da is A2, Ca is A1.  Similarly, let
   Cp represent the other port, so that if Dp is P1, Cp is P2.  If Dp is
   P2, Cp is P1.  If the "change port" flag was set in CHANGE-REQUEST
   attribute of the Binding Request, and the "change IP" flag was not
   set, the source IP address of the Binding Response MUST be Da and the
   source port of the Binding Response MUST be Cp.  If the "change IP"
   flag was set in the Binding Request, and the "change port" flag was
   not set, the source IP address of the Binding Response MUST be Ca and
   the source port of the Binding Response MUST be Dp.  When both flags
   are set, the source IP address of the Binding Response MUST be Ca and
   the source port of the Binding Response MUST be Cp.  If neither flag
   is set, or if the CHANGE-REQUEST attribute is absent entirely, the
   source IP address of the Binding Response MUST be Da and the source
   port of the Binding Response MUST be Dp.

   +--------------------+----------------+-------------+---------------+
   | Flags              | Source Address | Source Port | OTHER-ADDRESS |
   +--------------------+----------------+-------------+---------------+
   | none               | Da             | Dp          | Ca:Cp         |
   | Change IP          | Ca             | Dp          | Ca:Cp         |
   | Change port        | Da             | Cp          | Ca:Cp         |
   | Change IP and      | Ca             | Cp          | Ca:Cp         |
   | Change port        |                |             |               |
   +--------------------+----------------+-------------+---------------+

        Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS

   The server MUST add a RESPONSE-ORIGIN attribute to the Binding
   Response, containing the source address and port used to send the
   Binding Response.

   If the server supports an alternate address and port the server MUST
   add an OTHER-ADDRESS attribute to the Binding Response.  This
   contains the source IP address and port that would be used if the
   client had set the "change IP" and "change port" flags in the Binding
   Request.  As summarized in Table 1, these are Ca and Cp,
   respectively, regardless of the value of the CHANGE-REQUEST flags.

   If the Request contained a PADDING attribute, PADDING MUST be

MacDonald & Lowekamp     Expires March 31, 2010                [Page 20]
Internet-Draft           NAT Behavior Discovery           September 2009

   included in the Binding Response.  The server SHOULD use a length of
   PADDING equal to the MTU on the outgoing interface, rounded up to an
   even multiple of four bytes.  If the Request also contains the
   RESPONSE-PORT attribute the server MUST return an error response of
   type 400.

   Following that, the server completes the remainder of the processing
   from STUN [RFC5389].  If authentication is being required, the server
   MUST include a MESSAGE-INTEGRITY and associated attributes as
   appropriate.  A FINGERPRINT attribute is only required if the STUN
   messages are being multiplexed with application traffic that requires
   use of a FINGERPRINT to distinguish STUN messages.

   An ALTERNATE-SERVER attribute MUST NOT be included with any other
   attribute defined in this specification.

   When the server sends the Response, it is sent from the source
   address as determined above and to the to the source address of the
   Request.  If RESPONSE-PORT is present the server sends the reponse to
   that port instead of the originating port.

7.  New Attributes

   This document defines several STUN attributes that are required for
   NAT Behavior Discovery.  These attributes are all used only with
   Binding Requests and Binding Responses.  CHANGE-REQUEST was
   originally defined in RFC3489 [RFC3489] but is redefined here as that
   document is obsoleted by [RFC5389].

     Comprehension-required range (0x0000-0x7FFF):
       0x0003: CHANGE-REQUEST
       0x0026: PADDING
       0x0027: RESPONSE-PORT

     Comprehension-optional range (0x8000-0xFFFF)
       0x802b: RESPONSE-ORIGIN
       0x802c: OTHER-ADDRESS

7.1.  Representing Transport Addresses

   Whenever an attribute contains a transport IP address and port, it
   has the same format as MAPPED-ADDRESS.  Similarly, the XOR-
   attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389].

MacDonald & Lowekamp     Expires March 31, 2010                [Page 21]
Internet-Draft           NAT Behavior Discovery           September 2009

7.2.  CHANGE-REQUEST

   The CHANGE-REQUEST attribute contains two flags to control the IP
   address and port the server uses to send the response.  These flags
   are called the "change IP" and "change port" flags.  The CHANGE-
   REQUEST attribute is allowed only in the Binding Request.  The
   "change IP" and "change port" flags are useful for determining the
   current filtering behavior of a NAT.  They instruct the server to
   send the Binding Responses from the alternate source IP address
   and/or alternate port.  The CHANGE-REQUEST attribute is optional in
   the Binding Request.

   The attribute is 32 bits long, although only two bits (A and B) are
   used:
    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 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The meanings of the flags are:

   A: This is the "change IP" flag.  If true, it requests the server to
      send the Binding Response with a different IP address than the one
      the Binding Request was received on.

   B: This is the "change port" flag.  If true, it requests the server
      to send the Binding Response with a different port than the one
      the Binding Request was received on.

7.3.  RESPONSE-ORIGIN

   The RESPONSE-ORIGIN attribute is inserted by the server and indicates
   the source IP address and port the response was sent from.  It is
   useful for detecting double NAT configurations.  It is only present
   in Binding Responses.

7.4.  OTHER-ADDRESS

   The OTHER-ADDRESS attribute is used in Binding Responses.  It informs
   the client of the source IP address and port that would be used if
   the client requested the "change IP" and "change port" behavior.
   OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the
   server has a second IP address.

   OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
   RFC3489 [RFC3489]because it is simply a new name with the same
   semantics as CHANGED-ADDRESS.  It has been renamed to more clearly

MacDonald & Lowekamp     Expires March 31, 2010                [Page 22]
Internet-Draft           NAT Behavior Discovery           September 2009

   indicate its function.

7.5.  RESPONSE-PORT

   The REPONSE-PORT attribute contains a port.  The RESPONSE-PORT
   attribute can be present in the Binding Request and indicates which
   port the Binding Response will be sent to.  For servers which support
   the RESPONSE-PORT attribute, the Binding Response MUST be transmited
   to the source IP address of the Binding Request and the port
   contained in RESPONSE-PORT.  It is used in tests such as Section 4.6.
   When not present, the server sends the Binding Response to the source
   IP address and port of the Binding Request.  The server MUST NOT
   process a request containing a RESPONSE-PORT and a PADDING attribute.
   The RESPONSE-PORT attribute is optional in the Binding Request.
   Server support for RESPONSE-PORT is optional.

   RESPONSE-PORT is a 16 bit unsigned integer in network byte order
   followed by 2 bytes of padding.  Allowable values of RESPONSE-PORT
   are 0-65536.

7.6.  PADDING

   The PADDING attribute allows for the entire message to be padded to
   force the STUN message to be divided into IP fragments.  PADDING
   consists entirely of a freeform string, the value of which does not
   matter.  PADDING can be used in either Binding Requests or Binding
   Responses.

   PADDING MUST NOT be longer than the length that brings the total IP
   datagram size to 64K. It SHOULD be equal in length to the MTU of the
   outgoing interface, rounded up to an even multiple of four bytes.
   Because STUN messages with PADDING are intended to test the behavior
   of UDP fragments, they are an exception to the usual rule that STUN
   messages be less than the MTU of the path.

8.  IAB Considerations

   The IAB has studied the problem of ``Unilateral Self Address
   Fixing'', which is the general process by which a client attempts to
   determine its address in another realm on the other side of a NAT
   through a collaborative protocol reflection mechanism RFC 3424
   [RFC3424].  The STUN NAT Behavior Discovery usage is an example of a
   protocol that performs this type of function.  The IAB has mandated
   that any protocols developed for this purpose document a specific set
   of considerations.  This section meets those requirements.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 23]
Internet-Draft           NAT Behavior Discovery           September 2009

8.1.  Problem Definition

   From RFC 3424 [RFC3424], any UNSAF proposal must provide:

      Precise definition of a specific, limited-scope problem that is to
      be solved with the UNSAF proposal.  A short term fix should not be
      generalized to solve other problems; this is why "short term fixes
      usually aren't".

   The specific problem being solved by the STUN NAT Behavior Discovery
   usage is for a client, which may be located behind a NAT of any type,
   to determine the instantaneous characteristics of that NAT in order
   to either diagnose the cause of problems experienced by that or other
   applications or for an application to modify its behavior based on
   the current behavior of the NAT and an appropriate statistical model
   of the behavior required for the application to succeed.

8.2.  Exit Strategy

   From [RFC3424], any UNSAF proposal must provide:

      Description of an exit strategy/transition plan.  The better short
      term fixes are the ones that will naturally see less and less use
      as the appropriate technology is deployed.

   The STUN NAT Behavior Discovery usage does not itself provide an exit
   strategy for v4 NATs.  At the time of this writing, it appears some
   sort of NAT will be necessary between v6 clients and v4 servers, but
   this specification will not be necessary with those v6 to v4 NATs,
   because the IETF is planning to adequately describe their operation.
   This specification will be of no interest for v6 to v6 connectivity.

8.3.  Brittleness Introduced by STUN NAT Behavior Discovery

   From [RFC3424], any UNSAF proposal must provide:

      Discussion of specific issues that may render systems more
      "brittle".  For example, approaches that involve using data at
      multiple network layers create more dependencies, increase
      debugging challenges, and make it harder to transition.

   The STUN NAT Behavior Discovery usage allows a client to determine
   the current behavior of a NAT.  This information can be quite useful
   to a developer or network administrator outside of an application,
   and as such can be used to diagnose the brittleness induced in
   another application.  When used within an application itself, STUN
   NAT Behavior Discovery allows the application to adjust its behavior
   according to the current behavior of the NAT.  This draft is

MacDonald & Lowekamp     Expires March 31, 2010                [Page 24]
Internet-Draft           NAT Behavior Discovery           September 2009

   experimental because the extent to which brittleness is introduced to
   an application relying on the Behavior Discovery usage is unclear and
   must be carefully evaluated by the designers of the protocol making
   use of it.  The experimental test for this protocol is essentially
   determining whether an application can be made less brittle through
   the use of behavior-discovery information than it would be if
   attempted to make use of the network without any awareness of the
   NATs its traffic must pass through.

8.4.  Requirements for a Long Term Solution

   From [RFC3424], any UNSAF proposal must provide:

      Identify requirements for longer term, sound technical solutions
      -- contribute to the process of finding the right longer term
      solution.

   As long as v4 NATs are present, means of adapting to their presence
   will be required.  As described above, well-behaved v6 to v4 NATs and
   direct v6 to v6 connections will not require behavior
   characterization.

8.5.  Issues with Existing NAPT Boxes

   From [RFC3424], any UNSAF proposal must provide:

      Discussion of the impact of the noted practical issues with
      existing, deployed NA[P]Ts and experience reports.

   This usage provides a set of generic attributes that can be assembled
   to test many types of NAT behavior.  While tests for the most
   commonly known NAT box behaviors are described, the BEHAVE mailing
   list regularly has descriptions of new behaviors, some of which may
   not be readily detected using the tests described herein.  However,
   the techniques described in this usage can be assembled in different
   combinations to test NAT behaviors not now known or envisioned.

9.  IANA Considerations

   This specification requests that IANA make additions to the "STUN
   Attributes Registry" and "STUN Error Code Registry".

9.1.  STUN Attribute Registry

   This specification defines several new STUN attributes.  This section
   directs IANA to add these new protocol elements to the IANA registry
   of STUN protocol elements.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 25]
Internet-Draft           NAT Behavior Discovery           September 2009

   0x0003: CHANGE-REQUEST
   0x0027: RESPONSE-PORT
   0x0026: PADDING
   0x8027: CACHE-TIMEOUT
   0x802b: RESPONSE-ORIGIN
   0x802c: OTHER-ADDRESS

9.2.  SRV Registry

   This specification defines the "stun-behavior" and "stun-behaviors"
   SRV service names. "stun-behavior" may be used with SRV protocol
   specifiers "udp" and "tcp". "stun-behaviors" may only be specified
   with "tcp".  Thus, the allowable SRV queries are:
   _stun-behavior._udp            UDP
   _stun-behavior._tcp            TCP
   _stun-behaviors._tcp           TLS over TCP

10.  Security Considerations

   This usage inherits the security considerations of STUN [RFC5389].
   This usage adds several new attributes; security considerations for
   those are detailed here.

   OTHER-ADDRESS does not permit any new attacks; it provides another
   place where an attacker can impersonate a STUN server but it is not
   an interesting attack.  An attacker positioned where it can
   compromise the Binding Response can completely hide the STUN server
   from the client.

   o  Requests containing both RESPONSE-PORT and PADDING are rejected by
      the server.  This prevents an amplification attack which is
      targeted at the originating address.

   The only attack possible with the PADDING attribute is to have a
   large padding length which could cause a server to allocate a large
   amount of memory.  As servers will ignore any padding length greater
   than 64k so the scope of this attack is limited.  In general, servers
   should not allocate more memory than the size of the received
   datagram.  This attack would only affect non-compliant
   implementations.

   RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional
   attacks.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 26]
Internet-Draft           NAT Behavior Discovery           September 2009

11.  Acknowledgements

   The authors would like to thank the authors of the original STUN
   specification [RFC3489] from which many of the ideas, attributes, and
   description in this document originated.  Thanks to Dan Wing, Cullen
   Jennings, and Magnus Westerlund for detailed comments.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              February 2000.

   [RFC4787]  Audet, F. and C. Jennings, "Network Address Translation
              (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
              RFC 4787, January 2007.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

12.2.  Informative References

   [I-D.ietf-mmusic-ice]
              Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address  Translator (NAT)
              Traversal for Offer/Answer Protocols",
              draft-ietf-mmusic-ice-19 (work in progress), October 2007.

   [I-D.ietf-sip-outbound]
              Jennings, C., "Managing Client Initiated Connections in
              the Session Initiation Protocol  (SIP)",
              draft-ietf-sip-outbound-20 (work in progress), June 2009.

   [RFC3424]  Daigle, L. and IAB, "IAB Considerations for UNilateral
              Self-Address Fixing (UNSAF) Across Network Address
              Translation", RFC 3424, November 2002.

   [RFC3489]  Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
              "STUN - Simple Traversal of User Datagram Protocol (UDP)
              Through Network Address Translators (NATs)", RFC 3489,
              March 2003.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 27]
Internet-Draft           NAT Behavior Discovery           September 2009

Appendix A.  Change Log

   RFC-EDITOR: Please remove this entire Change Log section while
   formatting this document for publication.

A.1.  from draft-macdonald-behave-nat-behavior-diagnostics-00

   o  Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET
      support is optional; support for PADDING and SOURCE-ADDRESS is now
      mandatory

   o  PADDING is now a mandatory attribute

   o  OTHER-ADDRESS is returned in all binding responses if the server
      has a second IP address

A.2.  from draft-ietf-behave-nat-behavior-discovery-00

   o  Clarified that only servers with two IP addresses should have an
      SRV entry

   o  Removed support for backward compatibility with 3489 clients by
      removing non-XOR forms of attributes.  Language states that
      backward compatibility with 3489 clients is SHOULD NOT.
      Compatibility with 3489 servers is left unspecified.

   o  PADDING is mandatory and language has been changed to indicate
      that if a server supports PADDING it must either actually provide
      the padding or return an error (can't support it but refuse to do
      it)

   o  Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned
      to support detection of generic ALGs

A.3.  from draft-ietf-behave-nat-behavior-discovery-01

   o  Changed proposed status to experimental

   o  Made significant changes to the introduction and applicability
      statements to reflect the experimental status

   o  Fixed the New Attributes and IANA considerations not listing the
      same attribute numbers.

   o  Removed mandatory shared secret credentials in favor of the option
      of rate limiting or credentials.  Specified that credentials must
      be obtained from the user or parent application.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 28]
Internet-Draft           NAT Behavior Discovery           September 2009

   o  Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address
      compatibility with 3489bis clients.  Renamed SOURCE-ADDRESS as
      RESPONSE-ORIGIN to avoid conflicts with 3489.

   o  Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET

   o  Added discussion of FINGERPRINT and ALTERNATE-SERVER for
      compliance with 3489bis stun usage definition requirements.

A.4.  from draft-ietf-behave-nat-behavior-discovery-02

   o  fix terminology for endpoint-independent, address-dependent, and
      address and port-dependent from rfc4787

   o  define the ALG detection to apply to UDP and TCP

   o  fix >From typo in 9.5

   o  added exception to single MTU size restriction for PADDING

   o  removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the
      belief that we need to list that definition here now that 3489bis
      is dropping it.

A.5.  from draft-ietf-behave-nat-behavior-discovery-03

   o  moved semantics of PADDING usage into behavior sections rather
      than attributes section

   o  removed reference to SERVER attribute

   o  removed Open Issues section

   o  Updated IAB considerations

A.6.  from draft-ietf-behave-nat-behavior-discovery-04

   o  Clarified that behavior may vary by port used as well as by
      destination IP/particular STUN server, and therefore specified
      that all tests should be performed using the port the application
      will use

   o  Added additional text on selecting random port/ensuring port has
      been unused prior to starting filtering tests

   o  specified limit to start rate of tests and that tests
      retransmissions should not synchronize

MacDonald & Lowekamp     Expires March 31, 2010                [Page 29]
Internet-Draft           NAT Behavior Discovery           September 2009

   o  additional explanatory text for XOR-RESPONSE-TARGET

   o  added SRV entry to IANA section and subdivided to match STUN
      registries from 5389

   o  clarified that test combinations are non-normative

   o  Numerous clarifications

   o  Changed PADDING to default to interface MTU, and changed maximum
      length to not make IP datagram exceed 64K

   o  Added text that server should allocate TCP and TCP/TLS

A.7.  from draft-ietf-behave-nat-behavior-discovery-05

   o  In applicability section, add explicit requirement that citing
      drafts must specify how they handle failure

   o  Add new subsection on selecting the source port used for tests,
      covering both requirements that the same port be used for tests as
      for the application and dependencies on previous bindings.
      Reference that section explicitly for tests that are sensitive to
      previous binding state.

   o  Change SRV discovery to stun-behavior for UDP and TCP and stun-
      behaviors for TLS/TCP.

   o  Add SRV registry subsection to IANA section.

A.8.  from draft-ietf-behave-nat-behavior-discovery-06

   o  Reworked the applicability section and provided more detail in the
      P2P application example

   o  Additional clarification on the limits of the tests, and that the
      described tests include only those utilizing a single source IP,
      so can't test overloading.

   o  Several changes to clarify and make consistent security
      requirements for XOR-RESPONSE-TARGET

   o  Numerous other clarifications in response to comments.

MacDonald & Lowekamp     Expires March 31, 2010                [Page 30]
Internet-Draft           NAT Behavior Discovery           September 2009

A.9.  from draft-ietf-behave-nat-behavior-discovery-07

   o  Changed XOR-RESPONSE-ADDRESS to RESPONSE-PORT which resulted in
      CACHE-TIMEOUT and XOR-REFLECTED-FROM.  This resulted in a
      simplification of the Security Considerations

   o  Fixed erroneous STUN expansions

   o  Clarification of when a fallback mechanism will be used.

   o  Numerous other clarifications in response to comments.

Authors' Addresses

   Derek C. MacDonald
   CounterPath Solutions, Inc.
   Suite 300, One Bentall Centre, 505 Burrard St
   Vancouver, BC  V7X1M3
   Canada

   Phone: +1-604-320-3344
   Email: derek.macdonald@gmail.com

   Bruce B. Lowekamp
   MYMIC LLC
   1040 University Blvd., Suite 100
   Portsmouth, VA  23703
   USA

   Email: bbl@lowekamp.net

MacDonald & Lowekamp     Expires March 31, 2010                [Page 31]