draft-ietf-behave-nat-behavior-discovery-07.txt   draft-ietf-behave-nat-behavior-discovery-08.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 8, 2010 MYMIC LLC Expires: March 31, 2010 MYMIC LLC
July 7, 2009 September 27, 2009
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-07 draft-ietf-behave-nat-behavior-discovery-08
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 8, 2010. This Internet-Draft will expire on March 31, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. and restrictions with respect to this document.
Abstract Abstract
This specification defines an experimental usage of the Simple This specification defines an experimental usage of the Session
Traversal Underneath Network Address Translators (NAT) (STUN) Traversal Utilities for NAT (STUN) Protocol that discovers the
Protocol that discovers the presence and current behaviour of NATs presence and current behaviour of NATs and firewalls between the STUN
and firewalls between the STUN client and the STUN server. 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 7 2.1. Example Diagnostic Use . . . . . . . . . . . . . . . . . . 7
2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7
2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 9 2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 9
3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 10 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 10
3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 10
3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 10 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 11
3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11
3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 11
3.5. Determining Fragment Handling . . . . . . . . . . . . . . 11 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 12
3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 12 3.6. Detecting a Generic Application Level Gateways (ALG) . . . 12
4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 12 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 13 4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 13
4.2. Checking for UDP Connectivity with the STUN Server . . . . 14 4.2. Checking for UDP Connectivity with the STUN Server . . . . 14
4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14 4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 14
4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 15 4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 15
4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15 4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 15
4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 16 4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 16
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 18
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 19 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 19
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 22 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Representing Transport Addresses . . . . . . . . . . . . . 22 7.1. Representing Transport Addresses . . . . . . . . . . . . . 21
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 23 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 22
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 23 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 22
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 23 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22
7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 24 7.5. RESPONSE-PORT . . . . . . . . . . . . . . . . . . . . . . 23
7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 24 7.6. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 24 8. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 23
7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 25 8.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 24
8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 25 8.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 24
8.1. 481 Connection does not exist . . . . . . . . . . . . . . 25 8.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 24
8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 25 8.4. Requirements for a Long Term Solution . . . . . . . . . . 25
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 26 8.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 25
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 26 9.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 25
9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 26 9.2. SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 26
9.4. Requirements for a Long Term Solution . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 27 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 28 12.1. Normative References . . . . . . . . . . . . . . . . . . . 27
10.2. STUN Error Code Registry . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . . 27
10.3. SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 28 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 28
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 28
11. Security Considerations . . . . . . . . . . . . . . . . . . . 29 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 28
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 29
13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 29
13.2. Informative References . . . . . . . . . . . . . . . . . . 30 A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 29
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 31 A.7. from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 30
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 31 A.8. from draft-ietf-behave-nat-behavior-discovery-06 . . . . . 30
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 31 A.9. from draft-ietf-behave-nat-behavior-discovery-07 . . . . . 31
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 31 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 32
A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 32
A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 33
A.7. from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 33
A.8. from draft-ietf-behave-nat-behavior-discovery-06 . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34
1. Applicability 1. Applicability
This experimental NAT Behavior Discovery STUN usage provides This experimental NAT Behavior Discovery STUN usage provides
information about a NAT device's observable transient behavior; it information about a NAT device's observable transient behavior; it
determines a NAT's behavior with regard to the STUN server used and determines a NAT's behavior with regard to the STUN server used and
the particular client ports used at the instant the test is run. the particular client ports used at the instant the test is run.
This STUN usage does not allow an application behind a NAT to make an This STUN usage does not allow an application behind a NAT to make an
absolute determination of the NAT's characteristics. NAT devices do absolute determination of the NAT's characteristics. NAT devices do
not behave consistently enough to predict future behaviour with any not behave consistently enough to predict future behaviour with any
skipping to change at page 5, line 48 skipping to change at page 5, line 48
variety of peers. The experimental question is whether such a test variety of peers. The experimental question is whether such a test
is useful. If a node trying to join an overlay as a full peer when is useful. If a node trying to join an overlay as a full peer when
its NAT prevents sufficient connectivity and then withdrawing is its NAT prevents sufficient connectivity and then withdrawing is
expensive or leads to unreliable or poorly performing operation, then expensive or leads to unreliable or poorly performing operation, then
even if the behavior discovery check is only "correct" 75% of the even if the behavior discovery check is only "correct" 75% of the
time, its relative cheapness may make it very useful for optimizing time, its relative cheapness may make it very useful for optimizing
the behavior of the overlay network. Section 2.2 describes this the behavior of the overlay network. Section 2.2 describes this
experimental application in more detail and discusses how to evaluate experimental application in more detail and discusses how to evaluate
its success or failure. its success or failure.
The applications of this STUN usage are very different than the The applications of this STUN usage differ from the original use of
original use of RFC3489 [RFC3489], which was intended for static STUN (originally RFC3489 [RFC3489], now RFC5389 [RFC3489]). This
determination of device behavior. The NAT Behavior Discovery STUN specification acknowledges that the information gathered in this
usage makes an explicit statement that it is not, and cannot be, usage is not, and cannot be, correct 100% of the time, whereas STUN
correct 100% of the time, but is still very useful. More generally, focused only on getting information that could be known to be correct
one of the important differences between 3489 and ICE is that ICE and static.
ensures there is always a fallback to TURN, and thus avoids the
problem experienced by 3489-based applications that tried to This specification can also be compared to ICE. ICE requires a
fallback to TURN be available wheras 3489-based applications tried to
determine in advance whether they would need a relay and what their determine in advance whether they would need a relay and what their
peer reflexive address will be, which are both impossible. This STUN peer reflexive address will be, which is not generally achievable.
usage requires an application using it to have a fallback, but unlike be, which are both impossible. This STUN usage requires an
ICE's focus on the problems inherent in VoIP sessions, doesn't assume application using it to have a fallback, but unlike ICE's focus on
that it will only be used to establish a connection between a single the problems inherent in VoIP sessions, doesn't assume that it will
pair of machines, and so alternative fallback mechanisms may make only be used to establish a connection between a single pair of
sense. For example, in a P2P application it may be possible to machines, and so alternative fallback mechanisms may make sense. For
simply switch out of the role where such connections need to be example, in a P2P application it may be possible to simply switch out
established or to select an alternative indirect route if the peer of the role where such connections need to be established or to
discovers that, in practice, 10% of its connection attempts fail. select an alternative indirect route if the peer discovers that, in
practice, 10% of its connection attempts fail.
It is submitted to the Internet community as an experimental protocol It is submitted to the Internet community as an experimental protocol
that, when applied with appropriate statistical underpinnings and that, when applied with appropriate statistical underpinnings and
application behavior that is ultimately based on experienced application behavior that is ultimately based on experienced
connectivity patterns, can lead to more stability and increased connectivity patterns, can lead to more stability and increased
performance than is available without the knowledge it provides. performance than is available without the knowledge it provides.
If a draft specifies the use of any portion of this STUN usage, that If a standards document specifies the use of any portion of this STUN
draft MUST document how incorrect information derived using these usage, that document MUST describe how incorrect information derived
methods will be managed, either through identifying when a NAT's using these methods will be managed, either through identifying when
behavior changed or because the protocol uses such knowledge as an a NAT's behavior changed or because the protocol uses such knowledge
optimization but remains functional when the NAT's behavior changes. as an optimization but remains functional when the NAT's behavior
changes. The referencing document MUST also define when the fallback
mechanism will be invoked. Applications in different domains may
vary greatly in how agressively the fallback mechanism is utilized,
so there must be a clear defintion of when the fallback mechanism is
invoked.
2. Introduction 2. Introduction
The Simple Traversal Underneath Network Address Translators (STUN) The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a
[RFC5389] provides a mechanism to discover the reflexive transport mechanism to discover the reflexive transport address toward the STUN
address toward the STUN server, using the Binding Request. This server, using the Binding Request. This specification defines the
specification defines the NAT Behavior Discovery STUN usage, which NAT Behavior Discovery STUN usage, which allows a STUN client to
allows a STUN client to probe the current behaviour of the NAT/FW probe the current behaviour of the NAT/Firewall devices between the
devices between the client and the STUN server. This usage defines client and the STUN server. This usage defines new STUN attributes
new STUN attributes for the Binding Request and Binding Response. for the Binding 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 9, line 16 skipping to change at page 9, line 21
based on the results of Behavior Discovery probing. based on the results of Behavior Discovery probing.
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 applications implementing open This draft is experimental as 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, anecdotal that these three requirements have been met. However, anecdotal
evidence suggests that NATs targeted at households and small evidence suggests that NATs targeted at households and small
businesses have stable behaviour, especially when there are few businesses have stable behaviour, especially when there are few
clients behind them. Numerous P2P applications have been deployed clients behind them. Numerous P2P applications have been deployed
that appear to have these properties, although their protocols have that appear to have these properties, although their protocols have
not 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:
skipping to change at page 10, line 29 skipping to change at page 10, line 35
Because the STUN forbids a server from creating a new TCP or TCP/TLS 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 connection to the client, many tests apply only to UDP. The
applicability of the various tests is indicated below. 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 . and 7.
3.1. Determining NAT Mapping 3.1. Determining NAT Mapping
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 mapping[RFC4787]. The client performs a series of and port-dependent mapping[RFC4787]. The client performs a series of
tests that make use of the OTHER-ADDRESS attribute; these tests are tests that make use of the OTHER-ADDRESS attribute; these tests are
described in detail in Section 4. These tests send binding requests described in detail in Section 4. These tests send binding requests
to the alternate address and port of the STUN server to determine to the alternate address and port of the STUN server to determine
mapping behaviour. These tests can be used for UDP, TCP, or TCP/TLS mapping behaviour. These tests can be used for UDP, TCP, or TCP/TLS
skipping to change at page 11, line 24 skipping to change at page 11, line 35
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.
A normal request-response protocol cannot be used to test binding A normal request-response protocol cannot be used to test binding
lifetime because the initial request resets the binding timer. lifetime because the initial request resets the binding timer.
Behavior Discover defines the XOR-RESPONSE-TARGET attribute to allow Behavior Discover defines the RESPONSE-PORT attribute to allow the
the client and server to set up a "control channel" using one port on client and server to set up a "control channel" using one port on the
the client that is used to test the binding lifetime of a different client that is used to test the binding lifetime of a different port
port allocated on the client. More generally, XOR-RESPONSE-TARGET allocated on the client. More generally, RESPONSE-PORT allows the
allows the client to allocate two ports and request that responses to client to allocate two ports and request that responses to queries
queries sent from one port be delivered to the other. The client sent from one port be delivered to the other. The client uses its
uses its second port and the STUN server's alternate address to check second port and the STUN server's alternate address to check if an
if an existing binding that hasn't had traffic sent on it is still existing binding that hasn't had traffic sent on it is still open
open after time T. This approach is described in detail in after time T. This approach is described in detail in Section 4.6.
Section 4.6. This test applies only to UDP datagrams. 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 12, line 11 skipping to change at page 12, line 21
not hairpin fragments at all and some platforms discard fragments not hairpin fragments at all and some platforms discard fragments
under load. To diagnose this behavior, STUN messages may be sent under load. To diagnose this behavior, STUN messages may be sent
with the PADDING attribute, which simply inserts additional space with the PADDING attribute, which simply inserts additional space
into the message. By forcing the STUN message to be divided into into the message. By forcing the STUN message to be divided into
multiple fragments, the NAT's behavior can be observed. multiple fragments, the NAT's behavior can be observed.
All of the previous tests can be performed with PADDING if a NAT's All of the previous tests can be performed with PADDING if a NAT's
fragment behavior is important for an application, or only those fragment behavior is important for an application, or only those
tests which are most interesting to the application can be retested. tests which are most interesting to the application can be retested.
PADDING only applies to UDP datagrams. PADDING can not be used with PADDING only applies to UDP datagrams. PADDING can not be used with
XOR-RESPONSE-TARGET. RESPONSE-PORT.
3.6. Detecting Generic ALGs 3.6. Detecting a Generic Application Level Gateways (ALG)
A number of NAT boxes are now being deployed into the market which A number of NAT boxes are now being deployed into the market which
try to provide "generic" ALG functionality. These generic ALGs hunt try to provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This behavior can be detected rewrite them if they match a binding. This behavior can be detected
because the STUN server returns both the MAPPED-ADDRESS and XOR- because the STUN server returns both the MAPPED-ADDRESS and XOR-
MAPPED-ADDRESS in the same response. If the result in the two does MAPPED-ADDRESS in the same response. If the result in the two does
not match, there is a NAT with a generic ALG in the path. This test not match, there is a NAT with a generic ALG in the path. This test
apples to UDP and TCP, but not TLS over TCP connections. apples to UDP and TCP, but not TLS over TCP connections.
skipping to change at page 15, line 52 skipping to change at page 16, line 11
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 combining and parallelizing tests, due to the Care must be taken when combining and parallelizing tests, due to the
sensitivity of certain tests to prior state on the NAT and because sensitivity of certain tests to prior state on the NAT and because
some NAT devices have an upper limit on how quickly bindings will be some NAT devices have an upper limit on how quickly bindings will be
allocated. Section Section 5 restricts the rate at which clients may allocated. Section 5 restricts the rate at which clients may begin
begin new STUN transactions. new STUN transactions.
4.6. 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. Such tests are sensitive to prior state on the NAT. For by the NAT. Such tests are sensitive to prior state on the NAT. For
many NAT devices, an absolute refresh interval cannot be determined; many NAT devices, an absolute refresh interval cannot be determined;
bindings might be closed quicker under heavy load or might not behave bindings might be closed quicker under heavy load or might not behave
as the tests suggest. For this reason applications that require as the tests suggest. For this reason applications that require
reliable bindings must send keep-alives as frequently as required by reliable bindings must send keep-alives as frequently as required by
all NAT devices that will be encountered. Suggested refresh all NAT devices that will be encountered. Suggested refresh
skipping to change at page 16, line 39 skipping to change at page 16, line 47
lifetime. 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 source port, X. This creates Request to the server from a particular source port, X. This creates
a binding in the NAT. The response from the server contains a a binding in the NAT. The response from the server contains a
MAPPED-ADDRESS attribute, providing the public address and port on MAPPED-ADDRESS attribute, providing the public address and port on
the NAT. Call this Pa and Pp, respectively. The client then starts the NAT. Call this Pa and Pp, respectively. The client then starts
a timer with a value of T seconds. When this timer fires, the client a timer with a value of T seconds. When this timer fires, the client
sends another Binding Request to the server, using the same sends another Binding Request to the server, using the same
destination address and port, but from a different source port, Y. destination address and port, but from a different source port, Y.
This request contains an XOR-RESPONSE-TARGET address attribute, set This request contains an RESPONSE-PORT attribute, set to Pp, to
to (Pa,Pp), to request the response be delivered to (Pa,Pp). This request the response be delivered to (Pa,Pp). This will create a new
will create a new binding on the NAT, and cause the STUN server to binding on the NAT, and cause the STUN server to send a Binding
send a Binding Response that would match the old binding, (Pa,Pp), if Response that would match the old binding, (Pa,Pp), if it still
it still exists. If the client receives the Binding Response on port exists. If the client receives the Binding Response on port X, it
X, it knows that the binding has not expired. If the client receives knows that the binding has not expired. If the client receives the
the Binding Response on port Y (which is possible if the old binding Binding Response on port Y (which is possible if the old binding
expired, and the NAT allocated the same public address and port to expired, and the NAT allocated the same public address and port to
the new binding), or receives no response at all, it knows that the the new binding), or receives no response at all, it knows 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 from the original sent, the client must resend a binding request from the original
source port before beginning a second test with a different value of source port before beginning a second test with a different value of
T. The client can find the value of the binding lifetime by doing a T. The client can find the value of the binding lifetime by doing a
binary search through T, arriving eventually at the value where the binary search through T, arriving eventually at the value where the
response is not received for any timer greater than T, but is response is not received for any timer greater than T, but is
skipping to change at page 17, line 46 skipping to change at page 18, line 7
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 [RFC5389] are followed. Usage [RFC5389] are followed.
If a client intends to utilize an XOR-RESPONSE-TARGET attribute in As support for RESPONSE-PORT is optional a client MUST be prepared to
future transactions, as described in Section 4.6, then it MUST receive a 420 (Unknown Attribute) error to requests that include
include a CACHE-TIMEOUT attribute in the Request with the value set RESPONSE-PORT. Support for OTHER-ADDRESS and CHANGE-REQUEST is
greater than the longest time duration it intends to test. The optional, but MUST be supported by servers advertised via SRV, as
server will also include this attribute in its Response, modified described below. This is to allow the use of PADDING and RESPONSE-
with its estimate of how long it will be able to cache this PORT in applications where servers do not have multiple IP addresses.
connection. Because the returned value is only an estimate, the Clients MUST be prepared to receive a 420 for requests that include
client must be prepared for the value to be wrong, and therefore to CHANGE-REQUEST when OTHER-ADDRESS was not received in Binding
receive a 481 response to its subsequent Requests with XOR-RESPONSE- Response messages from the server.
TARGET.
Support for XOR-RESPONSE-TARGET is optional due to the state cost on
the server. Therefore, a client MUST be prepared to receive a 420
(Unknown Attribute) error to requests that include XOR-RESPONSE-
TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE-
REQUEST is optional, but MUST be supported by servers advertised via
SRV, as described below. This is to allow the use of PADDING and
XOR-RESPONSE-TARGET in applications where servers do not have
multiple IP addresses. Clients MUST be prepared to receive a 420 for
requests that include CHANGE-REQUEST when OTHER-ADDRESS was not
received in Binding Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage 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 equal to the MTU of the outgoing When PADDING is used, it SHOULD be equal to the MTU of the outgoing
interface. interface.
skipping to change at page 19, line 4 skipping to change at page 18, line 48
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"
for UDP and TCP. The service name is "stun-behaviors" for TLS over for UDP and TCP. The service name is "stun-behaviors" for TLS over
TCP. Only "tcp" is defined as a protocol for "stun-behaviors". TCP. Only "tcp" is defined as a protocol for "stun-behaviors".
Other aspects of handling failures and default ports are followed as Other aspects of handling failures and default ports are followed as
described in STUN [RFC5389]. 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. The method for obtaining these credentials,
to perform a Binding Lifetime Discovery test or other test requiring should the server require them, is outside the scope of this usage.
use of the XOR-RESPONSE-TARGET attribute. The method for obtaining Presumably, the administrator or application relying on this usage
these credentials, should the server require them, is outside the should have its own method for obtaining credentials. If the client
scope of this usage. Presumably, the administrator or application receives a 401 (Unauthorized) Response to a Request, then it must
relying on this usage should have its own method for obtaining either acquire the appropriate credential from the application before
credentials. If the client receives a 401 (Unauthorized) Response to retrying or report a permanent failure. Procedures for encoding the
a Request, then it must either acquire the appropriate credential MESSAGE-INTEGRITY attribute for a request are described in STUN
from the application before retrying or report a permanent failure. [RFC5389].
Procedures for encoding the MESSAGE-INTEGRITY attribute for a request
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 [RFC5389] 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 a pair of ports for each of the startup, the server SHOULD allocate a pair of ports for each of the
skipping to change at page 19, line 46 skipping to change at page 19, line 41
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" or "stun-behaviors". 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: RESPONSE-PORT, CHANGE-
CHANGE-REQUEST, CACHE-TIMEOUT, or PADDING. If the Request does not REQUEST, or PADDING. If the Request does not contain any attributes
contain any attributes from this document, OTHER-ADDRESS and from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are still
RESPONSE-ORIGIN are still included in the response. included in the response.
The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in
its Response. its Response.
If the Request contains CHANGE-REQUEST attribute and the server does If the Request contains CHANGE-REQUEST attribute and the server does
not have an alternate address and port as described above, the server not have an alternate address and port as described above, the server
MUST generate an error response of type 420. MUST generate an error response of type 420.
If the Request contains a CACHE-TIMEOUT attribute, then the server
SHOULD include a CACHE-TIMEOUT attribute in its response indicating
the duration (in seconds) it anticipates being able to cache this
binding request in anticipation of a future Request using the XOR-
RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be
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
CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT
provide a CACHE-TIMEOUT length longer than the amount of time it has
been able to cache recent requests.
If XOR-RESPONSE-TARGET is included in a Request, then the server MUST
verify that it has previously received a binding request with CACHE-
TIMEOUT from the 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 having received such a request due to limited state, it
MUST respond with an error response of type 481.
If the Request contains a XOR-RESPONSE-TARGET attribute and the
server is authenticating such requests, then the server checks the
message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they
are not present the server MUST generate an error response of type
401.
Because XOR-RESPONSE-TARGET offers the potential for minor
indirection attacks, a server MUST either authenticate the users
requesting its use or rate-limit its response to those requests, in
addition to verifying that it previously received a binding request
from that address. Rate-limiting is RECOMMENDED even for responses
to authenticated requests 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
that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let
skipping to change at page 21, line 48 skipping to change at page 20, line 52
Response, containing the source address and port used to send the Response, containing the source address and port used to send the
Binding Response. Binding Response.
If the server supports an alternate address and port the server MUST If the server supports an alternate address and port the server MUST
add an OTHER-ADDRESS attribute to the Binding Response. This add an OTHER-ADDRESS attribute to the Binding Response. This
contains the source IP address and port that would be used if the contains the source IP address and port that would be used if the
client had set the "change IP" and "change port" flags in the Binding 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
attribute. If the XOR-RESPONSE-TARGET attribute is included, then it
includes an XOR-REFLECTED-FROM attribute with the source address the
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 SHOULD use a length of included in the Binding Response. The server SHOULD use a length of
PADDING equal to the MTU on the outgoing interface, rounded up to an PADDING equal to the MTU on the outgoing interface, rounded up to an
even multiple of four bytes. If the Request also contains the XOR- even multiple of four bytes. If the Request also contains the
RESPONSE-TARGET attribute the server MUST return an error response of RESPONSE-PORT attribute the server MUST return an error response of
type 400. type 400.
Following that, the server completes the remainder of the processing Following that, the server completes the remainder of the processing
from STUN [RFC5389]. If authentication is being required, the server from STUN [RFC5389]. If authentication is being required, the server
MUST include a MESSAGE-INTEGRITY and associated attributes as MUST include a MESSAGE-INTEGRITY and associated attributes as
appropriate. A FINGERPRINT attribute is only required if the STUN appropriate. A FINGERPRINT attribute is only required if the STUN
messages are being multiplexed with application traffic that requires messages are being multiplexed with application traffic that requires
use of a FINGERPRINT to distinguish STUN messages. use of a FINGERPRINT to distinguish STUN messages.
An ALTERNATE-SERVER attribute MUST NOT be included with any other An ALTERNATE-SERVER attribute MUST NOT be included with any other
attribute defined in this specification. 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 to the source address of the
from the XOR-RESPONSE-TARGET, or to the source address of the Request Request. If RESPONSE-PORT is present the server sends the reponse to
otherwise. that port instead of the originating port.
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 [RFC5389]. 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: RESPONSE-PORT
0x0028: XOR-REFLECTED-FROM
Comprehension-optional range (0x8000-0xFFFF) Comprehension-optional range (0x8000-0xFFFF)
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 IP address and port, it Whenever an attribute contains a transport IP address and port, it
has the same format as MAPPED-ADDRESS. Similarly, the XOR- has the same format as MAPPED-ADDRESS. Similarly, the XOR-
attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389]. attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389].
7.2. CHANGE-REQUEST 7.2. CHANGE-REQUEST
skipping to change at page 23, line 39 skipping to change at page 22, line 39
the Binding Request was received on. the Binding Request was received on.
B: This is the "change port" flag. If true, it requests the server B: This is the "change port" flag. If true, it requests the server
to send the Binding Response with a different port than the one to send the Binding Response with a different port than the one
the Binding Request was received on. the Binding Request was received on.
7.3. RESPONSE-ORIGIN 7.3. RESPONSE-ORIGIN
The RESPONSE-ORIGIN attribute is inserted by the server and indicates The RESPONSE-ORIGIN attribute is inserted by the server and indicates
the source IP address and port the response was sent from. It is the source IP address and port the response was sent from. It is
useful for detecting twice NAT configurations. It is only present in useful for detecting double NAT configurations. It is only present
Binding Responses. in 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 number as CHANGED-ADDRESS from OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from
RFC3489 [RFC3489]because it is simply a new name with the same RFC3489 [RFC3489]because it is simply a new name with the same
semantics as CHANGED-ADDRESS. It has been renamed to more clearly semantics as CHANGED-ADDRESS. It has been renamed to more clearly
indicate its function. indicate its function.
7.5. XOR-REFLECTED-FROM 7.5. RESPONSE-PORT
The XOR-REFLECTED-FROM attribute is present only in Binding Responses
when the Binding Request contained a XOR-RESPONSE-TARGET attribute.
The attribute contains the transport address of the source where the
request came from. Its purpose is to provide traceability, so that a
STUN server cannot be used as a reflector for anonymous denial-of-
service attacks.
The XOR-REFLECTED-FROM attribute is used in place of RFC3489's
REFLECTED-FROM attribute. It provides the same information, but
because the NAT's public address is obfuscated through the XOR
function, It can pass through a NAT that would otherwise attempt to
translate it to the private network address.
7.6. XOR-RESPONSE-TARGET
The XOR-RESPONSE-TARGET attribute contains an IP address and port. The REPONSE-PORT attribute contains a port. The RESPONSE-PORT
The XOR-RESPONSE-TARGET attribute can be present in the Binding attribute can be present in the Binding Request and indicates which
Request and indicates where the Binding Response is to be sent. It port the Binding Response will be sent to. For servers which support
is used in tests such as Section 4.6. When not present, the server the RESPONSE-PORT attribute, the Binding Response MUST be transmited
sends the Binding Response to the source IP address and port of the to the source IP address of the Binding Request and the port
Binding Request. The server MUST NOT process a request containing a contained in RESPONSE-PORT. It is used in tests such as Section 4.6.
XOR-RESPONSE-TARGET and a PADDING attribute. The XOR-RESPONSE-TARGET When not present, the server sends the Binding Response to the source
attribute is optional in the Binding Request. Server support for IP address and port of the Binding Request. The server MUST NOT
XOR-RESPONSE-TARGET is optional. process a request containing a RESPONSE-PORT and a PADDING attribute.
The RESPONSE-PORT attribute is optional in the Binding Request.
Server support for RESPONSE-PORT is optional.
XOR-RESPONSE-TARGET is used in place of RFC3489's RESPONSE-ADDRESS. RESPONSE-PORT is a 16 bit unsigned integer in network byte order
It provides the same information, but because the NAT's public followed by 2 bytes of padding. Allowable values of RESPONSE-PORT
address is obfuscated through the XOR function, It can pass through a are 0-65536.
NAT that would otherwise attempt to translate it to the private
network address.
7.7. PADDING 7.6. 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 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. It SHOULD be equal in length to the MTU of the datagram size to 64K. It SHOULD be equal in length to the MTU of the
outgoing interface, rounded up to an even multiple of four bytes. outgoing interface, rounded up to 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 UDP 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 8. IAB Considerations
The CACHE-TIMEOUT is used in Binding Requests and Responses. It
indicates the time duration (in seconds) that the server will cache
the source address and USERNAME of an original Binding Request that
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
source address of the original Binding Request. A server MUST NOT
send a response to a target address requested with XOR-RESPONSE-
TARGET unless it has cached that the same a previous binding was
received from that target address. The client inserts a value in
CACHE-TIMEOUT into the Binding Request indicating the amount of time
it would like the server to cache that information. The server
responds with a CACHE-TIMEOUT in its Binding Response providing a
prediction of how long it will cache that information. The response
value can be greater than, equal to, or less than the requested
value. If the server is not able to provide such an estimate or the
information in the response would be meaningless, the server SHOULD
NOT include a CACHE-TIMEOUT attribute in its response. Server
support for CACHE-TIMEOUT is optional.
8. New Response Codes
This draft defines two new STUN response codes.
8.1. 481 Connection does not exist
This code is generated when a server has received an XOR-RESPONSE-
TARGET, but the server has no record of having received a prior
Binding Request from the address specified in XOR-RESPONSE-TARGET.
The client SHOULD send a new Binding Request from the address it
intends to specify in an XOR-RESPONSE-TARGET. This new Binding
Request SHOULD include a CACHE-TIMEOUT attribute with the value set
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
This response is generated when a server receives Requests specifying
a particular address in their XOR-RESPONSE-TARGET attribute more
often than one per second.
9. IAB Considerations
The IAB has studied the problem of ``Unilateral Self Address The IAB has studied the problem of ``Unilateral Self Address
Fixing'', which is the general process by which a client attempts to Fixing'', which is the general process by which a client attempts to
determine its address in another realm on the other side of a NAT determine its address in another realm on the other side of a NAT
through a collaborative protocol reflection mechanism RFC 3424 through a collaborative protocol reflection mechanism RFC 3424
[RFC3424]. The STUN NAT Behavior Discovery usage is an example of a [RFC3424]. The STUN NAT Behavior Discovery usage is an example of a
protocol that performs this type of function. The IAB has mandated protocol that performs this type of function. The IAB has mandated
that any protocols developed for this purpose document a specific set that any protocols developed for this purpose document a specific set
of considerations. This section meets those requirements. of considerations. This section meets those requirements.
9.1. Problem Definition 8.1. Problem Definition
From RFC 3424 [RFC3424], any UNSAF proposal must provide: From RFC 3424 [RFC3424], any UNSAF proposal must provide:
Precise definition of a specific, limited-scope problem that is to Precise definition of a specific, limited-scope problem that is to
be solved with the UNSAF proposal. A short term fix should not be be solved with the UNSAF proposal. A short term fix should not be
generalized to solve other problems; this is why "short term fixes generalized to solve other problems; this is why "short term fixes
usually aren't". usually aren't".
The specific problem being solved by the STUN NAT Behavior Discovery The specific problem being solved by the STUN NAT Behavior Discovery
usage is for a client, which may be located behind a NAT of any type, usage is for a client, which may be located behind a NAT of any type,
to determine the instantaneous characteristics of that NAT in order to determine the instantaneous characteristics of that NAT in order
to either diagnose the cause of problems experienced by that or other to either diagnose the cause of problems experienced by that or other
applications or for an application to modify its behavior based on applications or for an application to modify its behavior based on
the current behavior of the NAT and an appropriate statistical model the current behavior of the NAT and an appropriate statistical model
of the behavior required for the application to succeed. of the behavior required for the application to succeed.
9.2. Exit Strategy 8.2. Exit Strategy
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Description of an exit strategy/transition plan. The better short Description of an exit strategy/transition plan. The better short
term fixes are the ones that will naturally see less and less use term fixes are the ones that will naturally see less and less use
as the appropriate technology is deployed. as the appropriate technology is deployed.
The STUN NAT Behavior Discovery usage does not itself provide an exit The STUN NAT Behavior Discovery usage does not itself provide an exit
strategy for v4 NATs. At the time of this writing, it appears some strategy for v4 NATs. At the time of this writing, it appears some
sort of NAT will be necessary between v6 clients and v4 servers, but sort of NAT will be necessary between v6 clients and v4 servers, but
this specification will not be necessary with those v6 to v4 NATs, this specification will not be necessary with those v6 to v4 NATs,
because the IETF is planning to adequately describe their operation. because the IETF is planning to adequately describe their operation.
This specification will be of no interest for v6 to v6 connectivity. This specification will be of no interest for v6 to v6 connectivity.
9.3. Brittleness Introduced by STUN NAT Behavior Discovery 8.3. Brittleness Introduced by STUN NAT Behavior Discovery
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Discussion of specific issues that may render systems more Discussion of specific issues that may render systems more
"brittle". For example, approaches that involve using data at "brittle". For example, approaches that involve using data at
multiple network layers create more dependencies, increase multiple network layers create more dependencies, increase
debugging challenges, and make it harder to transition. debugging challenges, and make it harder to transition.
The STUN NAT Behavior Discovery usage allows a client to determine The STUN NAT Behavior Discovery usage allows a client to determine
the current behavior of a NAT. This information can be quite useful the current behavior of a NAT. This information can be quite useful
skipping to change at page 27, line 26 skipping to change at page 25, line 13
according to the current behavior of the NAT. This draft is according to the current behavior of the NAT. This draft is
experimental because the extent to which brittleness is introduced to experimental because the extent to which brittleness is introduced to
an application relying on the Behavior Discovery usage is unclear and an application relying on the Behavior Discovery usage is unclear and
must be carefully evaluated by the designers of the protocol making must be carefully evaluated by the designers of the protocol making
use of it. The experimental test for this protocol is essentially use of it. The experimental test for this protocol is essentially
determining whether an application can be made less brittle through determining whether an application can be made less brittle through
the use of behavior-discovery information than it would be if the use of behavior-discovery information than it would be if
attempted to make use of the network without any awareness of the attempted to make use of the network without any awareness of the
NATs its traffic must pass through. NATs its traffic must pass through.
9.4. Requirements for a Long Term Solution 8.4. Requirements for a Long Term Solution
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Identify requirements for longer term, sound technical solutions Identify requirements for longer term, sound technical solutions
-- contribute to the process of finding the right longer term -- contribute to the process of finding the right longer term
solution. solution.
As long as v4 NATs are present, means of adapting to their presence As long as v4 NATs are present, means of adapting to their presence
will be required. As described above, well-behaved v6 to v4 NATs and will be required. As described above, well-behaved v6 to v4 NATs and
direct v6 to v6 connections will not require behavior direct v6 to v6 connections will not require behavior
characterization. characterization.
9.5. Issues with Existing NAPT Boxes 8.5. Issues with Existing NAPT Boxes
From [RFC3424], any UNSAF proposal must provide: From [RFC3424], any UNSAF proposal must provide:
Discussion of the impact of the noted practical issues with Discussion of the impact of the noted practical issues with
existing, deployed NA[P]Ts and experience reports. existing, deployed NA[P]Ts and experience reports.
A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt
for IP addresses, either in text or binary form within a packet, and
rewrite them if they match a binding. This usage avoids that problem
by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes
instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes.
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 9. 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". Attributes Registry" and "STUN Error Code Registry".
10.1. STUN Attribute Registry 9.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: RESPONSE-PORT
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 9.2. SRV Registry
This specification defines two new STUN error response codes.
481: Connection does not exist
503: Service Unavailable
10.3. SRV Registry
This specification defines the "stun-behavior" and "stun-behaviors" This specification defines the "stun-behavior" and "stun-behaviors"
SRV service names. "stun-behavior" may be used with SRV protocol SRV service names. "stun-behavior" may be used with SRV protocol
specifiers "udp" and "tcp". "stun-behaviors" may only be specified specifiers "udp" and "tcp". "stun-behaviors" may only be specified
with "tcp". Thus, the allowable SRV queries are: with "tcp". Thus, the allowable SRV queries are:
_stun-behavior._udp UDP _stun-behavior._udp UDP
_stun-behavior._tcp TCP _stun-behavior._tcp TCP
_stun-behaviors._tcp TLS over TCP _stun-behaviors._tcp TLS over TCP
11. Security Considerations 10. 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
from the client. from the client.
XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector o Requests containing both RESPONSE-PORT and PADDING are rejected by
for denial-of-service attacks. It does not provide any amplification the server. This prevents an amplification attack which is
of the attack. The XOR-REFLECTED-FROM mitigates this by providing targeted at the originating address.
the identity (in terms of IP address) of the source where the request
came from. Its purpose is to provide traceability, so that a STUN
server cannot be used as an anonymous reflector for denial-of-service
attacks. To mitigate the security threats of XOR-RESPONSE-TARGET:
o The server MUST NOT respond to requests with XOR-RESPONSE-TARGET
unless they have cached state that a binding request with CACHE-
TIMEOUT has previously been received from the target address.
o The server MUST either authenticate all requests using XOR-
RESPONSE-TARGET or rate-limit its responses to such requests.
Rate-limiting is RECOMMENDED even if authenticating requests,
unless the server is deployed for an application requiring more
frequent responses.
o Requests containing both XOR-RESPONSE-TARGET and PADDING are
rejected by the server.
o Implementing XOR-RESPONSE-TARGET is optional, allowing servers
that cannot store the required state and/or deployed for
applications that don't require its use to automatically reject
any requests containing it.
The only attack possible with the PADDING attribute is to have a The only attack possible with the PADDING attribute is to have a
large padding length which could cause a server to allocate a large large padding length which could cause a server to allocate a large
amount of memory. As servers will ignore any padding length greater amount of memory. As servers will ignore any padding length greater
than 64k so the scope of this attack is limited. In general, servers than 64k so the scope of this attack is limited. In general, servers
should not allocate more memory than the size of the received should not allocate more memory than the size of the received
datagram. This attack would only affect non-compliant datagram. This attack would only affect non-compliant
implementations. implementations.
CHANGE-REQUEST provides no attacks, but adds three more reflection RESPONSE-ORIGIN and RESPONSE-PORT do not provide any additional
sources for the XOR-RESPONSE-TARGET reflection attacks. It provides attacks.
no additional amplification, however, and the security mechanisms for
XOR-RESPONSE-TARGET protect all addresses on the server.
RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide
any additional attacks.
12. Acknowledgements 11. 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. Thanks to Dan Wing, Cullen description in this document originated. Thanks to Dan Wing, Cullen
Jennings, and Magnus Westerlund for detailed comments. Jennings, and Magnus Westerlund for detailed comments.
13. References 12. References
13.1. Normative References 12.1. Normative References
[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, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
13.2. Informative References 12.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., "Managing Client Initiated Connections in Jennings, C., "Managing Client Initiated Connections in
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
skipping to change at page 34, line 14 skipping to change at page 31, line 5
o Additional clarification on the limits of the tests, and that the o Additional clarification on the limits of the tests, and that the
described tests include only those utilizing a single source IP, described tests include only those utilizing a single source IP,
so can't test overloading. so can't test overloading.
o Several changes to clarify and make consistent security o Several changes to clarify and make consistent security
requirements for XOR-RESPONSE-TARGET requirements for XOR-RESPONSE-TARGET
o Numerous other clarifications in response to comments. o Numerous other clarifications in response to comments.
A.9. from draft-ietf-behave-nat-behavior-discovery-07
o Changed XOR-RESPONSE-ADDRESS to RESPONSE-PORT which resulted in
CACHE-TIMEOUT and XOR-REFLECTED-FROM. This resulted in a
simplification of the Security Considerations
o Fixed erroneous STUN expansions
o Clarification of when a fallback mechanism will be used.
o Numerous other clarifications in response to comments.
Authors' Addresses 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.macdonald@gmail.com
Bruce B. Lowekamp Bruce B. Lowekamp
MYMIC LLC MYMIC LLC
1040 University Blvd., Suite 100 1040 University Blvd., Suite 100
Portsmouth, VA 23703 Portsmouth, VA 23703
USA USA
Email: bbl@lowekamp.net Email: bbl@lowekamp.net
 End of changes. 53 change blocks. 
331 lines changed or deleted 182 lines changed or added

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