idnits 2.17.1 draft-ietf-behave-nat-behavior-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 9, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-16 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE D.C. MacDonald 3 Internet-Draft CounterPath Solutions, Inc. 4 Intended status: Experimental B. B. Lowekamp 5 Expires: September 10, 2009 MYMIC LLC 6 March 9, 2009 8 NAT Behavior Discovery Using STUN 9 draft-ietf-behave-nat-behavior-discovery-06 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 10, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 This document may contain material from IETF Documents or IETF 47 Contributions published or made publicly available before November 48 10, 2008. The person(s) controlling the copyright in some of this 49 material may not have granted the IETF Trust the right to allow 50 modifications of such material outside the IETF Standards Process. 51 Without obtaining an adequate license from the person(s) controlling 52 the copyright in such materials, this document may not be modified 53 outside the IETF Standards Process, and derivative works of it may 54 not be created outside the IETF Standards Process, except to format 55 it for publication as an RFC or to translate it into languages other 56 than English. 58 Abstract 60 This specification defines an experimental usage of the Simple 61 Traversal Underneath Network Address Translators (NAT) (STUN) 62 Protocol that discovers the presence and current behaviour of NATs 63 and firewalls between the STUN client and the STUN server. 65 Requirements Language 67 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 68 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 69 document are to be interpreted as described in RFC 2119 [RFC2119]. 71 Table of Contents 73 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 5 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1. Diagnostic Use . . . . . . . . . . . . . . . . . . . . . . 6 76 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 7 77 2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 8 78 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 8 79 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 9 80 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 9 81 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 9 82 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 10 83 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 10 84 3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 10 85 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 11 86 4.1. Source Port Selection . . . . . . . . . . . . . . . . . . 11 87 4.2. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 12 88 4.3. Determining NAT Mapping Behavior . . . . . . . . . . . . . 13 89 4.4. Determining NAT Filtering Behavior . . . . . . . . . . . . 13 90 4.5. Combining and Ordering Tests . . . . . . . . . . . . . . . 14 91 4.6. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 14 92 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 16 93 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 17 94 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 17 96 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 18 97 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 21 98 7.1. Representing Transport Addresses . . . . . . . . . . . . . 21 99 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 21 100 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 22 101 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 22 102 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 22 103 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 22 104 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 23 105 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 23 106 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 24 107 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 24 108 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 24 109 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24 110 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 24 111 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 25 112 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 25 113 9.4. Requirements for a Long Term Solution . . . . . . . . . . 26 114 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 26 115 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 116 10.1. STUN Attribute Registry . . . . . . . . . . . . . . . . . 26 117 10.2. STUN Error Code Registry . . . . . . . . . . . . . . . . . 27 118 10.3. SRV Registry . . . . . . . . . . . . . . . . . . . . . . . 27 120 11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 121 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 122 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 123 13.1. Normative References . . . . . . . . . . . . . . . . . . . 28 124 13.2. Informative References . . . . . . . . . . . . . . . . . . 29 125 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 29 126 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 29 127 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 29 128 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 30 129 A.4. from draft-ietf-behave-nat-behavior-discovery-02 . . . . . 30 130 A.5. from draft-ietf-behave-nat-behavior-discovery-03 . . . . . 31 131 A.6. from draft-ietf-behave-nat-behavior-discovery-04 . . . . . 31 132 A.7. from draft-ietf-behave-nat-behavior-discovery-05 . . . . . 31 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 135 1. Applicability 137 This experimental STUN usage does not allow an application behind a 138 NAT to make an absolute determination of the NAT's characteristics. 139 NAT devices do not behave consistently enough to predict future 140 behaviour with any guarantee. This STUN usage provides information 141 about observable transient behavior; it only truly determines a NAT's 142 behavior with regard to the STUN server used and the particular ports 143 used at the instant the test is run. Applications requiring reliable 144 reach between two particular endpoints must establish a communication 145 channel through a NAT using another technique. IETF has proposed 146 standards including ICE [I-D.ietf-mmusic-ice] and OUTBOUND 147 [I-D.ietf-sip-outbound] for establishing communication channels when 148 a publicly accessible rendezvous service is available. 150 This usage provides techniques which are powerful diagnostic tools in 151 the hands of a network administrator or system programmer trying to 152 determine the causes of network failure; particularly when behavior 153 varies by load, destination, or other factors that may be related to 154 NAT behavior. 156 This draft also proposes experimental applications of NAT Behavior 157 Discovery STUN for real-time selection of parameters for protocols in 158 situations where a publicly accessible rendezvous service is not 159 available. One such application is role selection in P2P networks 160 based on statistical experience with establishing connections and 161 diagnosing NAT behavior with a variety of peers. The experimental 162 question is whether such a test is useful. If a node trying to join 163 an overlay as a full peer when its NAT prevents sufficient 164 connectivity and then withdrawing is expensive or leads to unreliable 165 or poorly performing operation, then even if the behavior discovery 166 check is only "correct" 75% of the time, its relative cheapness may 167 make it very useful for optimizing the behavior of the overlay 168 network. Section 2.2 describes this experimental application in more 169 detail and discusses how to evaluate its success or failure. 171 The applications of this STUN usage are very different than the 172 original use of RFC3489 [RFC3489], which was intended for static 173 determination of device behavior. The NAT Behavior Discovery STUN 174 usage makes an explicit statement that it is not, and cannot be, 175 correct 100% of the time, but is still very useful. It is submitted 176 to the Internet community as an experimental protocol that, when 177 applied with appropriate statistical underpinnings and application 178 behavior that is ultimately based on experienced connectivity 179 patterns, can lead to more stability and increased performance than 180 is available without the knowledge it provides. 182 If a draft specifies the use of any portion of this STUN usage, that 183 draft MUST document how incorrect information derived using these 184 methods will be managed, either through identifying when a NAT's 185 behavior changed or because the protocol uses such knowledge as an 186 optimization but remains functional when the NAT's behavior changes. 188 2. Introduction 190 The Session Traversal Utilities for NAT (STUN) [RFC5389] provides a 191 mechanism to discover the reflexive transport address toward the STUN 192 server, using the Binding Request. This specification defines the 193 NAT Behavior Discovery STUN usage, which allows a STUN client to 194 probe the current behaviour of the NAT/FW devices between the client 195 and the STUN server. This usage defines new STUN attributes for the 196 Binding Request and Binding Response. 198 Many NAT/FW devices do not behave consistently and will change their 199 behaviour under load and over time. Applications requiring high 200 reliability must be prepared for the NAT's behaviour to become more 201 restrictive. Specifically, it has been found that under load NATs 202 may transition to the most restrictive filtering and mapping 203 behaviour and shorten the lifetime of new and existing bindings. In 204 short, applications can discover how bad things currently are, but 205 not how bad things will get. 207 Despite this limitation, instantaneous observations are often quite 208 useful in troubleshooting network problems, and repeated tests over 209 time, or in known load situations, may be used to characterize a 210 NAT's behavior. In particular, in the hands of a person 211 knowledgeable about the needs of an application and the nodes an 212 application needs to communicate with, it can be a powerful tool. 214 2.1. Diagnostic Use 216 Applications that work well in the lab, but fail in a deployment, are 217 notoriously common within distributed systems. There are few systems 218 developers who have not had the experience of searching to determine 219 the difference in the environments for insight as to what real- 220 network behavior was missed in the testing lab. The behavior 221 discovery usage offers a powerful tool that can be used to check NAT 222 and firewall behavior as the application is running. 224 As they are being used to detect instantaneous behavior for analysis 225 by an experienced developer or administrator, there are relatively 226 few concerns about this application of the NAT Behavior Discovery 227 STUN usage. However, the user should be aware that 228 o adding new traffic to new destinations (STUN servers) has the 229 potential to itself change the behavior of a NAT and 231 o the user must be careful to select a STUN server that is 232 appropriately located, ideally collocated (or even integrated) 233 with the communication partners of the application in question, 234 for the results to be applicable to the network conditions 235 experienced by the application. 237 2.2. Example Use with P2P Overlays 239 An application could use Behavior Discovery in a Peer-to-Peer (P2P) 240 protocol to determine if a particular endpoint is a reasonable 241 candidate to participate as a peer or supernode (defined here as a 242 peer in the overlay that offers services, including message routing, 243 to other members or clients of the overlay network). This P2P 244 network application is willing to select supernodes that might be 245 located behind NATs to avoid the cost of dedicated servers. A 246 supernode candidate requires that its NAT(s) offer(s) Endpoint- 247 Independent Filtering. It might periodically re-run tests and would 248 remove itself as a supernode if its NAT/FW chain lost this 249 characteristic. These tests could be run with other supernodes 250 acting as STUN servers as well as with dedicated STUN servers. As 251 many P2P algorithms tolerate non-transitive connectivity between a 252 portion of their peers, guaranteed pair-wise reliable reach might be 253 sacrificed in order to distribute the P2P overlay's load across peers 254 that can be directly contacted by the majority of users. 256 Use of Behavior Discovery for such an application requires: 258 o Specification of protocols capable of offering reliable end-user 259 performance using unreliable links between peers. 261 o The application is deployed behind NATs that provide Endpoint- 262 Independent Filtering and that remain in this mode for an amount 263 of time sufficient for the application to identify their behavior, 264 distribute this information to the rest of the overlay, and 265 provide useful work for the application. 267 This draft is experimental as deployed applications implementing open 268 protocols have yet to be deployed in such environments to demonstrate 269 that these two requirements have been met. However, apocryphal 270 evidence suggests that NATs targeted at households and small 271 businesses have stable behaviour, especially when there are few 272 clients behind them. Numerous P2P applications have been deployed 273 that appear to have these properties, although their protocols have 274 not yet been subjected to rigorous evaluation by standards bodies. 276 2.3. Experimental Success 278 The criteria for an application to successfully demonstrate use of 279 the NAT Behavior Discovery STUN usage would include: 281 o An implementation that relies on this usage to determine its run- 282 time behavior, most likely using it to determine an initial choice 283 of options that are then adjusted based on experience with its 284 network connections. 286 o The implementation must either demonstrate its applicability in 287 environments where it is realistic to expect a provider to deploy 288 dedicated STUN servers with multiple IP addresses, or it must 289 demonstrate duplicating the behavior of such a dedicated STUN 290 server with two nodes that share the role of providing the 291 address-changing operations required by this usage. 293 o Experimental evidence that the application of this usage results 294 in improved behavior of the application in real-world conditions. 295 The exact metrics for this improvement may vary, some 296 possibilities include: faster convergence to the proper 297 parameters, less work to set up initial connections, fewer 298 reconfigurations required after startup, etc. 300 o A protocol specification that defines how the implementation 301 applies this usage. 303 The P2P scenario described above is a likely experimental test case 304 for this usage, but others applications are possible as well. 306 3. Overview of Operations 308 In a typical configuration, a STUN client is connected to a private 309 network and through one or more NATs to the public Internet. The 310 client is configured with the address of a STUN server on the public 311 Internet. The Behavior Discovery usage makes use of SRV records so 312 that a server may use a different transport address for this usage 313 than for other usages. This usage does not provide backward 314 compatibility with RFC3489 [RFC3489] for either clients or servers. 315 Implementors of clients that wish to be compliant with RFC3489 316 servers should see that specification. Implementors of servers 317 SHOULD NOT include support for RFC3489 clients as the original uses 318 of that protocol have been deprecated. 320 Because the STUN forbids a server from creating a new TCP or TCP/TLS 321 connection to the client, many tests apply only to UDP. The 322 applicability of the various tests is indicated below. 324 The STUN NAT Behavior Discovery usage defines new attributes on the 325 STUN Binding Request and STUN Binding Response that allow these 326 messages to be used to diagnose the current behavior of the NAT(s) 327 between the client and server. 329 This section provides a descriptive overview of the typical use of 330 these attributes. Normative behavior is described in Sections 5, 6, 331 7, and 8 . 333 3.1. Determining NAT Mapping 335 A client behind a NAT wishes to determine if the NAT it is behind is 336 currently using endpoint-independent, address-dependent, or address 337 and port-dependent mapping[RFC4787]. The client performs a series of 338 tests that make use of the OTHER-ADDRESS attribute; these tests are 339 described in detail in Section 4. These tests send binding requests 340 to the alternate address and port of the STUN server to determine 341 mapping behaviour. These tests can be used for UDP, TCP, or TCP/TLS 342 connections. 344 3.2. Determining NAT Filtering 346 A client behind a NAT wishes to determine if the NAT it is behind is 347 currently using endpoint-independent, address-dependent, or address 348 and port-dependent filtering[RFC4787]. The client performs a series 349 of tests that make use of the OTHER-ADDRESS and CHANGE-REQUEST 350 attributes; these tests are described in Section 4. These tests 351 request responses from the alternate address and port of the STUN 352 server; a precondition to these tests is that no binding be 353 established to the alternate address and port. See below for more 354 information. Because the NAT does not know that the alternate 355 address and port belong to the same server as the primary address and 356 port, it treats these responses the same as it would those from any 357 other host on the Internet. Therefore, the success of the binding 358 responses sent from the alternate address and port indicate whether 359 the NAT is currently performing endpoint-independent filtering, 360 address-dependent filtering, or address and port-dependent filtering. 361 This test applies only to UDP datagrams. 363 3.3. Binding Lifetime Discovery 365 Many systems, such as VoIP, rely on being able to keep a connection 366 open between a client and server or between peers of a P2P system. 367 Because NAT bindings expire over time, keepalive messages must be 368 sent across the connection to preserve it. Because keepalives impose 369 some overhead on the network and servers, reducing the frequency of 370 keepalives can be useful. 372 Binding lifetime can be discovered by performing timed tests that use 373 XOR-RESPONSE-TARGET. XOR-RESPONSE-TARGET allows the client to 374 allocate two ports and request that responses to queries sent from 375 one port be delivered to the other. The client uses its second port 376 and the STUN server's alternate address to check if an existing 377 binding that hasn't had traffic sent on it is still open after time 378 T. This approach is described in detail in Section 4.6. This test 379 applies only to UDP datagrams. 381 3.4. Diagnosing NAT Hairpinning 383 STUN Binding Requests allow a client to determine whether it is 384 behind a NAT that supports hairpinning of connections. To perform 385 this test, the client first sends a Binding Request to its STUN 386 server to determine its mapped address. The client then sends a STUN 387 Binding Request to this mapped address from a different port. If the 388 client receives its own request, the NAT hairpins connections. This 389 test applies to UDP, TCP, or TCP/TLS connections. 391 3.5. Determining Fragment Handling 393 Some NATs exhibit different behavior when forwarding fragments than 394 when forwarding a single-frame datagram. In particular, some NATs do 395 not hairpin fragments at all and some platforms discard fragments 396 under load. To diagnose this behavior, STUN messages may be sent 397 with the PADDING attribute, which simply inserts additional space 398 into the message. By forcing the STUN message to be divided into 399 multiple fragments, the NAT's behavior can be observed. 401 All of the previous tests can be performed with PADDING if a NAT's 402 fragment behavior is important for an application, or only those 403 tests which are most interesting to the application can be retested. 404 PADDING only applies to UDP datagrams. PADDING can not be used with 405 XOR-RESPONSE-TARGET. 407 3.6. Detecting Generic ALGs 409 A number of NAT boxes are now being deployed into the market which 410 try to provide "generic" ALG functionality. These generic ALGs hunt 411 for IP addresses, either in text or binary form within a packet, and 412 rewrite them if they match a binding. This behavior can be detected 413 because the STUN server returns both the MAPPED-ADDRESS and XOR- 414 MAPPED-ADDRESS in the same response. If the result in the two does 415 not match, there is a NAT with a generic ALG in the path. This test 416 apples to UDP and TCP, but not TLS over TCP connections. 418 4. Discovery Process 420 The NAT Behavior Discovery usage provides primitives that allow STUN 421 checks to be made to determine the current behaviour of the NAT or 422 NATs an application is behind. These tests can only give the 423 instantaneous behaviour of a NAT; it has been found that NATs can 424 change behaviour under load and over time. An application must 425 assume that NAT behaviour can become more restrictive at any time. 426 The tests described here are for UDP connectivity, NAT mapping 427 behaviour, and NAT filtering behaviour; additional tests could be 428 designed using this usage's mechanisms. Definitions for NAT 429 filtering and mapping behaviour are from [RFC4787]. 431 This section provides a descriptive overview of how the primitives 432 provided by the STUN attributes in this specification may be used to 433 perform behavior tests. Normative specifications for the attributes 434 is defined in later sections. 436 4.1. Source Port Selection 438 Proper source port selection is important to ensuring the usefulness 439 and accuracy of the Behavior Discovery tests. There are two 440 preconditions for tests: 442 o Because mapping behavior can vary on a port-by-port basis, an 443 application should perform its tests using the source port 444 intended for use by the application whenever possible. If it 445 intends to use multiple source ports, it should repeat these tests 446 for each source port. Such tests should be performed sequentially 447 to reduce load on the NAT. 449 o Because the results of some diagnostic checks depend on previous 450 state in the NAT created by prior traffic, the tests should be 451 performed using a source port that has not generated recent 452 traffic. Therefore the application should use a random source 453 port or ensure that no traffic has previously occurred on the 454 selected port prior to performing tests, generally by allocating a 455 port and holding it unused for at least 15 minutes prior to the 456 tests. 458 Ensuring both of these preconditions can be challenging, particularly 459 for a device or application wishing to perform Behavior Discovery 460 tests at startup. The following guidelines are suggested for 461 reducing the likelihood of problems: 463 o An application intended to operate behind a NAT should not attempt 464 to allocate a specific or well-known port. Because such software 465 must be designed to interoperate using whatever port is mapped to 466 it by the NAT, the specific port is unnecessary. Instead, on 467 startup a random port should be selected (see below for 468 recommended ranges). An application, particularly on an embedded 469 device, should not rely on the host operating system to select the 470 next available port, because that might result in the application 471 receiving the same port on each restart. An application using the 472 same port between restarts may not receive accurate results from 473 Behavior Discovery tests that are intended to test state-related 474 behavior of NATs, such as filtering and binding lifetime. 476 o An application requiring multiple ports, such as separate ports 477 for control and media, should allocate those ports on startup when 478 possible. Even if there is no immediate need for media flow, if 479 Behavior Discovery tests will be run on those ports, allocating 480 them early will allow them to be left idle, increasing the chance 481 of obtaining accurate results from Behavior Discovery tests. 483 o Although the most reliable results are obtained when performing 484 tests with the specific ports that the application will use, in 485 many cases an application will need to allocate and use ports 486 without being able to perform complete Behavior Discovery tests on 487 those ports. In those cases, an application should randomly 488 select its ports from a range likely to receive the same treatment 489 by the NAT. This document recommends ranges of 32768-49151, which 490 is the upper end of IANA's Registered Ports range, and 49152- 491 65535, which is IANA's Dynamic and/or Private port range, for 492 random selection. To attempt to characterize a NAT's general 493 treatment of ports in these ranges, a small number of ports within 494 a range can be randomly selected and characterized. 496 Those tests particularly sensistive to prior state on a NAT will be 497 indicated below. 499 4.2. Checking if UDP is Blocked 501 The client sends a STUN Binding Request to a server. This causes the 502 server to send the response back to the address and port that the 503 request came from. If this test yields no response, the client knows 504 right away that it is not capable of UDP connectivity. This test 505 requires only STUN [RFC5389] functionality. 507 As with all tests, this test is only deterministic for connectivity 508 with the particular STUN server and source port used. A client 509 should be configured with multiple STUN servers for redundancy and to 510 protect against the configuration specifying an incorrect address for 511 the STUN server. 513 4.3. Determining NAT Mapping Behavior 515 This will require at most three tests. In test I, the client 516 performs the UDP connectivity test. The server will return its 517 alternate address and port in OTHER-ADDRESS in the binding response. 518 If OTHER-ADDRESS is not returned, the server does not support this 519 usage and this test cannot be run. The client examines the XOR- 520 MAPPED-ADDRESS attribute. If this address and port are the same as 521 the local IP address and port of the socket used to send the request, 522 the client knows that it is not NATed and the effective mapping will 523 be Endpoint-Independent. 525 In test II, the client sends a Binding Request to the alternate 526 address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding 527 Response is the same as test I the NAT currently has Endpoint- 528 Independent Mapping. If not, test III is performed: the client sends 529 a Binding Request to the alternate address and port. If the XOR- 530 MAPPED-ADDRESS matches test II, the NAT currently has Address- 531 Dependent Mapping; if it doesn't match it currently has Address and 532 Port-Dependent Mapping. 534 4.4. Determining NAT Filtering Behavior 536 This will also require at most three tests. These tests are 537 sensitive to prior state on the NAT. 539 In test I, the client performs the UDP connectivity test. The server 540 will return its alternate address and port in OTHER-ADDRESS in the 541 binding response. If OTHER-ADDRESS is not returned, the server does 542 not support this usage and this test cannot be run. 544 In test II, the client sends a binding request to the primary address 545 of the server with the CHANGE-REQUEST attribute set to change-port 546 and change-IP. This will cause the server to send its response from 547 its alternate IP address and alternate port. If the client receives 548 a response the current behaviour of the NAT is Endpoint-Independent 549 Filtering. 551 If no response is received, test III must be performed to distinguish 552 between Address-Dependent Filtering and Address and Port-Dependent 553 Filtering. In test III, the client sends a binding request to the 554 original server address with CHANGE-REQUEST set to change-port. If 555 the client receives a response the current behaviour is Address- 556 Dependent Filtering; if no response is received the current behaviour 557 is Address and Port-Dependent Filtering. 559 4.5. Combining and Ordering Tests 561 Clients may wish to combine and parallelize these tests to reduce the 562 number of packets sent and speed the discovery process. For example, 563 test I of the filtering and mapping tests also checks if UDP is 564 blocked. Furthermore, an application or user may not need as much 565 detail as these sample tests provide. For example, establishing 566 connectivity between nodes becomes significantly more difficult if a 567 NAT has any behavior other than endpoint-independent mapping, which 568 requires only test I and II of Section 4.3. An application 569 determining its NAT does not always provide independent mapping might 570 notify the user if no relay is configured, whereas an application 571 behind a NAT that provides endpoint-independent mapping might not 572 notify the user until a subsequent connection actually fails or might 573 provide a less urgent notification that no relay is configured. Such 574 a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but 575 it does provide some information regarding whether ICE is likely to 576 be successful establishing non-relayed connections. 578 Care must be taken when combining and parallelizing tests, due to the 579 sensitivity of certain tests to prior state on the NAT and because 580 some NAT devices have an upper limit on how quickly bindings will be 581 allocated. Section Section 5 restricts the rate at which clients may 582 begin new STUN transactions. 584 4.6. Binding Lifetime Discovery 586 STUN can also be used to probe the lifetimes of the bindings created 587 by the NAT. Such tests are sensitive to prior state on the NAT. For 588 many NAT devices, an absolute refresh interval cannot be determined; 589 bindings might be closed quicker under heavy load or might not behave 590 as the tests suggest. For this reason applications that require 591 reliable bindings must send keep-alives as frequently as required by 592 all NAT devices that will be encountered. Suggested refresh 593 intervals are outside the scope of this document. ICE 594 [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have 595 suggested refresh intervals. 597 Determining the binding lifetime relies on two separate source ports 598 being used to send STUN Binding Requests to the STUN server. The 599 general approach is that the client uses a source port X to send a 600 single Binding Request. After a period of time during which source 601 port X is not used, the client uses a second source port Y to send a 602 Binding Request to the STUN server that indicates the response should 603 be sent to the binding established to port X. If the binding for port 604 X has timed out, that response will not be received. By varying the 605 time between the original Binding Request sent from X and the 606 subsequent request sent from Y, the client can determine the binding 607 lifetime. 609 To determine the binding lifetime, the client first sends a Binding 610 Request to the server from a particular source port, X. This creates 611 a binding in the NAT. The response from the server contains a 612 MAPPED-ADDRESS attribute, providing the public address and port on 613 the NAT. Call this Pa and Pp, respectively. The client then starts 614 a timer with a value of T seconds. When this timer fires, the client 615 sends another Binding Request to the server, using the same 616 destination address and port, but from a different source port, Y. 617 This request contains an XOR-RESPONSE-TARGET address attribute, set 618 to (Pa,Pp), to request the response be delivered to (Pa,Pp). This 619 will create a new binding on the NAT, and cause the STUN server to 620 send a Binding Response that would match the old binding, (Pa,Pp), if 621 it still exists. If the client receives the Binding Response on port 622 X, it knows that the binding has not expired. If the client receives 623 the Binding Response on port Y (which is possible if the old binding 624 expired, and the NAT allocated the same public address and port to 625 the new binding), or receives no response at all, it knows that the 626 binding has expired. 628 Because some NATs only refresh bindings when outbound traffic is 629 sent, the client must resend a binding request from the original 630 source port before beginning a second test with a different value of 631 T. The client can find the value of the binding lifetime by doing a 632 binary search through T, arriving eventually at the value where the 633 response is not received for any timer greater than T, but is 634 received for any timer less than T. Note also that the binding 635 refresh behavior (outbound only or all traffic) can be determined by 636 sending multiple Binding Requests from port Y without refreshes from 637 the original source port X. 639 This discovery process takes quite a bit of time and is something 640 that will typically be run in the background on a device once it 641 boots. 643 It is possible that the client can get inconsistent results each time 644 this process is run. For example, if the NAT should reboot, or be 645 reset for some reason, the process may discover a lifetime than is 646 shorter than the actual one. Binding lifetime may also be dependent 647 on the traffic load on the NAT. For this reason, implementations are 648 encouraged to run the test numerous times and be prepared to get 649 inconsistent results. 651 Like the other diagnostics, this test is inherently unstable. In 652 particular, an overloaded NAT might reduce binding lifetime to shed 653 load. A client might find this diagnostic useful at startup, for 654 example setting the initial keepalive interval on its connection to 655 the server to 10 seconds while beginning this check. After 656 determining the current lifetime, the keepalive interval used by the 657 connection to the server can be set to this appropriate value. 658 Subsequent checks of the binding lifetime can then be performed using 659 the keepalives in the server connection. The STUN Keepalive Usage 660 [I-D.ietf-sip-outbound] provides a response that confirms the 661 connection is open and allows the client to check that its mapped 662 address has not changed. As that provides both the keepalive action 663 and diagnostic that it is working, it should be preferred over any 664 attempt to characterize the connection by a secondary technique. 666 5. Client Behavior 668 Unless otherwise specified here, all procedures for preparing, 669 sending, and processing messages as described in the STUN Binding 670 Usage [RFC5389] are followed. 672 If a client intends to utilize an XOR-RESPONSE-TARGET attribute in 673 future transactions, as described in Section 4.6, then it MUST 674 include a CACHE-TIMEOUT attribute in the Request with the value set 675 greater than the longest time duration it intends to test. The 676 server will also include this attribute in its Response, modified 677 with its estimate of how long it will be able to cache this 678 connection. Because the returned value is only an estimate, the 679 client must be prepared for the value to be wrong, and therefore to 680 receive a 481 response to its subsequent Requests with XOR-RESPONSE- 681 TARGET. 683 Support for XOR-RESPONSE-TARGET is optional due to the state cost on 684 the server. Therefore, a client MUST be prepared to receive a 420 685 (Unknown Attribute) error to requests that include XOR-RESPONSE- 686 TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE- 687 REQUEST is optional, but MUST be supported by servers advertised via 688 SRV, as described below. This is to allow the use of PADDING and 689 XOR-RESPONSE-TARGET in applications where servers do not have 690 multiple IP addresses. Clients MUST be prepared to receive a 420 for 691 requests that include CHANGE-REQUEST when OTHER-ADDRESS was not 692 received in Binding Response messages from the server. 694 If an application makes use of the NAT Behavior Discovery STUN usage 695 by multiplexing it in a flow with application traffic, a FINGERPRINT 696 attribute SHOULD be included unless it is always possible to 697 distinguish a STUN message from an application message based on their 698 header. 700 When PADDING is used, it SHOULD be equal to the MTU of the outgoing 701 interface. 703 Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response 704 unless they are using authentication with a provider of STUN servers 705 that is aware of the topology requirements of the tests being 706 performed. 708 A client SHOULD NOT generate more than ten new STUN transactions per 709 second and SHOULD pace them such that the RTOs do not synchronize the 710 retransmissions of each transaction. 712 5.1. Discovery 714 Unless the user or application is aware of the transport address of a 715 STUN server supporting the NAT Behavior Discovery usage through other 716 means, a client is configured with the domain name of the provider of 717 the STUN servers. The domain is resolved to a transport address 718 using SRV procedures [RFC2782]. The mechanism for configuring the 719 client with the domain name of the STUN servers or of acquiring a 720 specific transport address is out of scope for this document. 722 For the Behavior Discovery Usage the service name is "stun-behavior" 723 for UDP and TCP. The service name is "stun-behaviors" for TLS over 724 TCP. Only "tcp" is defined as a protocol for "stun-behaviors". 725 Other aspects of handling failures and default ports are followed as 726 described in STUN [RFC5389]. 728 5.2. Security 730 Servers MAY require authentication before allowing a client to make 731 use of its services. This is particularly important to requests used 732 to perform a Binding Lifetime Discovery test or other test requiring 733 use of the XOR-RESPONSE-TARGET attribute. The method for obtaining 734 these credentials, should the server require them, is outside the 735 scope of this usage. Presumably, the administrator or application 736 relying on this usage should have its own method for obtaining 737 credentials. If the client receives a 401 (Unauthorized) Response to 738 a Request, then it must either acquire the appropriate credential 739 from the application before retrying or report a permanent failure. 740 Procedures for encoding the MESSAGE-INTEGRITY attribute for a request 741 are described in STUN [RFC5389]. 743 6. Server Behavior 745 Unless otherwise specified here, all procedures for preparing, 746 sending, and processing messages as described for the STUN Binding 747 Usage of STUN [RFC5389] are followed. 749 A server implementing the NAT Behavior Discovery usage SHOULD be 750 configured with two separate IP addresses on the public Internet. On 751 startup, the server SHOULD allocate a pair of ports for each of the 752 UDP, TCP, and TCP/TLS transport protocols, such that it can send and 753 receive datagrams using the same ports on each IP address (normally a 754 wildcard binding accomplishes this). TCP and TCP/TLS MUST use 755 different ports. If a server cannot allocate the same ports on two 756 different IP address, then it MUST NOT include an OTHER-ADDRESS 757 attribute in any Response and MUST respond with a 420 (Unknown 758 Attribute) to any Request with a CHANGE-REQUEST attribute. A server 759 with only one IP address MUST NOT be advertised using the SRV service 760 name "stun-behavior" or "stun-behaviors". 762 6.1. Preparing the Response 764 After performing all authentication and verification steps the server 765 begins processing specific to this Usage if the Request contains any 766 request attributes defined in this document: XOR-RESPONSE-TARGET, 767 CHANGE-REQUEST, CACHE-TIMEOUT, or PADDING. If the Request does not 768 contain any attributes from this document, OTHER-ADDRESS and 769 RESPONSE-ORIGIN are still included in the response. 771 The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in 772 its Response. 774 If the Request contains CHANGE-REQUEST attribute and the server does 775 not have an alternate address and port as described above, the server 776 MUST generate an error response of type 420. 778 If the Request contains a CACHE-TIMEOUT attribute, then the server 779 SHOULD include a CACHE-TIMEOUT attribute in its response indicating 780 the duration (in seconds) it anticipates being able to cache this 781 binding request in anticipation of a future Request using the XOR- 782 RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be 783 greater or less than the value in the request. If the server is not 784 prepared to provide such an estimate, it SHOULD NOT include the 785 CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT 786 provide a CACHE-TIMEOUT length longer than the amount of time it has 787 been able to cache recent requests. 789 If XOR-RESPONSE-TARGET is included in a Request, then the server MUST 790 verify that it has previously received a binding request from the 791 same address as is specified in XOR-RESPONSE-TARGET. If it has not, 792 or if sufficient time has passed that it no longer has a record of 793 having received such a request due to limited state, it MUST respond 794 with an error response of type 481. 796 If the Request contains a XOR-RESPONSE-TARGET attribute and the 797 server is authenticating such requests, then the server checks the 798 message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they 799 are not present the server MUST generate an error response of type 800 401. 802 Because XOR-RESPONSE-TARGET offers the potential for minor 803 indirection attacks, a server MUST either authenticate the users 804 requesting its use or rate-limit its response to those requests. 805 Rate-limiting is RECOMMENDED for responses to authenticated requests 806 unless the server is deployed for an application that requires more 807 frequent responses. If the Request contains a XOR-RESPONSE-TARGET 808 attribute and the server is rate-limiting such requests, it MUST 809 ensure that it does not generate a Response on a particular address 810 more often than one per second. If the server receives requests 811 whose responses are being rate-limited more often than one per 812 second, it MUST generate a 503 (Service unavailable) Response to the 813 Request. 815 The source address and port of the Binding Response depend on the 816 value of the CHANGE-REQUEST attribute and on the address and port the 817 Binding Request was received on, and are summarized in Table 1. 819 Let A1 and A2 be the two IP addresses used by the server and P1 and 820 P2 be the ports used by the server. Let Da represent the destination 821 IP address of the Binding Request (which will be either A1 or A2), 822 and Dp represent the destination port of the Binding Request (which 823 will be either P1 or P2). Let Ca represent the other address, so 824 that if Da is A1, Ca is A2. If Da is A2, Ca is A1. Similarly, let 825 Cp represent the other port, so that if Dp is P1, Cp is P2. If Dp is 826 P2, Cp is P1. If the "change port" flag was set in CHANGE-REQUEST 827 attribute of the Binding Request, and the "change IP" flag was not 828 set, the source IP address of the Binding Response MUST be Da and the 829 source port of the Binding Response MUST be Cp. If the "change IP" 830 flag was set in the Binding Request, and the "change port" flag was 831 not set, the source IP address of the Binding Response MUST be Ca and 832 the source port of the Binding Response MUST be Dp. When both flags 833 are set, the source IP address of the Binding Response MUST be Ca and 834 the source port of the Binding Response MUST be Cp. If neither flag 835 is set, or if the CHANGE-REQUEST attribute is absent entirely, the 836 source IP address of the Binding Response MUST be Da and the source 837 port of the Binding Response MUST be Dp. 839 +--------------------+----------------+-------------+---------------+ 840 | Flags | Source Address | Source Port | OTHER-ADDRESS | 841 +--------------------+----------------+-------------+---------------+ 842 | none | Da | Dp | Ca:Cp | 843 | Change IP | Ca | Dp | Ca:Cp | 844 | Change port | Da | Cp | Ca:Cp | 845 | Change IP and | Ca | Cp | Ca:Cp | 846 | Change port | | | | 847 +--------------------+----------------+-------------+---------------+ 849 Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS 851 The server MUST add a RESPONSE-ORIGIN attribute to the Binding 852 Response, containing the source address and port used to send the 853 Binding Response. 855 If the server supports an alternate address and port the server MUST 856 add an OTHER-ADDRESS attribute to the Binding Response. This 857 contains the source IP address and port that would be used if the 858 client had set the "change IP" and "change port" flags in the Binding 859 Request. As summarized in Table 1, these are Ca and Cp, 860 respectively, regardless of the value of the CHANGE-REQUEST flags. 862 Next the server inspects the Request for a XOR-RESPONSE-TARGET 863 attribute. If the XOR-RESPONSE-TARGET attribute is included, then it 864 includes an XOR-REFLECTED-FROM attribute with the source address the 865 Request was received from. 867 If the Request contained a PADDING attribute, PADDING MUST be 868 included in the Binding Response. The server SHOULD use a length of 869 PADDING equal to the MTU on the outgoing interface. If the Request 870 also contains the XOR-RESPONSE-TARGET attribute the server MUST 871 return an error response of type 400. 873 Following that, the server completes the remainder of the processing 874 from STUN [RFC5389]. If authentication is being required, the server 875 MUST include a MESSAGE-INTEGRITY and associated attributes as 876 appropriate. A FINGERPRINT attribute is only required if the STUN 877 messages are being multiplexed with application traffic that requires 878 use of a FINGERPRINT to distinguish STUN messages. 880 An ALTERNATE-SERVER attribute MUST NOT be included with any other 881 attribute defined in this specification. 883 When the server sends the Response, it is sent from the source 884 address as determined above and to the destination address determined 885 from the XOR-RESPONSE-TARGET, or to the source address of the Request 886 otherwise. 888 7. New Attributes 890 This document defines several STUN attributes that are required for 891 NAT Behavior Discovery. These attributes are all used only with 892 Binding Requests and Binding Responses. CHANGE-REQUEST was 893 originally defined in RFC3489 [RFC3489] but is redefined here as that 894 document is obsoleted by [RFC5389]. 896 Comprehension-required range (0x0000-0x7FFF): 897 0x0003: CHANGE-REQUEST 898 0x0026: PADDING 899 0x0027: XOR-RESPONSE-TARGET 900 0x0028: XOR-REFLECTED-FROM 902 Comprehension-optional range (0x8000-0xFFFF) 903 0x8027: CACHE-TIMEOUT 904 0x802b: RESPONSE-ORIGIN 905 0x802c: OTHER-ADDRESS 907 7.1. Representing Transport Addresses 909 Whenever an attribute contains a transport IP address and port, it 910 has the same format as MAPPED-ADDRESS. Similarly, the XOR- 911 attributes have the same format as XOR-MAPPED-ADDRESS[RFC5389]. 913 7.2. CHANGE-REQUEST 915 The CHANGE-REQUEST attribute contains two flags to control the IP 916 address and port the server uses to send the response. These flags 917 are called the "change IP" and "change port" flags. The CHANGE- 918 REQUEST attribute is allowed only in the Binding Request. The 919 "change IP" and "change port" flags are useful for determining the 920 current filtering behavior of a NAT. They instruct the server to 921 send the Binding Responses from the alternate source IP address 922 and/or alternate port. The CHANGE-REQUEST attribute is optional in 923 the Binding Request. 925 The attribute is 32 bits long, although only two bits (A and B) are 926 used: 927 0 1 2 3 928 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 |0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 A B 0| 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 933 The meanings of the flags are: 935 A: This is the "change IP" flag. If true, it requests the server to 936 send the Binding Response with a different IP address than the one 937 the Binding Request was received on. 939 B: This is the "change port" flag. If true, it requests the server 940 to send the Binding Response with a different port than the one 941 the Binding Request was received on. 943 7.3. RESPONSE-ORIGIN 945 The RESPONSE-ORIGIN attribute is inserted by the server and indicates 946 the source IP address and port the response was sent from. It is 947 useful for detecting twice NAT configurations. It is only present in 948 Binding Responses. 950 7.4. OTHER-ADDRESS 952 The OTHER-ADDRESS attribute is used in Binding Responses. It informs 953 the client of the source IP address and port that would be used if 954 the client requested the "change IP" and "change port" behavior. 955 OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the 956 server has a second IP address. 958 OTHER-ADDRESS uses the same attribute number as CHANGED-ADDRESS from 959 RFC3489 [RFC3489]because it is simply a new name with the same 960 semantics as CHANGED-ADDRESS. It has been renamed to more clearly 961 indicate its function. 963 7.5. XOR-REFLECTED-FROM 965 The XOR-REFLECTED-FROM attribute is present only in Binding Responses 966 when the Binding Request contained a XOR-RESPONSE-TARGET attribute. 967 The attribute contains the transport address of the source where the 968 request came from. Its purpose is to provide traceability, so that a 969 STUN server cannot be used as a reflector for anonymous denial-of- 970 service attacks. 972 The XOR-REFLECTED-FROM attribute is used in place of RFC3489's 973 REFLECTED-FROM attribute. It provides the same information, but 974 because the NAT's public address is obfuscated through the XOR 975 function, It can pass through a NAT that would otherwise attempt to 976 translate it to the private network address. 978 7.6. XOR-RESPONSE-TARGET 980 The XOR-RESPONSE-TARGET attribute contains an IP address and port. 981 The XOR-RESPONSE-TARGET attribute can be present in the Binding 982 Request and indicates where the Binding Response is to be sent. When 983 not present, the server sends the Binding Response to the source IP 984 address and port of the Binding Request. The server MUST NOT process 985 a request containing a XOR-RESPONSE-TARGET that does not contain 986 MESSAGE-INTEGRITY. The XOR-RESPONSE-TARGET attribute is optional in 987 the Binding Request. 989 XOR-RESPONSE-TARGET is used in place of RFC3489's RESPONSE-ADDRESS. 990 It provides the same information, but because the NAT's public 991 address is obfuscated through the XOR function, It can pass through a 992 NAT that would otherwise attempt to translate it to the private 993 network address. 995 7.7. PADDING 997 The PADDING attribute allows for the entire message to be padded to 998 force the STUN message to be divided into IP fragments. PADDING 999 consists entirely of a freeform string, the value of which does not 1000 matter. PADDING can be used in either Binding Requests or Binding 1001 Responses. 1003 PADDING MUST NOT be longer than the length that brings the total IP 1004 datagram size to 64K and SHOULD be an even multiple of four bytes. 1005 Because STUN messages with PADDING are intended to test the behavior 1006 of UDP fragments, they are an exception to the usual rule that STUN 1007 messages be less than the MTU of the path. 1009 7.8. CACHE-TIMEOUT 1011 The CACHE-TIMEOUT is used in Binding Requests and Responses. It 1012 indicates the time duration (in seconds) that the server will cache 1013 the source address and USERNAME of an original binding request that 1014 will later by followed by a request from a different source address 1015 with a XOR-RESPONSE-TARGET asking that a response be reflected to the 1016 source address of the original binding request. A server SHOULD NOT 1017 send a response to a target address requested with XOR-RESPONSE- 1018 TARGET unless it has cached that the same USERNAME made a previous 1019 binding request from that target address. The client inserts a value 1020 in CACHE-TIMEOUT into the Binding Request indicating the amount of 1021 time it would like the server to cache that information. The server 1022 responds with a CACHE-TIMEOUT in its Binding Response providing a 1023 prediction of how long it will cache that information. The response 1024 value can be greater than, equal to, or less than the requested 1025 value. If the server is not able to provide such an estimate or the 1026 information in the response would be meaningless, the server should 1027 not include a CACHE-TIMEOUT attribute in its response. 1029 8. New Response Codes 1031 This draft defines new STUN response code. 1033 8.1. 481 Connection does not exist 1035 This code is generated when a server has received an XOR-RESPONSE- 1036 TARGET, but the server has no record of having received a prior 1037 Binding Request from the address specified in XOR-RESPONSE-TARGET. 1038 The client SHOULD send a new Binding Request from the address it 1039 intends to specify in an XOR-RESPONSE-TARGET. This new Binding 1040 Request SHOULD include a CACHE-TIMEOUT attribute with the value set 1041 to the desired duration. If the server's response includes a CACHE- 1042 TIMEOUT duration that is shorter than the client's requested 1043 duration, the server is unable to satisfy the caching time requested 1044 by the client and the client SHOULD NOT continue to retry the 1045 request. 1047 8.2. 503 Service Unavailable 1049 This response is generated when a server receives Requests specifying 1050 a particular address in their XOR-RESPONSE-TARGET attribute more 1051 often than one per second. 1053 9. IAB Considerations 1055 The IAB has studied the problem of ``Unilateral Self Address 1056 Fixing'', which is the general process by which a client attempts to 1057 determine its address in another realm on the other side of a NAT 1058 through a collaborative protocol reflection mechanism RFC 3424 1059 [RFC3424]. The STUN NAT Behavior Discovery usage is an example of a 1060 protocol that performs this type of function. The IAB has mandated 1061 that any protocols developed for this purpose document a specific set 1062 of considerations. This section meets those requirements. 1064 9.1. Problem Definition 1066 From RFC 3424 [RFC3424], any UNSAF proposal must provide: 1068 Precise definition of a specific, limited-scope problem that is to 1069 be solved with the UNSAF proposal. A short term fix should not be 1070 generalized to solve other problems; this is why "short term fixes 1071 usually aren't". 1073 The specific problem being solved by the STUN NAT Behavior Discovery 1074 usage is for a client, which may be located behind a NAT of any type, 1075 to determine the instantaneous characteristics of that NAT in order 1076 to either diagnose the cause of problems experienced by that or other 1077 applications or for an application to modify its behavior based on 1078 the current behavior of the NAT and an appropriate statistical model 1079 of the behavior required for the application to succeed. 1081 9.2. Exit Strategy 1083 From [RFC3424], any UNSAF proposal must provide: 1085 Description of an exit strategy/transition plan. The better short 1086 term fixes are the ones that will naturally see less and less use 1087 as the appropriate technology is deployed. 1089 The STUN NAT Behavior Discovery usage does not itself provide an exit 1090 strategy for v4 NATs. At the time of this writing, it appears some 1091 sort of NAT will be necessary between v6 clients and v4 servers, but 1092 this specification will not be necessary with those v6 to v4 NATs, 1093 because the IETF is planning to adequately describe their operation. 1094 This specification will be of no interest for v6 to v6 connectivity. 1096 9.3. Brittleness Introduced by STUN NAT Behavior Discovery 1098 From [RFC3424], any UNSAF proposal must provide: 1100 Discussion of specific issues that may render systems more 1101 "brittle". For example, approaches that involve using data at 1102 multiple network layers create more dependencies, increase 1103 debugging challenges, and make it harder to transition. 1105 The STUN NAT Behavior Discovery usage allows a client to determine 1106 the current behavior of a NAT. This information can be quite useful 1107 to a developer or network administrator outside of an application, 1108 and as such can be used to diagnose the brittleness induced in 1109 another application. When used within an application itself, STUN 1110 NAT Behavior Discovery allows the application to adjust its behavior 1111 according to the current behavior of the NAT. This draft is 1112 experimental because the extent to which brittleness is introduced to 1113 an application relying on the Behavior Discovery usage is unclear and 1114 must be carefully evaluated by the designers of the protocol making 1115 use of it. The experimental test for this protocol is essentially 1116 determining whether an application can be made less brittle through 1117 the use of behavior-discovery information than it would be if 1118 attempted to make use of the network without any awareness of the 1119 NATs its traffic must pass through. 1121 9.4. Requirements for a Long Term Solution 1123 From [RFC3424]}, any UNSAF proposal must provide: 1125 Identify requirements for longer term, sound technical solutions 1126 -- contribute to the process of finding the right longer term 1127 solution. 1129 As long as v4 NATs are present, means of adapting to their presence 1130 will be required. As described above, well-behaved v6 to v4 NATs and 1131 direct v6 to v6 connections will not require behavior 1132 characterization. 1134 9.5. Issues with Existing NAPT Boxes 1136 From [RFC3424], any UNSAF proposal must provide: 1138 Discussion of the impact of the noted practical issues with 1139 existing, deployed NA[P]Ts and experience reports. 1141 A number of NAT boxes are now being deployed into the market which 1142 try and provide "generic" ALG functionality. These generic ALGs hunt 1143 for IP addresses, either in text or binary form within a packet, and 1144 rewrite them if they match a binding. This usage avoids that problem 1145 by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes 1146 instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes. 1148 This usage provides a set of generic attributes that can be assembled 1149 to test many types of NAT behavior. While tests for the most 1150 commonly known NAT box behaviors are described, the BEHAVE mailing 1151 list regularly has descriptions of new behaviors, some of which may 1152 not be readily detected using the tests described herein. However, 1153 the techniques described in this usage can be assembled in different 1154 combinations to test NAT behaviors not now known or envisioned. 1156 10. IANA Considerations 1158 This specification requests that IANA make additions to the "STUN 1159 Attributes Registry" and "STUN Error Code Registry". 1161 10.1. STUN Attribute Registry 1163 This specification defines several new STUN attributes. This section 1164 directs IANA to add these new protocol elements to the IANA registry 1165 of STUN protocol elements. 1167 0x0003: CHANGE-REQUEST 1168 0x0027: XOR-RESPONSE-TARGET 1169 0x0028: XOR-REFLECTED-FROM 1170 0x0026: PADDING 1171 0x8027: CACHE-TIMEOUT 1172 0x802b: RESPONSE-ORIGIN 1173 0x802c: OTHER-ADDRESS 1175 10.2. STUN Error Code Registry 1177 This specification defines two new STUN error response codes. 1179 481: Connection does not exist 1180 503: Service Unavailable 1182 10.3. SRV Registry 1184 This specification defines the "stun-behavior" and "stun-behaviors" 1185 SRV service names. "stun-behavior" may be used with SRV protocol 1186 specifiers "udp" and "tcp". "stun-behaviors" may only be specified 1187 with "tcp". Thus, the allowable SRV queries are: 1188 _stun-behavior._udp UDP 1189 _stun-behavior._tcp TCP 1190 _stun-behaviors._tcp TLS over TCP 1192 11. Security Considerations 1194 This usage inherits the security considerations of STUN [RFC5389]. 1195 This usage adds several new attributes; security considerations for 1196 those are detailed here. 1198 OTHER-ADDRESS does not permit any new attacks; it provides another 1199 place where an attacker can impersonate a STUN server but it is not 1200 an interesting attack. An attacker positioned where it can 1201 compromise the Binding Response can completely hide the STUN server 1202 from the client. 1204 XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector 1205 for denial-of-service attacks. It does not provide any amplification 1206 of the attack. The XOR-REFLECTED-FROM mitigates this by providing 1207 the identity (in terms of IP address) of the source where the request 1208 came from. Its purpose is to provide traceability, so that a STUN 1209 server cannot be used as an anonymous reflector for denial-of-service 1210 attacks. XOR-RESPONSE-TARGET is rate-limited or uses pre-existing 1211 credentials to alleviate this threat. Server caching previous 1212 contacts before directing a response to a XOR-RESPONSE-TARGET further 1213 eliminates the threat, although it introduces the complexity of state 1214 into a STUN server. CACHE-TIMEOUT is used to reduce the amount of 1215 additional state required. 1217 The only attack possible with the PADDING attribute is to have a 1218 large padding length which could cause a server to allocate a large 1219 amount of memory. As servers will ignore any padding length greater 1220 than 64k so the scope of this attack is limited. In general, servers 1221 should not allocate more memory than the size of the received 1222 datagram. This attack would only affect non-compliant 1223 implementations. 1225 CHANGE-REQUEST provides no attacks, but adds three more reflection 1226 sources for the XOR-RESPONSE-TARGET reflection attacks. It provides 1227 no additional amplification and the security mechanisms for XOR- 1228 RESPONSE-TARGET are deemed sufficient. 1230 RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide 1231 any additional attacks. 1233 12. Acknowledgements 1235 The authors would like to thank the authors of the original STUN 1236 specification [RFC3489] from which many of the ideas, attributes, and 1237 description in this document originated. Thanks to Dan Wing, Cullen 1238 Jennings, and Magnus Westerlund for detailed comments. 1240 13. References 1242 13.1. Normative References 1244 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1245 Requirement Levels", BCP 14, RFC 2119, March 1997. 1247 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1248 specifying the location of services (DNS SRV)", RFC 2782, 1249 February 2000. 1251 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1252 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1253 RFC 4787, January 2007. 1255 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1256 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1257 October 2008. 1259 13.2. Informative References 1261 [I-D.ietf-mmusic-ice] 1262 Rosenberg, J., "Interactive Connectivity Establishment 1263 (ICE): A Protocol for Network Address Translator (NAT) 1264 Traversal for Offer/Answer Protocols", 1265 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1267 [I-D.ietf-sip-outbound] 1268 Jennings, C. and R. Mahy, "Managing Client Initiated 1269 Connections in the Session Initiation Protocol (SIP)", 1270 draft-ietf-sip-outbound-16 (work in progress), 1271 October 2008. 1273 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1274 Self-Address Fixing (UNSAF) Across Network Address 1275 Translation", RFC 3424, November 2002. 1277 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1278 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1279 Through Network Address Translators (NATs)", RFC 3489, 1280 March 2003. 1282 Appendix A. Change Log 1284 RFC-EDITOR: Please remove this entire Change Log section while 1285 formatting this document for publication. 1287 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 1289 o Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET 1290 support is optional; support for PADDING and SOURCE-ADDRESS is now 1291 mandatory 1293 o PADDING is now a mandatory attribute 1295 o OTHER-ADDRESS is returned in all binding responses if the server 1296 has a second IP address 1298 A.2. from draft-ietf-behave-nat-behavior-discovery-00 1300 o Clarified that only servers with two IP addresses should have an 1301 SRV entry 1303 o Removed support for backward compatibility with 3489 clients by 1304 removing non-XOR forms of attributes. Language states that 1305 backward compatibility with 3489 clients is SHOULD NOT. 1307 Compatibility with 3489 servers is left unspecified. 1309 o PADDING is mandatory and language has been changed to indicate 1310 that if a server supports PADDING it must either actually provide 1311 the padding or return an error (can't support it but refuse to do 1312 it) 1314 o Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned 1315 to support detection of generic ALGs 1317 A.3. from draft-ietf-behave-nat-behavior-discovery-01 1319 o Changed proposed status to experimental 1321 o Made significant changes to the introduction and applicability 1322 statements to reflect the experimental status 1324 o Fixed the New Attributes and IANA considerations not listing the 1325 same attribute numbers. 1327 o Removed mandatory shared secret credentials in favor of the option 1328 of rate limiting or credentials. Specified that credentials must 1329 be obtained from the user or parent application. 1331 o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address 1332 compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as 1333 RESPONSE-ORIGIN to avoid conflicts with 3489. 1335 o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET 1337 o Added discussion of FINGERPRINT and ALTERNATE-SERVER for 1338 compliance with 3489bis stun usage definition requirements. 1340 A.4. from draft-ietf-behave-nat-behavior-discovery-02 1342 o fix terminology for endpoint-independent, address-dependent, and 1343 address and port-dependent from rfc4787 1345 o define the ALG detection to apply to UDP and TCP 1347 o fix >From typo in 9.5 1349 o added exception to single MTU size restriction for PADDING 1351 o removed OPEN ISSUE about CHANGE-REQUEST IANA registry based on the 1352 belief that we need to list that definition here now that 3489bis 1353 is dropping it. 1355 A.5. from draft-ietf-behave-nat-behavior-discovery-03 1357 o moved semantics of PADDING usage into behavior sections rather 1358 than attributes section 1360 o removed reference to SERVER attribute 1362 o removed Open Issues section 1364 o Updated IAB considerations 1366 A.6. from draft-ietf-behave-nat-behavior-discovery-04 1368 o Clarified that behavior may vary by port used as well as by 1369 destination IP/particular STUN server, and therefore specified 1370 that all tests should be performed using the port the application 1371 will use 1373 o Added additional text on selecting random port/ensuring port has 1374 been unused prior to starting filtering tests 1376 o specified limit to start rate of tests and that tests 1377 retransmissions should not synchronize 1379 o additional explanatory text for XOR-RESPONSE-TARGET 1381 o added SRV entry to IANA section and subdivided to match STUN 1382 registries from 5389 1384 o clarified that test combinations are non-normative 1386 o Numerous clarifications 1388 o Changed PADDING to default to interface MTU, and changed maximum 1389 length to not make IP datagram exceed 64K 1391 o Added text that server should allocate TCP and TCP/TLS 1393 A.7. from draft-ietf-behave-nat-behavior-discovery-05 1395 o In applicability section, add explicit requirement that citing 1396 drafts must specify how they handle failure 1398 o Add new subsection on selecting the source port used for tests, 1399 covering both requirements that the same port be used for tests as 1400 for the application and dependencies on previous bindings. 1401 Reference that section explicitly for tests that are sensitive to 1402 previous binding state. 1404 o Change SRV discovery to stun-behavior for UDP and TCP and stun- 1405 behaviors for TLS/TCP. 1407 o Add SRV registry subsection to IANA section. 1409 Authors' Addresses 1411 Derek C. MacDonald 1412 CounterPath Solutions, Inc. 1413 Suite 300, One Bentall Centre, 505 Burrard St 1414 Vancouver, BC V7X1M3 1415 Canada 1417 Phone: +1-604-320-3344 1418 Email: derek@counterpath.com 1420 Bruce B. Lowekamp 1421 MYMIC LLC 1422 200 High St, Suite 308 1423 Portsmouth, VA 23704 1424 USA 1426 Email: bbl@lowekamp.net