draft-ietf-behave-nat-behavior-discovery-04.txt   draft-ietf-behave-nat-behavior-discovery-05.txt 
BEHAVE D. MacDonald BEHAVE D. MacDonald
Internet-Draft CounterPath Solutions, Inc. Internet-Draft CounterPath Solutions, Inc.
Intended status: Experimental B. Lowekamp Intended status: Experimental B. Lowekamp
Expires: January 30, 2009 SIPeerior Technologies, Inc. Expires: May 7, 2009 SIPeerior Technologies
July 29, 2008 November 3, 2008
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-04 draft-ietf-behave-nat-behavior-discovery-05
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 30, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This specification defines an experimental usage of the Simple This specification defines an experimental usage of the Simple
Traversal Underneath Network Address Translators (NAT) (STUN) Traversal Underneath Network Address Translators (NAT) (STUN)
Protocol that discovers the presence and current behaviour of NATs Protocol that discovers the presence and current behaviour of NATs
and firewalls between the STUN client and the STUN server. and firewalls between the STUN client and the STUN server.
Requirements Language Requirements Language
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 8 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 8
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 8 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 8
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 8 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 8
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 9 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 9
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 9 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 9
3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 9 3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 9
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 9 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 9
4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 10 4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 10
4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 10 4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 10
4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 10 4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 11
4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11 4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11
4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11 4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 12
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 14 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 16
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 17 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Representing Transport Addresses . . . . . . . . . . . . . 17 7.1. Representing Transport Addresses . . . . . . . . . . . . . 19
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 18 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 19
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 18 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 20
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 18 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 20
7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 19 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 20
7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 19 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 20
7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 20 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 21
8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 20 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 21
8.1. 481 Connection does not exist . . . . . . . . . . . . . . 20 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 21
8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 20 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 22
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 22
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22
9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 21 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 23
9.4. Requirements for a Long Term Solution . . . . . . . . . . 22 9.4. Requirements for a Long Term Solution . . . . . . . . . . 23
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 22 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 10.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 24
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 10.2. STUN Error Code Registry . . . . . . . . . . . . . . . . . 24
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . . 25 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 26
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 26
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 27
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 26 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 27
A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 27 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 28
Intellectual Property and Copyright Statements . . . . . . . . . . 28 A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 28
A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29
Intellectual Property and Copyright Statements . . . . . . . . . . 30
1. Applicability 1. Applicability
This experimental STUN usage does not allow an application behind a This experimental STUN usage does not allow an application behind a
NAT to make an absolute determination of the NAT's characteristics. NAT to make an absolute determination of the NAT's characteristics.
NAT devices do not behave consistently enough to predict future NAT devices do not behave consistently enough to predict future
behaviour with any guarantee. This STUN usage provides information behaviour with any guarantee. This STUN usage provides information
about observable transient behavior; it only truly determines a NAT's about observable transient behavior; it only truly determines a NAT's
behavior with regard to the STUN server used at the instant the test behavior with regard to the STUN server used and the particular ports
is run. Applications requiring reliable reach between two particular used at the instant the test is run. Applications requiring reliable
endpoints must establish a communication channel through a NAT using reach between two particular endpoints must establish a communication
another technique. IETF has proposed standards including ICE channel through a NAT using another technique. IETF has proposed
[I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for standards including ICE [I-D.ietf-mmusic-ice] and OUTBOUND
establishing communication channels when a publicly accessible [I-D.ietf-sip-outbound] for establishing communication channels when
rendezvous service is available. a publicly accessible rendezvous service is available.
This usage provides techniques which are powerful diagnostic tools in This usage provides techniques which are powerful diagnostic tools in
the hands of a network administrator or system programmer trying to the hands of a network administrator or system programmer trying to
determine the causes of network failure; particularly when behavior determine the causes of network failure; particularly when behavior
varies by load, destination, or other factors that may be related to varies by load, destination, or other factors that may be related to
NAT behavior. NAT behavior.
This draft also proposes experimental applications of NAT Behavior This draft also proposes experimental applications of NAT Behavior
Discovery STUN for real-time selection of parameters for protocols in Discovery STUN for real-time selection of parameters for protocols in
situations where a publicly accessible rendezvous service is not situations where a publicly accessible rendezvous service is not
skipping to change at page 5, line 7 skipping to change at page 5, line 7
usage makes an explicit statement that it is not, and cannot be, usage makes an explicit statement that it is not, and cannot be,
correct 100% of the time, but is still very useful. It is submitted correct 100% of the time, but is still very useful. It is submitted
to the Internet community as an experimental protocol that, when to the Internet community as an experimental protocol that, when
applied with appropriate statistical underpinnings and application applied with appropriate statistical underpinnings and application
behavior that is ultimately based on experienced connectivity behavior that is ultimately based on experienced connectivity
patterns, can lead to more stability and increased performance than patterns, can lead to more stability and increased performance than
is available without the knowledge it provides. is available without the knowledge it provides.
2. Introduction 2. Introduction
The Simple Traversal Underneath Network Address Translators (NAT) The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a
(STUN) [I-D.ietf-behave-rfc3489bis] provides a mechanism to discover mechanism to discover the reflexive transport address toward the STUN
the reflexive transport address toward the STUN server, using the server, using the Binding Request. This specification defines the
Binding Request. This specification defines the NAT Behavior NAT Behavior Discovery STUN usage, which allows a STUN client to
Discovery STUN usage, which allows a STUN client to probe the current probe the current behaviour of the NAT/FW devices between the client
behaviour of the NAT/FW devices between the client and the STUN and the STUN server. This usage defines new STUN attributes for the
server. This usage defines new STUN attributes for the Binding Binding Request and Binding Response.
Request and Binding Response.
Many NAT/FW devices do not behave consistently and will change their Many NAT/FW devices do not behave consistently and will change their
behaviour under load and over time. Applications requiring high behaviour under load and over time. Applications requiring high
reliability must be prepared for the NAT's behaviour to become more reliability must be prepared for the NAT's behaviour to become more
restrictive. Specifically, it has been found that under load NATs restrictive. Specifically, it has been found that under load NATs
may transition to the most restrictive filtering and mapping may transition to the most restrictive filtering and mapping
behaviour and shorten the lifetime of new and existing bindings. In behaviour and shorten the lifetime of new and existing bindings. In
short, applications can discover how bad things currently are, but short, applications can discover how bad things currently are, but
not how bad things will get. not how bad things will get.
skipping to change at page 6, line 9 skipping to change at page 6, line 8
potential to itself change the behavior of a NAT and potential to itself change the behavior of a NAT and
o the user must be careful to select a STUN server that is o the user must be careful to select a STUN server that is
appropriately located, ideally collocated (or even integrated) appropriately located, ideally collocated (or even integrated)
with the communication partners of the application in question, with the communication partners of the application in question,
for the results to be applicable to the network conditions for the results to be applicable to the network conditions
experienced by the application. experienced by the application.
2.2. Example Use with P2P Overlays 2.2. Example Use with P2P Overlays
An application could use Behavior Discovery in a P2P protocol to An application could use Behavior Discovery in a Peer-to-Peer (P2P)
determine if a particular endpoint is a reasonable candidate to protocol to determine if a particular endpoint is a reasonable
participate as a peer or supernode (defined here as a peer in the candidate to participate as a peer or supernode (defined here as a
overlay that offers services, including message routing, to other peer in the overlay that offers services, including message routing,
members or clients of the overlay network). This P2P network to other members or clients of the overlay network). This P2P
application is willing to select supernodes that might be located network application is willing to select supernodes that might be
behind NATs to avoid the cost of dedicated servers. A supernode located behind NATs to avoid the cost of dedicated servers. A
candidate requires that its NAT(s) offer(s) Endpoint-Independent supernode candidate requires that its NAT(s) offer(s) Endpoint-
Filtering. It might periodically re-run tests and would remove Independent Filtering. It might periodically re-run tests and would
itself as a supernode if its NAT/FW chain lost this characteristic. remove itself as a supernode if its NAT/FW chain lost this
These tests could be run with other supernodes acting as STUN servers characteristic. These tests could be run with other supernodes
as well as with dedicated STUN servers. As many P2P algorithms acting as STUN servers as well as with dedicated STUN servers. As
tolerate non-transitive connectivity between a portion of their many P2P algorithms tolerate non-transitive connectivity between a
peers, guaranteed pair-wise reliable reach might be sacrificed in portion of their peers, guaranteed pair-wise reliable reach might be
order to distribute the P2P overlay's load across peers that can be sacrificed in order to distribute the P2P overlay's load across peers
directly contacted by the majority of users. that can be directly contacted by the majority of users.
Use of Behavior Discovery for such an application requires: Use of Behavior Discovery for such an application requires:
o Specification of protocols capable of offering reliable end-user o Specification of protocols capable of offering reliable end-user
performance using unreliable links between peers. performance using unreliable links between peers.
o The application is deployed behind NATs that provide Endpoint- o The application is deployed behind NATs that provide Endpoint-
Independent Filtering and that remain in this mode for an amount Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior, of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and distribute this information to the rest of the overlay, and
provide useful work for the application. provide useful work for the application.
This draft is experimental as deployed applications implementing open This draft is experimental as deployed applications implementing open
protocols have yet to be deployed in such environments to demonstrate protocols have yet to be deployed in such environments to demonstrate
that these two requirements have been met. However, apocryphal that these two requirements have been met. However, apocryphal
evidence suggests that household- and small business-targeted NAT evidence suggests that NATs targeted at households and small
devices have stable behaviour, especially when there are few clients businesses have stable behaviour, especially when there are few
behind them. Numerous P2P applications have been deployed that clients behind them. Numerous P2P applications have been deployed
appear to have these properties, although their protocols have not that appear to have these properties, although their protocols have
yet been subjected to rigorous evaluation by standards bodies. not yet been subjected to rigorous evaluation by standards bodies.
2.3. Experimental Success 2.3. Experimental Success
The criteria for an application to successfully demonstrate use of The criteria for an application to successfully demonstrate use of
the NAT Behavior Discovery STUN usage would include: the NAT Behavior Discovery STUN usage would include:
o An implementation that relies on this usage to determine its run- o An implementation that relies on this usage to determine its run-
time behavior, most likely using it to determine an initial choice time behavior, most likely using it to determine an initial choice
of options that are then adjusted based on experience with its of options that are then adjusted based on experience with its
network connections. network connections.
skipping to change at page 7, line 44 skipping to change at page 7, line 44
client is configured with the address of a STUN server on the public client is configured with the address of a STUN server on the public
Internet. The Behavior Discovery usage makes use of SRV records so Internet. The Behavior Discovery usage makes use of SRV records so
that a server may use a different transport address for this usage that a server may use a different transport address for this usage
than for other usages. This usage does not provide backward than for other usages. This usage does not provide backward
compatibility with RFC3489 [RFC3489] for either clients or servers. compatibility with RFC3489 [RFC3489] for either clients or servers.
Implementors of clients that wish to be compliant with RFC3489 Implementors of clients that wish to be compliant with RFC3489
servers should see that specification. Implementors of servers servers should see that specification. Implementors of servers
SHOULD NOT include support for RFC3489 clients as the original uses SHOULD NOT include support for RFC3489 clients as the original uses
of that protocol have been deprecated. 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 The STUN NAT Behavior Discovery usage defines new attributes on the
STUN Binding Request and STUN Binding Response that allow these STUN Binding Request and STUN Binding Response that allow these
messages to be used to diagnose the current behavior of the NAT(s) messages to be used to diagnose the current behavior of the NAT(s)
between the client and server. between the client and server.
This section provides a descriptive overview of the typical use of This section provides a descriptive overview of the typical use of
these attributes. Normative behavior is described in Sections 5, 6, these attributes. Normative behavior is described in Sections 5, 6,
7, and 8 . 7, and 8 .
3.1. Determining NAT Mapping 3.1. Determining NAT Mapping
skipping to change at page 8, line 25 skipping to change at page 8, line 29
3.2. Determining NAT Filtering 3.2. Determining NAT Filtering
A client behind a NAT wishes to determine if the NAT it is behind is A client behind a NAT wishes to determine if the NAT it is behind is
currently using endpoint-independent, address-dependent, or address currently using endpoint-independent, address-dependent, or address
and port-dependent filtering[RFC4787]. The client performs a series and port-dependent filtering[RFC4787]. The client performs a series
of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST
attributes; these tests are described in Section 4. These tests attributes; these tests are described in Section 4. These tests
request responses from the alternate address and port of the STUN request responses from the alternate address and port of the STUN
server; a precondition to these tests is that no binding be server; a precondition to these tests is that no binding be
established to the alternate address and port. Because the NAT does established to the alternate address and port. Ensuring this
not know that the alternate address and port belong to the same precondition is difficult, therefore the client must either use a
server as the primary address and port, it treats these responses the random port or ensure that no traffic has previously occurred on the
same as it would those from any other host on the Internet. selected port. Because the NAT does not know that the alternate
Therefore, the success of the binding responses sent from the address and port belong to the same server as the primary address and
alternate address and port indicate whether the NAT is currently port, it treats these responses the same as it would those from any
performing endpoint-independent filtering, address-dependent other host on the Internet. Therefore, the success of the binding
filtering, or address and port-dependent filtering. This test responses sent from the alternate address and port indicate whether
applies only to UDP datagrams. 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 3.3. Binding Lifetime Discovery
Many systems, such as VoIP, rely on being able to keep a connection 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. open between a client and server or between peers of a P2P system.
Because NAT bindings expire over time, keepalive messages must be Because NAT bindings expire over time, keepalive messages must be
sent across the connection to preserve it. Because keepalives impose sent across the connection to preserve it. Because keepalives impose
some overhead on the network and servers, reducing the frequency of some overhead on the network and servers, reducing the frequency of
keepalives can be useful. keepalives can be useful.
Binding lifetime can be discovered by performing timed tests that use Binding lifetime can be discovered by performing timed tests that use
XOR-RESPONSE-TARGET. The client uses a second port and the STUN XOR-RESPONSE-TARGET. XOR-RESPONSE-TARGET allows the client to
server's alternate address to check if an existing binding that allocate two ports and request that responses to queries sent from
hasn't had traffic sent on it is still open after time T. This one port be delivered to the other. The client uses its second port
approach is described in detail in Section 4.5. This test applies and the STUN server's alternate address to check if an existing
only to UDP datagrams. binding that hasn't had traffic sent on it is still open after time
T. This approach is described in detail in Section 4.5. This test
applies only to UDP datagrams.
3.4. Diagnosing NAT Hairpinning 3.4. Diagnosing NAT Hairpinning
STUN Binding Requests allow a client to determine whether it is STUN Binding Requests allow a client to determine whether it is
behind a NAT that supports hairpinning of connections. To perform behind a NAT that supports hairpinning of connections. To perform
this test, the client first sends a Binding Request to its STUN this test, the client first sends a Binding Request to its STUN
server to determine its mapped address. The client then sends a 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 Binding Request to this mapped address from a different port. If the
client receives its own request, the NAT hairpins connections. This client receives its own request, the NAT hairpins connections. This
test applies to UDP, TCP, or TCP/TLS connections. test applies to UDP, TCP, or TCP/TLS connections.
skipping to change at page 10, line 7 skipping to change at page 10, line 13
checks to be made to determine the current behaviour of the NAT or checks to be made to determine the current behaviour of the NAT or
NATs an application is behind. These tests can only give the NATs an application is behind. These tests can only give the
instantaneous behaviour of a NAT; it has been found that NATs can instantaneous behaviour of a NAT; it has been found that NATs can
change behaviour under load and over time. An application must change behaviour under load and over time. An application must
assume that NAT behaviour can become more restrictive at any time. assume that NAT behaviour can become more restrictive at any time.
The tests described here are for UDP connectivity, NAT mapping The tests described here are for UDP connectivity, NAT mapping
behaviour, and NAT filtering behaviour; additional tests could be behaviour, and NAT filtering behaviour; additional tests could be
designed using this usage's mechanisms. Definitions for NAT designed using this usage's mechanisms. Definitions for NAT
filtering and mapping behaviour are from [RFC4787]. filtering and mapping behaviour are from [RFC4787].
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.
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
is defined in later sections.
4.1. Checking if UDP is Blocked 4.1. Checking if UDP is Blocked
The client sends a STUN Binding Request to a server. This causes the 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 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 request came from. If this test yields no response, the client knows
right away that it is not capable of UDP connectivity. This test right away that it is not capable of UDP connectivity. This test
requires only RFC3489-bis [I-D.ietf-behave-rfc3489bis] functionality. requires only STUN [RFC5389] functionality.
As with all tests, this test is only deterministic for connectivity
with the particular STUN server and source port used. A client
should be configured with multiple STUN servers for redundancy and to
protect against the configuration specifying an incorrect address for
the STUN server.
4.2. Determining NAT Mapping Behavior 4.2. Determining NAT Mapping Behavior
This will require at most three tests. In test I, the client This will require at most three tests. In test I, the client
performs the UDP connectivity test. The server will return its performs the UDP connectivity test. The server will return its
alternate address and port in OTHER-ADDRESS in the binding response. alternate address and port in OTHER-ADDRESS in the binding response.
If OTHER-ADDRESS is not returned, the server does not support this If OTHER-ADDRESS is not returned, the server does not support this
usage and this test cannot be run. The client examines the XOR- usage and this test cannot be run. The client examines the XOR-
MAPPED-ADDRESS attribute. If this address and port are the same as 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 local IP address and port of the socket used to send the request,
skipping to change at page 10, line 38 skipping to change at page 11, line 14
address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding
Response is the same as test I the NAT currently has Endpoint- Response is the same as test I the NAT currently has Endpoint-
Independent Mapping. If not, test III is performed: the client sends Independent Mapping. If not, test III is performed: the client sends
a Binding Request to the alternate address and port. If the XOR- a Binding Request to the alternate address and port. If the XOR-
MAPPED-ADDRESS matches test II, the NAT currently has Address- MAPPED-ADDRESS matches test II, the NAT currently has Address-
Dependent Mapping; if it doesn't match it currently has Address and Dependent Mapping; if it doesn't match it currently has Address and
Port-Dependent Mapping. Port-Dependent Mapping.
4.3. Determining NAT Filtering Behavior 4.3. Determining NAT Filtering Behavior
This will also require at most three tests. These tests should be This will also require at most three tests. Because prior traffic
performed using a port that wasn't used for mapping or other tests as may affect results, the client needs to either use a source port that
packets sent during those tests may affect results. In test I, the is known to have been idle for at least 15 minutes prior to running
client performs the UDP connectivity test. The server will return the test or use a random source port for these tests. A client
its alternate address and port in OTHER-ADDRESS in the binding performing these tests immediatley on startup will have no knowledge
response. If OTHER-ADDRESS is not returned, the server does not of prior use of these ports and, therefore, needs to use a random
support this usage and this test cannot be run. source port to ensure correct results.
Note that a client wishing to perform these tests using the source
port it will use for its application traffic, as recommended above,
must either use a random source port for its application traffic or
ensure that the intended source port is not used for at least 15
minutes prior to performing the test.
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 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 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 and change-IP. This will cause the server to send its response from
its alternate IP address and alternate port. If the client receives its alternate IP address and alternate port. If the client receives
a response the current behaviour of the NAT is Endpoint-Independent a response the current behaviour of the NAT is Endpoint-Independent
Filtering. Filtering.
If no response is received, test III must be performed to distinguish If no response is received, test III must be performed to distinguish
between Address-Dependent Filtering and Address and Port-Dependent between Address-Dependent Filtering and Address and Port-Dependent
skipping to change at page 11, line 33 skipping to change at page 12, line 20
determining its NAT does not always provide independent mapping might determining its NAT does not always provide independent mapping might
notify the user if no relay is configured, whereas an application notify the user if no relay is configured, whereas an application
behind a NAT that provides endpoint-independent mapping might not behind a NAT that provides endpoint-independent mapping might not
notify the user until a subsequent connection actually fails or might notify the user until a subsequent connection actually fails or might
provide a less urgent notification that no relay is configured. Such provide a less urgent notification that no relay is configured. Such
a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but 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 it does provide some information regarding whether ICE is likely to
be successful establishing non-relayed connections. be successful establishing non-relayed connections.
Care must be taken when parallelizing tests, as some NAT devices have Care must be taken when parallelizing tests, as some NAT devices have
an upper limit on how quickly bindings will be allocated. an upper limit on how quickly bindings will be allocated. Section
Section 5restricts the rate at which clients may begin new STUN
transactions.
4.5. Binding Lifetime Discovery 4.5. Binding Lifetime Discovery
STUN can also be used to probe the lifetimes of the bindings created STUN can also be used to probe the lifetimes of the bindings created
by the NAT. For many NAT devices, an absolute refresh interval by the NAT. For many NAT devices, an absolute refresh interval
cannot be determined; bindings might be closed quicker under heavy cannot be determined; bindings might be closed quicker under heavy
load or might not behave as the tests suggest. For this reason load or might not behave as the tests suggest. For this reason
applications that require reliable bindings must send keep-alives as applications that require reliable bindings must send keep-alives as
frequently as required by all NAT devices that will be encountered. frequently as required by all NAT devices that will be encountered.
Suggested refresh intervals are outside the scope of this document. Suggested refresh intervals are outside the scope of this document.
ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have
suggested refresh intervals. 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 To determine the binding lifetime, the client first sends a Binding
Request to the server from a particular socket, X. This creates a Request to the server from a particular source port, X. This creates
binding in the NAT. The response from the server contains a MAPPED- a binding in the NAT. The response from the server contains a
ADDRESS attribute, providing the public address and port on the NAT. MAPPED-ADDRESS attribute, providing the public address and port on
Call this Pa and Pp, respectively. The client then starts a timer the NAT. Call this Pa and Pp, respectively. The client then starts
with a value of T seconds. When this timer fires, the client sends a timer with a value of T seconds. When this timer fires, the client
another Binding Request to the server, using the same destination sends another Binding Request to the server, using the same
address and port, but from a different socket, Y. This request destination address and port, but from a different source port, Y.
contains an XOR-RESPONSE-TARGET address attribute, set to (Pa,Pp). This request contains an XOR-RESPONSE-TARGET address attribute, set
This will create a new binding on the NAT, and cause the STUN server to (Pa,Pp), to request the response be delivered to (Pa,Pp). This
to send a Binding Response that would match the old binding, if it will create a new binding on the NAT, and cause the STUN server to
still exists. If the client receives the Binding Response on socket 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 knows that the binding has not expired. If the client receives X, it knows that the binding has not expired. If the client receives
the Binding Response on socket Y (which is possible if the old the Binding Response on port Y (which is possible if the old binding
binding expired, and the NAT allocated the same public address and expired, and the NAT allocated the same public address and port to
port to the new binding), or receives no response at all, it knows the new binding), or receives no response at all, it knows that the
that the binding has expired. binding has expired.
Because some NATs only refresh bindings when outbound traffic is Because some NATs only refresh bindings when outbound traffic is
sent, the client must resend a binding request on the original port sent, the client must resend a binding request from the original
before beginning a second test with a different value of T. The source port before beginning a second test with a different value of
client can find the value of the binding lifetime by doing a binary T. The client can find the value of the binding lifetime by doing a
search through T, arriving eventually at the value where the response binary search through T, arriving eventually at the value where the
is not received for any timer greater than T, but is received for any response is not received for any timer greater than T, but is
timer less than T. 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 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 that will typically be run in the background on a device once it
boots. boots.
It is possible that the client can get inconsistent results each time 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 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 reset for some reason, the process may discover a lifetime than is
shorter than the actual one. Binding lifetime may also be dependent shorter than the actual one. Binding lifetime may also be dependent
on the traffic load on the NAT. For this reason, implementations are on the traffic load on the NAT. For this reason, implementations are
skipping to change at page 13, line 9 skipping to change at page 14, line 13
[I-D.ietf-sip-outbound] provides a response that confirms the [I-D.ietf-sip-outbound] provides a response that confirms the
connection is open and allows the client to check that its mapped connection is open and allows the client to check that its mapped
address has not changed. As that provides both the keepalive action address has not changed. As that provides both the keepalive action
and diagnostic that it is working, it should be preferred over any and diagnostic that it is working, it should be preferred over any
attempt to characterize the connection by a secondary technique. attempt to characterize the connection by a secondary technique.
5. Client Behavior 5. Client Behavior
Unless otherwise specified here, all procedures for preparing, Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described in the STUN Binding sending, and processing messages as described in the STUN Binding
Usage [I-D.ietf-behave-rfc3489bis] are followed. Usage [RFC5389] are followed.
If a client intends to utilize an XOR-RESPONSE-TARGET attribute in If a client intends to utilize an XOR-RESPONSE-TARGET attribute in
future transactions, as described in Section 4.5, then it MUST future transactions, as described in Section 4.5, then it MUST
include a CACHE-TIMEOUT attribute in the Request with the value set include a CACHE-TIMEOUT attribute in the Request with the value set
greater than the longest time duration it intends to test. The greater than the longest time duration it intends to test. The
server will also include this attribute in its Response, modified server will also include this attribute in its Response, modified
with its estimate of how long it will be able to cache this with its estimate of how long it will be able to cache this
connection. Because the returned value is only an estimate, the connection. Because the returned value is only an estimate, the
client must be prepared for the value to be wrong, and therefore to client must be prepared for the value to be wrong, and therefore to
receive a 481 response to its subsequent Requests with XOR-RESPONSE- receive a 481 response to its subsequent Requests with XOR-RESPONSE-
skipping to change at page 13, line 39 skipping to change at page 14, line 43
multiple IP addresses. Clients MUST be prepared to receive a 420 for multiple IP addresses. Clients MUST be prepared to receive a 420 for
requests that include CHANGE-REQUEST when OTHER-ADDRESS was not requests that include CHANGE-REQUEST when OTHER-ADDRESS was not
received in Binding Response messages from the server. received in Binding Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT by multiplexing it in a flow with application traffic, a FINGERPRINT
attribute SHOULD be included unless it is always possible to attribute SHOULD be included unless it is always possible to
distinguish a STUN message from an application message based on their distinguish a STUN message from an application message based on their
header. header.
When PADDING is used, it SHOULD be 1500 bytes long, unless a more When PADDING is used, it SHOULD be longer than the MTU of the
appropriate length is known based on the MTU of the path. outgoing interface.
Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response
unless they are using authentication with a provider of STUN servers unless they are using authentication with a provider of STUN servers
that is aware of the topology requirements of the tests being that is aware of the topology requirements of the tests being
performed. 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 5.1. Discovery
Unless the user or application is aware of the transport address of a Unless the user or application is aware of the transport address of a
STUN server supporting the NAT Behavior Discovery usage through other STUN server supporting the NAT Behavior Discovery usage through other
means, a client is configured with the domain name of the provider of means, a client is configured with the domain name of the provider of
the STUN servers. The domain is resolved to a transport address the STUN servers. The domain is resolved to a transport address
using SRV procedures [RFC2782]. The mechanism for configuring the using SRV procedures [RFC2782]. The mechanism for configuring the
client with the domain name of the STUN servers or of acquiring a client with the domain name of the STUN servers or of acquiring a
specific transport address is out of scope for this document. specific transport address is out of scope for this document.
For the Behavior Discovery Usage the service name is "stun-behavior". For the Behavior Discovery Usage the service name is "stun-behavior".
The protocol can be "udp", "tcp" or "tls". Other aspects of handling The protocol can be "udp", "tcp" or "tls". Other aspects of handling
failures and default ports are followed as described in STUN failures and default ports are followed as described in STUN
[I-D.ietf-behave-rfc3489bis]. [RFC5389].
5.2. Security 5.2. Security
Servers MAY require authentication before allowing a client to make Servers MAY require authentication before allowing a client to make
use of its services. This is particularly important to requests used use of its services. This is particularly important to requests used
to perform a Binding Lifetime Discovery test or other test requiring to perform a Binding Lifetime Discovery test or other test requiring
use of the XOR-RESPONSE-TARGET attribute. The method for obtaining use of the XOR-RESPONSE-TARGET attribute. The method for obtaining
these credentials, should the server require them, is outside the these credentials, should the server require them, is outside the
scope of this usage. Presumably, the administrator or application scope of this usage. Presumably, the administrator or application
relying on this usage should have its own method for obtaining relying on this usage should have its own method for obtaining
credentials. If the client receives a 401 (Unauthorized) Response to credentials. If the client receives a 401 (Unauthorized) Response to
a Request, then it must either acquire the appropriate credential a Request, then it must either acquire the appropriate credential
from the application before retrying or report a permanent failure. from the application before retrying or report a permanent failure.
Procedures for encoding the MESSAGE-INTEGRITY attribute for a request Procedures for encoding the MESSAGE-INTEGRITY attribute for a request
are described in STUN [I-D.ietf-behave-rfc3489bis]. are described in STUN [RFC5389].
6. Server Behavior 6. Server Behavior
Unless otherwise specified here, all procedures for preparing, Unless otherwise specified here, all procedures for preparing,
sending, and processing messages as described for the STUN Binding sending, and processing messages as described for the STUN Binding
Usage of STUN [I-D.ietf-behave-rfc3489bis] are followed. Usage of STUN [RFC5389] are followed.
A server implementing the NAT Behavior Discovery usage SHOULD be A server implementing the NAT Behavior Discovery usage SHOULD be
configured with two separate IP addresses on the public Internet. On configured with two separate IP addresses on the public Internet. On
startup, the server SHOULD allocate two UDP ports, such that it can startup, the server SHOULD allocate a pair of ports for each of the
send and receive datagrams using the same ports on each IP address UDP, TCP, and TCP/TLS transport protocols, such that it can send and
(normally a wildcard binding accomplishes this). If a server cannot receive datagrams using the same ports on each IP address (normally a
allocate the same ports on two different IP address, then it MUST NOT wildcard binding accomplishes this). TCP and TCP/TLS MUST use
include an OTHER-ADDRESS attribute in any Response and MUST respond different ports. If a server cannot allocate the same ports on two
with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST different IP address, then it MUST NOT include an OTHER-ADDRESS
attribute. A server with only one IP address MUST NOT be advertised attribute in any Response and MUST respond with a 420 (Unknown
using the SRV service name "stun-behavior". 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".
6.1. Preparing the Response 6.1. Preparing the Response
After performing all authentication and verification steps the server After performing all authentication and verification steps the server
begins processing specific to this Usage if the Request contains any begins processing specific to this Usage if the Request contains any
request attributes defined in this document: XOR-RESPONSE-TARGET, request attributes defined in this document: XOR-RESPONSE-TARGET,
CHANGE-REQUEST, CACHE-TIMEOUT, or PADDING. If the Request does not CHANGE-REQUEST, CACHE-TIMEOUT, or PADDING. If the Request does not
contain any attributes from this document, OTHER-ADDRESS and contain any attributes from this document, OTHER-ADDRESS and
RESPONSE-ORIGIN are still included in the response. RESPONSE-ORIGIN are still included in the response.
skipping to change at page 15, line 25 skipping to change at page 16, line 37
SHOULD include a CACHE-TIMEOUT attribute in its response indicating SHOULD include a CACHE-TIMEOUT attribute in its response indicating
the duration (in seconds) it anticipates being able to cache this the duration (in seconds) it anticipates being able to cache this
binding request in anticipation of a future Request using the XOR- binding request in anticipation of a future Request using the XOR-
RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be
greater or less than the value in the request. If the server is not greater or less than the value in the request. If the server is not
prepared to provide such an estimate, it SHOULD NOT include the prepared to provide such an estimate, it SHOULD NOT include the
CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT
provide a CACHE-TIMEOUT length longer than the amount of time it has provide a CACHE-TIMEOUT length longer than the amount of time it has
been able to cache recent requests. been able to cache recent requests.
Because XOR-RESPONSE-TARGET offers the potential for minor If XOR-RESPONSE-TARGET is included in a Request, then the server MUST
indirection attacks, a server MUST either authenticate the users
requesting its use or rate-limit its response to those requests.
If XOR-RESPONSE-TARGET is included in a Request, then the server must
verify that it has previously received a binding request from the verify that it has previously received a binding request from the
same address as is specified in XOR-RESPONSE-TARGET. If it has not, same address as is specified in XOR-RESPONSE-TARGET. If it has not,
or if sufficient time has passed that it no longer has a record of or if sufficient time has passed that it no longer has a record of
having received such a request due to limited state, it MUST respond having received such a request due to limited state, it MUST respond
with an error response of type 481. with an error response of type 481.
If the Request contains a XOR-RESPONSE-TARGET attribute and the If the Request contains a XOR-RESPONSE-TARGET attribute and the
server is authenticating such requests, then the server checks the server is authenticating such requests, then the server checks the
message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they
are not present the server MUST generate an error response of type are not present the server MUST generate an error response of type
401. 401.
If the Request contains a XOR-RESPONSE-TARGET attribute and the Because XOR-RESPONSE-TARGET offers the potential for minor
server is rate-limiting such requests, it MUST ensure that it does indirection attacks, a server MUST either authenticate the users
not generate a Response on a particular address more often than one requesting its use or rate-limit its response to those requests.
per second. If it receives requests more often than one per second, Rate-limiting is RECOMMENDED for responses to authenticated requests
it MUST generate a 503 (Service unavailable) Response to the Request. unless the server is deployed for an application that requires more
frequent responses. If the Request contains a XOR-RESPONSE-TARGET
attribute and the server is rate-limiting such requests, it MUST
ensure that it does not generate a Response on a particular address
more often than one per second. If the server receives requests
whose responses are being rate-limited more often than one per
second, it MUST generate a 503 (Service unavailable) Response to the
Request.
The source address and port of the Binding Response depend on the 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 value of the CHANGE-REQUEST attribute and on the address and port the
Binding Request was received on, and are summarized in Table 1. 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 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 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), IP address of the Binding Request (which will be either A1 or A2),
and Dp represent the destination port of the Binding Request (which and Dp represent the destination port of the Binding Request (which
will be either P1 or P2). Let Ca represent the other address, so will be either P1 or P2). Let Ca represent the other address, so
skipping to change at page 17, line 6 skipping to change at page 18, line 20
client had set the "change IP" and "change port" flags in the Binding client had set the "change IP" and "change port" flags in the Binding
Request. As summarized in Table 1, these are Ca and Cp, Request. As summarized in Table 1, these are Ca and Cp,
respectively, regardless of the value of the CHANGE-REQUEST flags. respectively, regardless of the value of the CHANGE-REQUEST flags.
Next the server inspects the Request for a XOR-RESPONSE-TARGET Next the server inspects the Request for a XOR-RESPONSE-TARGET
attribute. If the XOR-RESPONSE-TARGET attribute is included, then it attribute. If the XOR-RESPONSE-TARGET attribute is included, then it
includes an XOR-REFLECTED-FROM attribute with the source address the includes an XOR-REFLECTED-FROM attribute with the source address the
Request was received from. Request was received from.
If the Request contained a PADDING attribute, PADDING MUST be If the Request contained a PADDING attribute, PADDING MUST be
included in the Binding Response. The server MUST use either the included in the Binding Response. The server SHOULD use a length of
length of PADDING in the Request or a length it knows is sufficient PADDING equal to the MTU on the outgoing interface. If the Request
to cause fragmentation along the return path. If the Request also also contains the XOR-RESPONSE-TARGET attribute the server MUST
contains the XOR-RESPONSE-TARGET attribute the server MUST return an return an error response of type 400.
error response of type 400.
Following that, the server completes the remainder of the processing Following that, the server completes the remainder of the processing
from STUN [I-D.ietf-behave-rfc3489bis]. If authentication is being from STUN [RFC5389]. If authentication is being required, the server
required, the server MUST include a MESSAGE-INTEGRITY and associated MUST include a MESSAGE-INTEGRITY and associated attributes as
attributes as appropriate. A FINGERPRINT attribute is only required appropriate. A FINGERPRINT attribute is only required if the STUN
if the STUN messages are being multiplexed with application traffic messages are being multiplexed with application traffic that requires
that requires use of a FINGERPRINT to distinguish STUN messages. An use of a FINGERPRINT to distinguish STUN messages.
ALTERNATE-SERVER attribute SHOULD NOT be included.
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 When the server sends the Response, it is sent from the source
address as determined above and to the destination address determined address as determined above and to the destination address determined
from the XOR-RESPONSE-TARGET, or to the source address of the Request from the XOR-RESPONSE-TARGET, or to the source address of the Request
otherwise. otherwise.
7. New Attributes 7. New Attributes
This document defines several STUN attributes that are required for This document defines several STUN attributes that are required for
NAT Behavior Discovery. These attributes are all used only with NAT Behavior Discovery. These attributes are all used only with
Binding Requests and Binding Responses. CHANGE-REQUEST was Binding Requests and Binding Responses. CHANGE-REQUEST was
originally defined in RFC3489 [RFC3489] but is redefined here as that originally defined in RFC3489 [RFC3489] but is redefined here as that
document is obsoleted by RFC3489bis [I-D.ietf-behave-rfc3489bis]. document is obsoleted by [RFC5389].
Comprehension-required range (0x0000-0x7FFF): Comprehension-required range (0x0000-0x7FFF):
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0026: PADDING 0x0026: PADDING
0x0027: XOR-RESPONSE-TARGET 0x0027: XOR-RESPONSE-TARGET
0x0028: XOR-REFLECTED-FROM 0x0028: XOR-REFLECTED-FROM
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
0x8027: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
7.1. Representing Transport Addresses 7.1. Representing Transport Addresses
Whenever an attribute contains a transport address, it has the same Whenever an attribute contains a transport IP address and port, it
format as MAPPED-ADDRESS. Similarly, the XOR- attributes have the has the same format as MAPPED-ADDRESS. Similarly, the XOR-
same format as XOR-MAPPED-ADDRESS[I-D.ietf-behave-rfc3489bis]. attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389].
7.2. CHANGE-REQUEST 7.2. CHANGE-REQUEST
The CHANGE-REQUEST attribute contains two flags to control the IP The CHANGE-REQUEST attribute contains two flags to control the IP
address and port the server uses to send the response. These flags address and port the server uses to send the response. These flags
are called the "change IP" and "change port" flags. The CHANGE- are called the "change IP" and "change port" flags. The CHANGE-
REQUEST attribute is allowed only in the Binding Request. The REQUEST attribute is allowed only in the Binding Request. The
"change IP" and "change port" flags are useful for determining the "change IP" and "change port" flags are useful for determining the
current filtering behavior of a NAT. They instruct the server to current filtering behavior of a NAT. They instruct the server to
send the Binding Responses from the alternate source IP address send the Binding Responses from the alternate source IP address
skipping to change at page 18, line 50 skipping to change at page 20, line 20
Binding Responses. Binding Responses.
7.4. OTHER-ADDRESS 7.4. OTHER-ADDRESS
The OTHER-ADDRESS attribute is used in Binding Responses. It informs 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 of the source IP address and port that would be used if
the client requested the "change IP" and "change port" behavior. the client requested the "change IP" and "change port" behavior.
OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the
server has a second IP address. server has a second IP address.
OTHER-ADDRESS uses the same attribute as CHANGED-ADDRESS from RFC3489 OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
because it is simply a new name with the same semantics as CHANGED- RFC3489 [RFC3489]because it is simply a new name with the same
ADDRESS. It has been renamed to more clearly indicate its function. semantics as CHANGED-ADDRESS. It has been renamed to more clearly
indicate its function.
7.5. XOR-REFLECTED-FROM 7.5. XOR-REFLECTED-FROM
The XOR-REFLECTED-FROM attribute is present only in Binding Responses The XOR-REFLECTED-FROM attribute is present only in Binding Responses
when the Binding Request contained a XOR-RESPONSE-TARGET attribute. when the Binding Request contained a XOR-RESPONSE-TARGET attribute.
The attribute contains the transport address of the source where the The attribute contains the transport address of the source where the
request came from. Its purpose is to provide traceability, so that a request came from. Its purpose is to provide traceability, so that a
STUN server cannot be used as a reflector for anonymous denial-of- STUN server cannot be used as a reflector for anonymous denial-of-
service attacks. service attacks.
skipping to change at page 19, line 45 skipping to change at page 21, line 16
network address. network address.
7.7. PADDING 7.7. PADDING
The PADDING attribute allows for the entire message to be padded to The PADDING attribute allows for the entire message to be padded to
force the STUN message to be divided into IP fragments. PADDING force the STUN message to be divided into IP fragments. PADDING
consists entirely of a freeform string, the value of which does not consists entirely of a freeform string, the value of which does not
matter. PADDING can be used in either Binding Requests or Binding matter. PADDING can be used in either Binding Requests or Binding
Responses. Responses.
PADDING MUST be no longer than 64K and SHOULD be an even multiple of PADDING MUST NOT be longer than the length that brings the total IP
four bytes. Because STUN messages with PADDING are intended to test datagram size to 64K and SHOULD be an even multiple of four bytes.
the behavior of UDP fragments, they are an exception to the usual Because STUN messages with PADDING are intended to test the behavior
rule that STUN messages be less than the MTU of the path. of dUDP fragments, they are an exception to the usual rule that STUN
messages be less than the MTU of the path.
7.8. CACHE-TIMEOUT 7.8. CACHE-TIMEOUT
The CACHE-TIMEOUT is used in Binding Requests and Responses. It The CACHE-TIMEOUT is used in Binding Requests and Responses. It
indicates the time duration (in seconds) that the server will cache indicates the time duration (in seconds) that the server will cache
the source address and USERNAME of an original binding request that the source address and USERNAME of an original binding request that
will later by followed by a request from a different source address will later by followed by a request from a different source address
with a XOR-RESPONSE-TARGET asking that a response be reflected to the with a XOR-RESPONSE-TARGET asking that a response be reflected to the
source address of the original binding request. A server SHOULD NOT source address of the original binding request. A server SHOULD NOT
send a response to a target address requested with XOR-RESPONSE- send a response to a target address requested with XOR-RESPONSE-
skipping to change at page 20, line 33 skipping to change at page 21, line 50
not include a CACHE-TIMEOUT attribute in its response. not include a CACHE-TIMEOUT attribute in its response.
8. New Response Codes 8. New Response Codes
This draft defines new STUN response code. This draft defines new STUN response code.
8.1. 481 Connection does not exist 8.1. 481 Connection does not exist
This code is generated when a server has received an XOR-RESPONSE- This code is generated when a server has received an XOR-RESPONSE-
TARGET, but the server has no record of having received a prior TARGET, but the server has no record of having received a prior
binding Request from the address specified in XOR-RESPONSE-TARGET. Binding Request from the address specified in XOR-RESPONSE-TARGET.
The client should re-submit the original binding request with an
appropriate CACHE-TIMEOUT attribute. If the server's response The client SHOULD send a new Binding Request from the address it
includes a CACHE-TIMEOUT that is shorter than the client's request, intends to specify in an XOR-RESPONSE-TARGET. This new Binding
the server is unable to satisfy the caching time requested by the Request SHOULD include a CACHE-TIMEOUT attribute with the value set
client and the client SHOULD NOT continue to retry the request. to the desired duration. If the server's response includes a CACHE-
TIMEOUT duration that is shorter than the client's requested
duration, the server is unable to satisfy the caching time requested
by the client and the client SHOULD NOT continue to retry the
request.
8.2. 503 Service Unavailable 8.2. 503 Service Unavailable
This response is generated when a server receives Requests specifying This response is generated when a server receives Requests specifying
a particular address in their XOR-RESPONSE-TARGET attribute more a particular address in their XOR-RESPONSE-TARGET attribute more
often than one per second. often than one per second.
9. IAB Considerations 9. IAB Considerations
The IAB has studied the problem of ``Unilateral Self Address The IAB has studied the problem of ``Unilateral Self Address
skipping to change at page 23, line 8 skipping to change at page 24, line 29
This usage provides a set of generic attributes that can be assembled This usage provides a set of generic attributes that can be assembled
to test many types of NAT behavior. While tests for the most to test many types of NAT behavior. While tests for the most
commonly known NAT box behaviors are described, the BEHAVE mailing commonly known NAT box behaviors are described, the BEHAVE mailing
list regularly has descriptions of new behaviors, some of which may list regularly has descriptions of new behaviors, some of which may
not be readily detected using the tests described herein. However, not be readily detected using the tests described herein. However,
the techniques described in this usage can be assembled in different the techniques described in this usage can be assembled in different
combinations to test NAT behaviors not now known or envisioned. combinations to test NAT behaviors not now known or envisioned.
10. IANA Considerations 10. IANA Considerations
This specification requests that IANA make additions to the "STUN
Attributes Registry" and "STUN Error Code Registry". IANA is also
requested to add an SRV registration for "stun-behavior" for this
STUN usage.
10.1. STUN Attribute Registry
This specification defines several new STUN attributes. This section This specification defines several new STUN attributes. This section
directs IANA to add these new protocol elements to the IANA registry directs IANA to add these new protocol elements to the IANA registry
of STUN protocol elements. of STUN protocol elements.
0x0003: CHANGE-REQUEST 0x0003: CHANGE-REQUEST
0x0027: XOR-RESPONSE-TARGET 0x0027: XOR-RESPONSE-TARGET
0x0028: XOR-REFLECTED-FROM 0x0028: XOR-REFLECTED-FROM
0x0026: PADDING 0x0026: PADDING
0x8027: CACHE-TIMEOUT 0x8027: CACHE-TIMEOUT
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
10.2. STUN Error Code Registry
This specification defines two new STUN error response codes. This specification defines two new STUN error response codes.
481: Connection does not exist 481: Connection does not exist
503: Service Unavailable 503: Service Unavailable
11. Security Considerations 11. Security Considerations
This usage inherits the security considerations of STUN This usage inherits the security considerations of STUN [RFC5389].
[I-D.ietf-behave-rfc3489bis]. This usage adds several new This usage adds several new attributes; security considerations for
attributes; security considerations for those are detailed here. those are detailed here.
OTHER-ADDRESS does not permit any new attacks; it provides another OTHER-ADDRESS does not permit any new attacks; it provides another
place where an attacker can impersonate a STUN server but it is not place where an attacker can impersonate a STUN server but it is not
an interesting attack. An attacker positioned where it can an interesting attack. An attacker positioned where it can
compromise the Binding Response can completely hide the STUN server compromise the Binding Response can completely hide the STUN server
from the client. from the client.
XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector
for denial-of-service attacks. It does not provide any amplification for denial-of-service attacks. It does not provide any amplification
of the attack. The XOR-REFLECTED-FROM mitigates this by providing of the attack. The XOR-REFLECTED-FROM mitigates this by providing
skipping to change at page 24, line 25 skipping to change at page 26, line 9
no additional amplification and the security mechanisms for XOR- no additional amplification and the security mechanisms for XOR-
RESPONSE-TARGET are deemed sufficient. RESPONSE-TARGET are deemed sufficient.
RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide
any additional attacks. any additional attacks.
12. Acknowledgements 12. Acknowledgements
The authors would like to thank the authors of the original STUN The authors would like to thank the authors of the original STUN
specification [RFC3489] from which many of the ideas, attributes, and specification [RFC3489] from which many of the ideas, attributes, and
description in this document originated. description in this document originated. Thanks to Dan Wing, Cullen
Jennings, and Magnus Westerlund for detailed comments.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-18 (work in progress),
July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008.
13.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-15 (work in progress), June 2008. draft-ietf-sip-outbound-16 (work in progress),
October 2008.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
skipping to change at page 27, line 16 skipping to change at page 28, line 44
o moved semantics of PADDING usage into behavior sections rather o moved semantics of PADDING usage into behavior sections rather
than attributes section than attributes section
o removed reference to SERVER attribute o removed reference to SERVER attribute
o removed Open Issues section o removed Open Issues section
o Updated IAB considerations 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
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
Authors' Addresses Authors' Addresses
Derek C. MacDonald Derek C. MacDonald
CounterPath Solutions, Inc. CounterPath Solutions, Inc.
Suite 300, One Bentall Centre, 505 Burrard St Suite 300, One Bentall Centre, 505 Burrard St
Vancouver, BC V7X1M3 Vancouver, BC V7X1M3
Canada Canada
Phone: +1-604-320-3344 Phone: +1-604-320-3344
Email: derek@counterpath.com Email: derek@counterpath.com
Bruce B. Lowekamp Bruce B. Lowekamp
SIPeerior Technologies, Inc. SIPeerior Technologies
3000 Easter Circle 5251-18 John Tyler Highway #330
Williamsburg, Virginia 23188 Williamsburg, VA 23185
USA USA
Phone: +1-757-565-0101 Email: bbl@lowekamp.net
Email: lowekamp@sipeerior.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 46 change blocks. 
191 lines changed or deleted 298 lines changed or added

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