draft-ietf-behave-nat-behavior-discovery-03.txt   draft-ietf-behave-nat-behavior-discovery-04.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: August 28, 2008 SIPeerior Technologies and William Expires: January 30, 2009 SIPeerior Technologies, Inc.
& Mary July 29, 2008
February 25, 2008
NAT Behavior Discovery Using STUN NAT Behavior Discovery Using STUN
draft-ietf-behave-nat-behavior-discovery-03 draft-ietf-behave-nat-behavior-discovery-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 36 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 28, 2008. This Internet-Draft will expire on January 30, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
This specification defines an experimental usage of the Simple This specification defines an experimental usage of the Simple
Traversal Underneath Network Address Translators (NAT) (STUN) Traversal Underneath Network Address Translators (NAT) (STUN)
Protocol that discovers the presence and current behaviour of NATs Protocol that discovers the presence and current behaviour of NATs
and firewalls between the STUN client and the STUN server. and firewalls between the STUN client and the STUN server.
Requirements Language Requirements Language
skipping to change at page 2, line 38 skipping to change at page 2, line 32
4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 10 4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 10
4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11 4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11
4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11 4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11
5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 14 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 14
7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 17 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 17
7.1. Representing Transport Addresses . . . . . . . . . . . . . 17 7.1. Representing Transport Addresses . . . . . . . . . . . . . 17
7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 17 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 18
7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 18 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 18
7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 18 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 18
7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 18 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 19
7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 19 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 19
7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 20 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 20
8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 20 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 20
8.1. 481 Connection does not exist . . . . . . . . . . . . . . 20 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 20
8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 20 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 20
9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21
9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21
9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 21 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 21
9.4. Requirements for a Long Term Solution . . . . . . . . . . 22 9.4. Requirements for a Long Term Solution . . . . . . . . . . 22
9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 22 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 22
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23
12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24
14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 13.2. Informative References . . . . . . . . . . . . . . . . . . 25
14.2. Informative References . . . . . . . . . . . . . . . . . . 25
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25
A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 26 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 25
A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 26 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 25
A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26
A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 27 A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 26
A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28 Intellectual Property and Copyright Statements . . . . . . . . . . 28
1. Applicability 1. Applicability
This experimental STUN usage does not allow an application behind a This experimental STUN usage does not allow an application behind a
NAT to make an absolute determination of the NAT's characteristics. NAT to make an absolute determination of the NAT's characteristics.
NAT devices do not behave consistently enough to predict future NAT devices do not behave consistently enough to predict future
behaviour with any guarantee. This STUN usage provides information behaviour with any guarantee. This STUN usage provides information
about observable transient behavior; it only truly determines a NAT's about observable transient behavior; it only truly determines a NAT's
behavior with regard to the STUN server used at the instant the test behavior with regard to the STUN server used at the instant the test
is run. Applications requiring reliable reach between two particular is run. Applications requiring reliable reach between two particular
endpoints must establish a communication channel through a NAT using endpoints must establish a communication channel through a NAT using
another technique. IETF has proposed standards including ICE another technique. IETF has proposed standards including ICE
[I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for
establishing communication channels when a publicly accessible establishing communication channels when a publicly accessible
rendezvous service is available. rendezvous service is available.
This techniques available with this usage are powerful diagnostic This usage provides techniques which are powerful diagnostic tools in
tools in the hands of a network administrator or system programmer the hands of a network administrator or system programmer trying to
trying to determine the causes of network failure, in particular when determine the causes of network failure; particularly when behavior
behavior varies by load, destination, or other factors that may be varies by load, destination, or other factors that may be related to
related to NAT behavior. NAT behavior.
This draft also proposes experimental applications of NAT Behavior This draft also proposes experimental applications of NAT Behavior
Discovery STUN for real-time selection of parameters for protocols in Discovery STUN for real-time selection of parameters for protocols in
situations where a publicly accessible rendezvous service is not situations where a publicly accessible rendezvous service is not
available. One such application is role selection in P2P networks available. One such application is role selection in P2P networks
based on statistical experience with establishing connections and based on statistical experience with establishing connections and
diagnosing NAT behavior with a variety of peers. The experimental diagnosing NAT behavior with a variety of peers. The experimental
question is whether such a test is useful. If a node trying to join question is whether such a test is useful. If a node trying to join
an overlay as a full peer when its NAT prevents sufficient an overlay as a full peer when its NAT prevents sufficient
connectivity and then withdrawing is expensive or leads to unreliable connectivity and then withdrawing is expensive or leads to unreliable
skipping to change at page 6, line 19 skipping to change at page 6, line 19
An application could use Behavior Discovery in a P2P protocol to An application could use Behavior Discovery in a P2P protocol to
determine if a particular endpoint is a reasonable candidate to determine if a particular endpoint is a reasonable candidate to
participate as a peer or supernode (defined here as a peer in the participate as a peer or supernode (defined here as a peer in the
overlay that offers services, including message routing, to other overlay that offers services, including message routing, to other
members or clients of the overlay network). This P2P network members or clients of the overlay network). This P2P network
application is willing to select supernodes that might be located application is willing to select supernodes that might be located
behind NATs to avoid the cost of dedicated servers. A supernode behind NATs to avoid the cost of dedicated servers. A supernode
candidate requires that its NAT(s) offer(s) Endpoint-Independent candidate requires that its NAT(s) offer(s) Endpoint-Independent
Filtering. It might periodically re-run tests and would remove Filtering. It might periodically re-run tests and would remove
itself as a supernode if its NAT/FW chain lost this characteristic. itself as a supernode if its NAT/FW chain lost this characteristic.
These tests could be run with other supernode candidates acting as These tests could be run with other supernodes acting as STUN servers
STUN servers as well as dedicated STUN servers. As many P2P as well as with dedicated STUN servers. As many P2P algorithms
algorithms tolerate non-transitive connectivity between a portion of tolerate non-transitive connectivity between a portion of their
their peers, guaranteed pair-wise reliable reach might be sacrificed peers, guaranteed pair-wise reliable reach might be sacrificed in
in order to distribute the P2P overlay's load across peers that can order to distribute the P2P overlay's load across peers that can be
be directly contacted by the majority of users. directly contacted by the majority of users.
Use of Behavior Discovery for such an application requires: Use of Behavior Discovery for such an application requires:
o Specification of protocols capable of offering reliable end-user o Specification of protocols capable of offering reliable end-user
performance using unreliable links between peers. performance using unreliable links between peers.
o The application is deployed behind NATs that provide Endpoint- o The application is deployed behind NATs that provide Endpoint-
Independent Filtering and that remain in this mode for an amount Independent Filtering and that remain in this mode for an amount
of time sufficient for the application to identify their behavior, of time sufficient for the application to identify their behavior,
distribute this information to the rest of the overlay, and distribute this information to the rest of the overlay, and
skipping to change at page 7, line 51 skipping to change at page 7, line 51
SHOULD NOT include support for RFC3489 clients as the original uses SHOULD NOT include support for RFC3489 clients as the original uses
of that protocol have been deprecated. of that protocol have been deprecated.
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,
and 7. 7, and 8 .
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 13, line 23 skipping to change at page 13, line 23
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
the server. Therefore, a client MUST be prepared for receiving a 420 the server. Therefore, a client MUST be prepared to receive a 420
(Unknown Attribute) error to requests that include XOR-RESPONSE- (Unknown Attribute) error to requests that include XOR-RESPONSE-
TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE- TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE-
REQUEST is optional, but MUST be supported by servers advertised via REQUEST is optional, but MUST be supported by servers advertised via
SRV, as described below. This is to allow the use of PADDING and SRV, as described below. This is to allow the use of PADDING and
XOR-RESPONSE-TARGET in applications where servers do not have XOR-RESPONSE-TARGET in applications where servers do not have
multiple IP addresses. Clients MUST be prepared to receive a 420 for multiple IP addresses. Clients MUST be prepared to receive a 420 for
requests that include CHANGE-REQUEST when OTHER-ADDRESS was not requests that include CHANGE-REQUEST when OTHER-ADDRESS was not
received in Binding Response messages from the server. received in Binding Response messages from the server.
If an application makes use of the NAT Behavior Discovery STUN usage If an application makes use of the NAT Behavior Discovery STUN usage
by multiplexing it in a flow with application traffic, a FINGERPRINT by multiplexing it in a flow with application traffic, a FINGERPRINT
attribute SHOULD be included unless it is always possible to attribute SHOULD be included unless it is always possible to
distinguish a STUN message from an application message based on their distinguish a STUN message from an application message based on their
header. header.
When PADDING is used, it SHOULD be 1500 bytes long, unless a more
appropriate length is known based on the MTU of the path.
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.
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
skipping to change at page 14, line 47 skipping to change at page 14, line 50
include an OTHER-ADDRESS attribute in any Response and MUST respond include an OTHER-ADDRESS attribute in any Response and MUST respond
with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST
attribute. A server with only one IP address MUST NOT be advertised attribute. A server with only one IP address MUST NOT be advertised
using the SRV service name "stun-behavior". using the SRV service name "stun-behavior".
6.1. Preparing the Response 6.1. Preparing the Response
After performing all authentication and verification steps the server After performing all authentication and verification steps the server
begins processing specific to this Usage if the Request contains any begins processing specific to this Usage if the Request contains any
request attributes defined in this document: XOR-RESPONSE-TARGET, request attributes defined in this document: XOR-RESPONSE-TARGET,
CHANGE-REQUEST, or PADDING. If the Request does not contain any CHANGE-REQUEST, CACHE-TIMEOUT, or PADDING. If the Request does not
attributes from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are contain any attributes from this document, OTHER-ADDRESS and
still included in the response. RESPONSE-ORIGIN are still 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 If the Request contains a CACHE-TIMEOUT attribute, then the server
SHOULD include a CACHE-TIMEOUT attribute in its response indicating SHOULD include a CACHE-TIMEOUT attribute in its response indicating
skipping to change at page 15, line 48 skipping to change at page 16, line 5
If the Request contains a XOR-RESPONSE-TARGET attribute and the If the Request contains a XOR-RESPONSE-TARGET attribute and the
server is rate-limiting such requests, it MUST ensure that it does server is rate-limiting such requests, it MUST ensure that it does
not generate a Response on a particular address more often than one not generate a Response on a particular address more often than one
per second. If it receives requests more often than one per second, per second. If it receives requests more often than one per second,
it MUST generate a 503 (Service unavailable) Response to the Request. 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 Da represent the destination IP address of the Binding Request Let A1 and A2 be the two IP addresses used by the server and P1 and
(which will be either A1 or A2), and Dp represent the destination P2 be the ports used by the server. Let Da represent the destination
port of the Binding Request (which will be either P1 or P2). Let Ca IP address of the Binding Request (which will be either A1 or A2),
represent the other address, so that if Da is A1, Ca is A2. If Da is and Dp represent the destination port of the Binding Request (which
A2, Ca is A1. Similarly, let Cp represent the other port, so that if will be either P1 or P2). Let Ca represent the other address, so
Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port" that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let
flag was set in CHANGE-REQUEST attribute of the Binding Request, and Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is
the "change IP" flag was not set, the source IP address of the P2, Cp is P1. If the "change port" flag was set in CHANGE-REQUEST
Binding Response MUST be Da and the source port of the Binding attribute of the Binding Request, and the "change IP" flag was not
Response MUST be Cp. If the "change IP" flag was set in the Binding set, the source IP address of the Binding Response MUST be Da and the
Request, and the "change port" flag was not set, the source IP source port of the Binding Response MUST be Cp. If the "change IP"
address of the Binding Response MUST be Ca and the source port of the flag was set in the Binding Request, and the "change port" flag was
Binding Response MUST be Dp. When both flags are set, the source IP not set, the source IP address of the Binding Response MUST be Ca and
address of the Binding Response MUST be Ca and the source port of the the source port of the Binding Response MUST be Dp. When both flags
Binding Response MUST be Cp. If neither flag is set, or if the are set, the source IP address of the Binding Response MUST be Ca and
CHANGE-REQUEST attribute is absent entirely, the source IP address of the source port of the Binding Response MUST be Cp. If neither flag
the Binding Response MUST be Da and the source port of the Binding is set, or if the CHANGE-REQUEST attribute is absent entirely, the
Response MUST be Dp. source IP address of the Binding Response MUST be Da and the source
port of the Binding Response MUST be Dp.
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
| Flags | Source Address | Source Port | OTHER-ADDRESS | | Flags | Source Address | Source Port | OTHER-ADDRESS |
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
| none | Da | Dp | Ca:Cp | | none | Da | Dp | Ca:Cp |
| Change IP | Ca | Dp | Ca:Cp | | Change IP | Ca | Dp | Ca:Cp |
| Change port | Da | Cp | Ca:Cp | | Change port | Da | Cp | Ca:Cp |
| Change IP and | Ca | Cp | Ca:Cp | | Change IP and | Ca | Cp | Ca:Cp |
| Change port | | | | | Change port | | | |
+--------------------+----------------+-------------+---------------+ +--------------------+----------------+-------------+---------------+
skipping to change at page 16, line 47 skipping to change at page 17, line 5
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 Next the server inspects the Request for a XOR-RESPONSE-TARGET
attribute. If the XOR-RESPONSE-TARGET attribute is included, then it attribute. If the XOR-RESPONSE-TARGET attribute is included, then it
includes an XOR-REFLECTED-FROM attribute with the source address the includes an XOR-REFLECTED-FROM attribute with the source address the
Request was received from. Request was received from.
If the Request contained a PADDING attribute, then the server SHOULD If the Request contained a PADDING attribute, PADDING MUST be
insert a PADDING attribute of the same length into its response, but included in the Binding Response. The server MUST use either the
no longer than 64K. If the Request also contains the XOR-RESPONSE- length of PADDING in the Request or a length it knows is sufficient
TARGET attribute the server MUST return an error response of type to cause fragmentation along the return path. If the Request also
400. contains the XOR-RESPONSE-TARGET attribute the server MUST return an
error response of type 400.
Following that, the server completes the remainder of the processing Following that, the server completes the remainder of the processing
from STUN [I-D.ietf-behave-rfc3489bis]. The server MAY include a from STUN [I-D.ietf-behave-rfc3489bis]. If authentication is being
SERVER attribute. If authentication is being required, the server required, the server MUST include a MESSAGE-INTEGRITY and associated
MUST include a MESSAGE-INTEGRITY and associated attributes as attributes as appropriate. A FINGERPRINT attribute is only required
appropriate. A FINGERPRINT attribute is only required if the STUN if the STUN messages are being multiplexed with application traffic
messages are being multiplexed with application traffic that requires that requires use of a FINGERPRINT to distinguish STUN messages. An
use of a FINGERPRINT to distinguish STUN messages. An ALTERNATE- ALTERNATE-SERVER attribute SHOULD NOT be included.
SERVER attribute SHOULD NOT be included.
When the server sends the Response, it is sent from the source When the server sends the Response, it is sent from the source
address as determined above and to the destination address determined address as determined above and to the destination address determined
from the XOR-RESPONSE-TARGET, or to the source address of the Request from the XOR-RESPONSE-TARGET, or to the source address of the Request
otherwise. otherwise.
7. New Attributes 7. New Attributes
This document defines several STUN attributes that are required for This document defines several STUN attributes that are required for
NAT Behavior Discovery. These attributes are all used only with NAT Behavior Discovery. These attributes are all used only with
skipping to change at page 19, line 34 skipping to change at page 19, line 42
It provides the same information, but because the NAT's public It provides the same information, but because the NAT's public
address is obfuscated through the XOR function, It can pass through a address is obfuscated through the XOR function, It can pass through a
NAT that would otherwise attempt to translate it to the private NAT that would otherwise attempt to translate it to the private
network address. network address.
7.7. PADDING 7.7. PADDING
The PADDING attribute allows for the entire message to be padded to The PADDING attribute allows for the entire message to be padded to
force the STUN message to be divided into IP fragments. PADDING force the STUN message to be divided into IP fragments. PADDING
consists entirely of a freeform string, the value of which does not consists entirely of a freeform string, the value of which does not
matter. When PADDING is used, it SHOULD be 1500 bytes long, unless a matter. PADDING can be used in either Binding Requests or Binding
more appropriate length is known based on the MTU of the path. Responses.
PADDING can be used in either Binding Requests or Binding Responses.
If PADDING is present in the Binding Request and the server supports
it, PADDING MUST be present in the Binding Response. The server
SHOULD use the same length PADDING as was used in the Binding
Request, but it MAY use another length if it knows what length is
required to cause fragmentation along the return path. If the server
supports PADDING (i.e. doesn't return a 420 in response to a Request
containing PADDING), then it MUST use either the requested length or
a length it knows is sufficient to cause fragmentation.
PADDING MUST be no longer than 64K and SHOULD be an even multiple of PADDING MUST be no longer than 64K and SHOULD be an even multiple of
four bytes. Because STUN messages with PADDING are intended to test four bytes. Because STUN messages with PADDING are intended to test
the behavior of UDP fragments, they are an exception to the usual the behavior of UDP fragments, they are an exception to the usual
rule that STUN messages be less than the MTU of the path. rule that STUN messages be less than the MTU of the path.
7.8. CACHE-TIMEOUT 7.8. CACHE-TIMEOUT
The CACHE-TIMEOUT is used in Binding Requests and Responses. It The CACHE-TIMEOUT is used in Binding Requests and Responses. It
indicates the time duration (in seconds) that the server will cache indicates the time duration (in seconds) that the server will cache
skipping to change at page 21, line 36 skipping to change at page 21, line 36
9.2. Exit Strategy 9.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. Instead, that is provided by other initiatives. Work is strategy for v4 NATs. At the time of this writing, it appears some
currently proceeding on proposals for protocols that allow clients to sort of NAT will be necessary between v6 clients and v4 servers, but
determine the location of and control the behavior of NATs through this specification will not be necessary with those v6 to v4 NATs,
direct interaction with the NAT; Nat Control STUN Usage because the IETF is planning to adequately describe their operation.
[I-D.wing-behave-nat-control-stun-usage] STUN NAT Behavior Discovery This specification will be of no interest for v6 to v6 connectivity.
is no longer needed once NATs that can be communicated with directly
are in use. Finally, as NATs phase out and as IPv6 is deployed, STUN
NAT Behavior Discovery will no longer be of any interest.
9.3. Brittleness Introduced by STUN NAT Behavior Discovery 9.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.
skipping to change at page 22, line 34 skipping to change at page 22, line 27
NATs its traffic must pass through. NATs its traffic must pass through.
9.4. Requirements for a Long Term Solution 9.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 NATs are present, means of adapting to their presence will As long as v4 NATs are present, means of adapting to their presence
be required. Direct control or discovery of NATs by applications, will be required. As described above, well-behaved v6 to v4 NATs and
such as proposed in Nat Control STUN Usage direct v6 to v6 connections will not require behavior
[I-D.wing-behave-nat-control-stun-usage], will eliminate the need for characterization.
anonymous diagnostics of NAT behavior.
9.5. Issues with Existing NAPT Boxes 9.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 A number of NAT boxes are now being deployed into the market which
try and provide "generic" ALG functionality. These generic ALGs hunt try and provide "generic" ALG functionality. These generic ALGs hunt
skipping to change at page 23, line 41 skipping to change at page 23, line 34
11. Security Considerations 11. Security Considerations
This usage inherits the security considerations of STUN This usage inherits the security considerations of STUN
[I-D.ietf-behave-rfc3489bis]. This usage adds several new [I-D.ietf-behave-rfc3489bis]. This usage adds several new
attributes; security considerations for those are detailed here. attributes; security considerations for 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 Request can completely hide the STUN server compromise the Binding Response can completely hide the STUN server
from the client. from the client.
XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector
for denial-of-service attacks. It does not provide any amplification for denial-of-service attacks. It does not provide any amplification
of the attack. The XOR-REFLECTED-FROM mitigates this by providing of the attack. The XOR-REFLECTED-FROM mitigates this by providing
the identity (in terms of IP address) of the source where the request 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 came from. Its purpose is to provide traceability, so that a STUN
server cannot be used as an anonymous reflector for denial-of-service server cannot be used as an anonymous reflector for denial-of-service
attacks. XOR-RESPONSE-TARGET is rate-limited or uses pre-existing attacks. XOR-RESPONSE-TARGET is rate-limited or uses pre-existing
credentials to alleviate this threat. Server caching previous credentials to alleviate this threat. Server caching previous
skipping to change at page 24, line 26 skipping to change at page 24, line 21
implementations. implementations.
CHANGE-REQUEST provides no attacks, but adds three more reflection CHANGE-REQUEST provides no attacks, but adds three more reflection
sources for the XOR-RESPONSE-TARGET reflection attacks. It provides sources for the XOR-RESPONSE-TARGET reflection attacks. It provides
no additional amplification and the security mechanisms for XOR- no additional amplification and the security mechanisms for XOR-
RESPONSE-TARGET are deemed sufficient. RESPONSE-TARGET are deemed sufficient.
RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide
any additional attacks. any additional attacks.
12. Open Issues 12. Acknowledgements
Does IANA consider attributes that were in 3489 but not in 3489bis to
have been removed from the registry and should be re-registered by
this document, or are there forever in the registry from 3489?
13. Acknowledgements
The authors would like to thank the authors of the original STUN The authors would like to thank the authors of the original STUN
specification [RFC3489] from which many of the ideas, attributes, and specification [RFC3489] from which many of the ideas, attributes, and
description in this document originated. description in this document originated.
14. References 13. References
14.1. Normative References 13.1. Normative References
[I-D.ietf-behave-rfc3489bis] [I-D.ietf-behave-rfc3489bis]
Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for (NAT) (STUN)", "Session Traversal Utilities for (NAT) (STUN)",
draft-ietf-behave-rfc3489bis-15 (work in progress), draft-ietf-behave-rfc3489bis-18 (work in progress),
February 2008. July 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
14.2. Informative References 13.2. Informative References
[I-D.ietf-mmusic-ice] [I-D.ietf-mmusic-ice]
Rosenberg, J., "Interactive Connectivity Establishment Rosenberg, J., "Interactive Connectivity Establishment
(ICE): A Protocol for Network Address Translator (NAT) (ICE): A Protocol for Network Address Translator (NAT)
Traversal for Offer/Answer Protocols", Traversal for Offer/Answer Protocols",
draft-ietf-mmusic-ice-19 (work in progress), October 2007. draft-ietf-mmusic-ice-19 (work in progress), October 2007.
[I-D.ietf-sip-outbound] [I-D.ietf-sip-outbound]
Jennings, C. and R. Mahy, "Managing Client Initiated Jennings, C. and R. Mahy, "Managing Client Initiated
Connections in the Session Initiation Protocol (SIP)", Connections in the Session Initiation Protocol (SIP)",
draft-ietf-sip-outbound-11 (work in progress), draft-ietf-sip-outbound-15 (work in progress), June 2008.
November 2007.
[I-D.wing-behave-nat-control-stun-usage]
Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering,
Querying, and Controlling Firewalls and NATs",
draft-wing-behave-nat-control-stun-usage-05 (work in
progress), October 2007.
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral
Self-Address Fixing (UNSAF) Across Network Address Self-Address Fixing (UNSAF) Across Network Address
Translation", RFC 3424, November 2002. Translation", RFC 3424, November 2002.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "STUN - Simple Traversal of User Datagram Protocol (UDP)
Through Network Address Translators (NATs)", RFC 3489, Through Network Address Translators (NATs)", RFC 3489,
March 2003. March 2003.
skipping to change at page 27, line 25 skipping to change at page 27, line 5
o define the ALG detection to apply to UDP and TCP o define the ALG detection to apply to UDP and TCP
o fix >From typo in 9.5 o fix >From typo in 9.5
o added exception to single MTU size restriction for PADDING o added exception to single MTU size restriction for PADDING
o removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the o removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the
belief that we need to list that definition here now that 3489bis belief that we need to list that definition here now that 3489bis
is dropping it. is dropping it.
A.5. from draft-ietf-behave-nat-behavior-discovery-03
o moved semantics of PADDING usage into behavior sections rather
than attributes section
o removed reference to SERVER attribute
o removed Open Issues section
o Updated IAB considerations
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 and William & Mary SIPeerior Technologies, Inc.
3000 Easter Circle 3000 Easter Circle
Williamsburg, Virginia 23188 Williamsburg, Virginia 23188
USA USA
Phone: +1-757-565-0101 Phone: +1-757-565-0101
Email: lowekamp@sipeerior.com Email: lowekamp@sipeerior.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
skipping to change at page 28, line 44 skipping to change at line 1259
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 30 change blocks. 
111 lines changed or deleted 95 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/