draft-ietf-behave-nat-behavior-discovery-05.txt   draft-ietf-behave-nat-behavior-discovery-06.txt 
BEHAVE D. MacDonald BEHAVE D.C. MacDonald
Internet-Draft CounterPath Solutions, Inc. Internet-Draft CounterPath Solutions, Inc.
Intended status: Experimental B. Lowekamp Intended status: Experimental B. B. Lowekamp
Expires: May 7, 2009 SIPeerior Technologies Expires: September 10, 2009 MYMIC LLC
November 3, 2008 March 9, 2009
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-05 draft-ietf-behave-nat-behavior-discovery-06
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79.
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.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 May 7, 2009. This Internet-Draft will expire on September 10, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document.
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.
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Table of Contents Table of Contents
1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Diagnostic Use . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Diagnostic Use . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 6 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 6 2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 8
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 8
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 8 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 9
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 8 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 9
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 8 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 9
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 9 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 10
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 9 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 10
3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 9 3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 10
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 9 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 10 4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 11
4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 10 4.2. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 12
4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 11 4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 13
4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11 4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 13
4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 12 4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 14
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 14
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 15 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 16 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18
7.1. Representing Transport Addresses . . . . . . . . . . . . . 19 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 20 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 20 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 22
7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 20 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 20 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 22
7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 22
7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 21 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 23
8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 21 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 23
8.1. 481 Connection does not exist . . . . . . . . . . . . . . 21 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 24
8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 22 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 24
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 22 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 24
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 22 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 22 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 24
9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 23 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 25
9.4. Requirements for a Long Term Solution . . . . . . . . . . 23 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 25
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 24 9.4. Requirements for a Long Term Solution . . . . . . . . . . 26
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 26
10.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 24 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10.2. STUN Error Code Registry . . . . . . . . . . . . . . . . . 24 10.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 25 10.2. STUN Error Code Registry . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 10.3. SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 26 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 26 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 27 13.2. Informative References . . . . . . . . . . . . . . . . . . 29
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 27 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 27 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 29
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 28 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 29
A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 28 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 30
A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 28 A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 31
Intellectual Property and Copyright Statements . . . . . . . . . . 30 A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 31
A.7. from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32
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 and the particular ports behavior with regard to the STUN server used and the particular ports
used at the instant the test is run. Applications requiring reliable used at the instant the test is run. Applications requiring reliable
skipping to change at page 5, line 5 skipping to change at page 5, line 52
original use of RFC3489 [RFC3489], which was intended for static original use of RFC3489 [RFC3489], which was intended for static
determination of device behavior. The NAT Behavior Discovery STUN determination of device behavior. The NAT Behavior Discovery STUN
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.
If a draft specifies the use of any portion of this STUN usage, that
draft MUST document 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.
2. Introduction 2. Introduction
The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a
mechanism to discover the reflexive transport address toward the STUN mechanism to discover the reflexive transport address toward the STUN
server, using the Binding Request. This specification defines the server, using the Binding Request. This specification defines the
NAT Behavior Discovery STUN usage, which allows a STUN client to NAT Behavior Discovery STUN usage, which allows a STUN client to
probe the current behaviour of the NAT/FW devices between the client probe the current behaviour of the NAT/FW devices between the client
and the STUN server. This usage defines new STUN attributes for the and the STUN server. This usage defines new STUN attributes for the
Binding Request and Binding Response. Binding Request and Binding Response.
skipping to change at page 8, line 29 skipping to change at page 9, line 34
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. Ensuring this established to the alternate address and port. See below for more
precondition is difficult, therefore the client must either use a information. Because the NAT does not know that the alternate
random port or ensure that no traffic has previously occurred on the
selected port. Because the NAT does not know that the alternate
address and port belong to the same server as the primary address and 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 port, it treats these responses the same as it would those from any
other host on the Internet. Therefore, the success of the binding other host on the Internet. Therefore, the success of the binding
responses sent from the alternate address and port indicate whether responses sent from the alternate address and port indicate whether
the NAT is currently performing endpoint-independent filtering, the NAT is currently performing endpoint-independent filtering,
address-dependent filtering, or address and port-dependent filtering. address-dependent filtering, or address and port-dependent filtering.
This test applies only to UDP datagrams. This test applies only to UDP datagrams.
3.3. Binding Lifetime Discovery 3.3. Binding Lifetime Discovery
skipping to change at page 9, line 7 skipping to change at page 10, line 11
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. XOR-RESPONSE-TARGET allows the client to XOR-RESPONSE-TARGET. XOR-RESPONSE-TARGET allows the client to
allocate two ports and request that responses to queries sent from allocate two ports and request that responses to queries sent from
one port be delivered to the other. The client uses its second port 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 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 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 T. This approach is described in detail in Section 4.6. This test
applies only to UDP datagrams. 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
skipping to change at page 10, line 13 skipping to change at page 11, line 18
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 This section provides a descriptive overview of how the primitives
provided by the STUN attributes in this specification may be used to provided by the STUN attributes in this specification may be used to
perform behavior tests. Normative specifications for the attributes perform behavior tests. Normative specifications for the attributes
is defined in later sections. is defined in later sections.
4.1. Checking if UDP is Blocked 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
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 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 STUN [RFC5389] functionality. requires only STUN [RFC5389] functionality.
As with all tests, this test is only deterministic for connectivity As with all tests, this test is only deterministic for connectivity
with the particular STUN server and source port used. A client with the particular STUN server and source port used. A client
should be configured with multiple STUN servers for redundancy and to should be configured with multiple STUN servers for redundancy and to
protect against the configuration specifying an incorrect address for protect against the configuration specifying an incorrect address for
the STUN server. the STUN server.
4.2. Determining NAT Mapping Behavior 4.3. 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,
the client knows that it is not NATed and the effective mapping will the client knows that it is not NATed and the effective mapping will
be Endpoint-Independent. be Endpoint-Independent.
In test II, the client sends a Binding Request to the alternate In test II, the client sends a Binding Request to the alternate
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.4. Determining NAT Filtering Behavior
This will also require at most three tests. Because prior traffic
may affect results, the client needs to either use a source port that
is known to have been idle for at least 15 minutes prior to running
the test or use a random source port for these tests. A client
performing these tests immediatley on startup will have no knowledge
of prior use of these ports and, therefore, needs to use a random
source port to ensure correct results.
Note that a client wishing to perform these tests using the source This will also require at most three tests. These tests are
port it will use for its application traffic, as recommended above, sensitive to prior state on the NAT.
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 In test I, the client performs the UDP connectivity test. The server
will return its alternate address and port in OTHER-ADDRESS in the will return its alternate address and port in OTHER-ADDRESS in the
binding response. If OTHER-ADDRESS is not returned, the server does binding response. If OTHER-ADDRESS is not returned, the server does
not support this usage and this test cannot be run. 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
skipping to change at page 11, line 48 skipping to change at page 14, line 5
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
Filtering. In test III, the client sends a binding request to the Filtering. In test III, the client sends a binding request to the
original server address with CHANGE-REQUEST set to change-port. If original server address with CHANGE-REQUEST set to change-port. If
the client receives a response the current behaviour is Address- the client receives a response the current behaviour is Address-
Dependent Filtering; if no response is received the current behaviour Dependent Filtering; if no response is received the current behaviour
is Address and Port-Dependent Filtering. is Address and Port-Dependent Filtering.
4.4. Combining and Ordering Tests 4.5. Combining and Ordering Tests
Clients may wish to combine and parallelize these tests to reduce the Clients may wish to combine and parallelize these tests to reduce the
number of packets sent and speed the discovery process. For example, number of packets sent and speed the discovery process. For example,
test I of the filtering and mapping tests also checks if UDP is test I of the filtering and mapping tests also checks if UDP is
blocked. Furthermore, an application or user may not need as much blocked. Furthermore, an application or user may not need as much
detail as these sample tests provide. For example, establishing detail as these sample tests provide. For example, establishing
connectivity between nodes becomes significantly more difficult if a connectivity between nodes becomes significantly more difficult if a
NAT has any behavior other than endpoint-independent mapping, which NAT has any behavior other than endpoint-independent mapping, which
requires only test I and II of Section 4.2. An application requires only test I and II of Section 4.3. An application
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 combining and parallelizing tests, due to the
an upper limit on how quickly bindings will be allocated. Section sensitivity of certain tests to prior state on the NAT and because
Section 5restricts the rate at which clients may begin new STUN some NAT devices have an upper limit on how quickly bindings will be
transactions. allocated. Section Section 5 restricts the rate at which clients may
begin new STUN transactions.
4.5. Binding Lifetime Discovery 4.6. 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. Such tests are sensitive to prior state on the NAT. For
cannot be determined; bindings might be closed quicker under heavy many NAT devices, an absolute refresh interval cannot be determined;
load or might not behave as the tests suggest. For this reason bindings might be closed quicker under heavy load or might not behave
applications that require reliable bindings must send keep-alives as as the tests suggest. For this reason applications that require
frequently as required by all NAT devices that will be encountered. reliable bindings must send keep-alives as frequently as required by
Suggested refresh intervals are outside the scope of this document. all NAT devices that will be encountered. Suggested refresh
ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have 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. suggested refresh intervals.
Determining the binding lifetime relies on two separate source ports Determining the binding lifetime relies on two separate source ports
being used to send STUN Binding Requests to the STUN server. The 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 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 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 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 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 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 X has timed out, that response will not be received. By varying the
skipping to change at page 14, line 16 skipping to change at page 16, line 22
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 [RFC5389] 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.6, 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-
TARGET. TARGET.
Support for XOR-RESPONSE-TARGET is optional due to the state cost on Support for XOR-RESPONSE-TARGET is optional due to the state cost on
skipping to change at page 14, line 43 skipping to change at page 16, line 49
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 longer than the MTU of the When PADDING is used, it SHOULD be equal to the MTU of the outgoing
outgoing interface. 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 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 second and SHOULD pace them such that the RTOs do not synchronize the
retransmissions of each transaction. 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 for UDP and TCP. The service name is "stun-behaviors" for TLS over
failures and default ports are followed as described in STUN TCP. Only "tcp" is defined as a protocol for "stun-behaviors".
[RFC5389]. Other aspects of handling failures and default ports are followed as
described in STUN [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
skipping to change at page 16, line 8 skipping to change at page 18, line 14
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 a pair of ports for each of the 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 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 receive datagrams using the same ports on each IP address (normally a
wildcard binding accomplishes this). TCP and TCP/TLS MUST use wildcard binding accomplishes this). TCP and TCP/TLS MUST use
different ports. If a server cannot allocate the same ports on two different ports. If a server cannot allocate the same ports on two
different IP address, then it MUST NOT include an OTHER-ADDRESS different IP address, then it MUST NOT include an OTHER-ADDRESS
attribute in any Response and MUST respond with a 420 (Unknown attribute in any Response and MUST respond with a 420 (Unknown
Attribute) to any Request with a CHANGE-REQUEST attribute. A server Attribute) to any Request with a CHANGE-REQUEST attribute. A server
with only one IP address MUST NOT be advertised using the SRV service with only one IP address MUST NOT be advertised using the SRV service
name "stun-behavior". name "stun-behavior" or "stun-behaviors".
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 21, line 19 skipping to change at page 23, line 27
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 NOT be longer than the length that brings the total IP PADDING MUST NOT be longer than the length that brings the total IP
datagram size to 64K and SHOULD be an even multiple of four bytes. datagram size to 64K and SHOULD be an even multiple of four bytes.
Because STUN messages with PADDING are intended to test the behavior Because STUN messages with PADDING are intended to test the behavior
of dUDP fragments, they are an exception to the usual rule that STUN of UDP fragments, they are an exception to the usual rule that STUN
messages be less than the MTU of the path. 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
skipping to change at page 24, line 30 skipping to change at page 26, line 43
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 This specification requests that IANA make additions to the "STUN
Attributes Registry" and "STUN Error Code Registry". IANA is also Attributes Registry" and "STUN Error Code Registry".
requested to add an SRV registration for "stun-behavior" for this
STUN usage.
10.1. STUN Attribute Registry 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
skipping to change at page 25, line 8 skipping to change at page 27, line 18
0x802b: RESPONSE-ORIGIN 0x802b: RESPONSE-ORIGIN
0x802c: OTHER-ADDRESS 0x802c: OTHER-ADDRESS
10.2. STUN Error Code Registry 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
10.3. 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
11. Security Considerations 11. Security Considerations
This usage inherits the security considerations of STUN [RFC5389]. This usage inherits the security considerations of STUN [RFC5389].
This usage adds several new attributes; security considerations for This usage adds several new 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
skipping to change at page 29, line 21 skipping to change at page 31, line 43
o clarified that test combinations are non-normative o clarified that test combinations are non-normative
o Numerous clarifications o Numerous clarifications
o Changed PADDING to default to interface MTU, and changed maximum o Changed PADDING to default to interface MTU, and changed maximum
length to not make IP datagram exceed 64K length to not make IP datagram exceed 64K
o Added text that server should allocate TCP and TCP/TLS 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.
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 MYMIC LLC
5251-18 John Tyler Highway #330 200 High St, Suite 308
Williamsburg, VA 23185 Portsmouth, VA 23704
USA USA
Email: bbl@lowekamp.net Email: bbl@lowekamp.net
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
 End of changes. 30 change blocks. 
126 lines changed or deleted 226 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/