idnits 2.17.1 draft-ietf-behave-nat-behavior-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1243. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1250. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1256. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 17, 2007) is 6005 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-12 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-10 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE D. MacDonald 3 Internet-Draft CounterPath Solutions, Inc. 4 Intended status: Experimental B. Lowekamp 5 Expires: May 20, 2008 SIPeerior Technologies and William 6 & Mary 7 November 17, 2007 9 NAT Behavior Discovery Using STUN 10 draft-ietf-behave-nat-behavior-discovery-02 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on May 20, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This specification defines an experimental usage of the Simple 44 Traversal Underneath Network Address Translators (NAT) (STUN) 45 Protocol that discovers the presence and current behaviour of NATs 46 and firewalls between the STUN client and the STUN server. 48 Requirements Language 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC 2119 [RFC2119]. 54 Table of Contents 56 1. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 2.1. Diagnostic Use . . . . . . . . . . . . . . . . . . . . . . 5 59 2.2. Example Use with P2P Overlays . . . . . . . . . . . . . . 6 60 2.3. Experimental Success . . . . . . . . . . . . . . . . . . . 6 61 3. Overview of Operations . . . . . . . . . . . . . . . . . . . . 7 62 3.1. Determining NAT Mapping . . . . . . . . . . . . . . . . . 8 63 3.2. Determining NAT Filtering . . . . . . . . . . . . . . . . 8 64 3.3. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 8 65 3.4. Diagnosing NAT Hairpinning . . . . . . . . . . . . . . . . 9 66 3.5. Determining Fragment Handling . . . . . . . . . . . . . . 9 67 3.6. Detecting Generic ALGs . . . . . . . . . . . . . . . . . . 9 68 4. Discovery Process . . . . . . . . . . . . . . . . . . . . . . 9 69 4.1. Checking if UDP is Blocked . . . . . . . . . . . . . . . . 10 70 4.2. Determining NAT Mapping Behavior . . . . . . . . . . . . . 10 71 4.3. Determining NAT Filtering Behavior . . . . . . . . . . . . 10 72 4.4. Combining and Ordering Tests . . . . . . . . . . . . . . . 11 73 4.5. Binding Lifetime Discovery . . . . . . . . . . . . . . . . 11 74 5. Client Behavior . . . . . . . . . . . . . . . . . . . . . . . 13 75 5.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 13 76 5.2. Security . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Server Behavior . . . . . . . . . . . . . . . . . . . . . . . 14 78 6.1. Preparing the Response . . . . . . . . . . . . . . . . . . 14 79 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 17 80 7.1. Representing Transport Addresses . . . . . . . . . . . . . 17 81 7.2. CHANGE-REQUEST . . . . . . . . . . . . . . . . . . . . . . 17 82 7.3. RESPONSE-ORIGIN . . . . . . . . . . . . . . . . . . . . . 18 83 7.4. OTHER-ADDRESS . . . . . . . . . . . . . . . . . . . . . . 18 84 7.5. XOR-REFLECTED-FROM . . . . . . . . . . . . . . . . . . . . 18 85 7.6. XOR-RESPONSE-TARGET . . . . . . . . . . . . . . . . . . . 19 86 7.7. PADDING . . . . . . . . . . . . . . . . . . . . . . . . . 19 87 7.8. CACHE-TIMEOUT . . . . . . . . . . . . . . . . . . . . . . 20 88 8. New Response Codes . . . . . . . . . . . . . . . . . . . . . . 20 89 8.1. 481 Connection does not exist . . . . . . . . . . . . . . 20 90 8.2. 503 Service Unavailable . . . . . . . . . . . . . . . . . 20 91 9. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 92 9.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21 93 9.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21 94 9.3. Brittleness Introduced by STUN NAT Behavior Discovery . . 21 95 9.4. Requirements for a Long Term Solution . . . . . . . . . . 22 96 9.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 22 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 98 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 12. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 24 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 25 104 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 105 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 . 26 106 A.2. from draft-ietf-behave-nat-behavior-discovery-00 . . . . . 26 107 A.3. from draft-ietf-behave-nat-behavior-discovery-01 . . . . . 26 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 109 Intellectual Property and Copyright Statements . . . . . . . . . . 28 111 1. Applicability 113 This experimental STUN usage does not allow an application behind a 114 NAT to make an absolute determination of the NAT's characteristics. 115 NAT devices do not behave consistently enough to predict future 116 behaviour with any guarantee. This STUN usage provides information 117 about observable transient behavior; it only truly determines a NAT's 118 behavior with regard to the STUN server used at the instant the test 119 is run. Applications requiring reliable reach between two particular 120 endpoints must establish a communication channel through a NAT using 121 another technique. IETF has proposed standards including ICE 122 [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] for 123 establishing communication channels when a publicly accessible 124 rendezvous service is available. 126 This techniques available with this usage are powerful diagnostic 127 tools in the hands of a network administrator or system programmer 128 trying to determine the causes of network failure, in particular when 129 behavior varies by load, destination, or other factors that may be 130 related to NAT behavior. 132 This draft also proposes experimental applications of NAT Behavior 133 Discovery STUN for real-time selection of parameters for protocols in 134 situations where a publicly accessible rendezvous service is not 135 available. One such application is role selection in P2P networks 136 based on statistical experience with establishing connections and 137 diagnosing NAT behavior with a variety of peers. The experimental 138 question is whether such a test is useful. If a node trying to join 139 an overlay as a full peer when its NAT prevents sufficient 140 connectivity and then withdrawing is expensive or leads to unreliable 141 or poorly performing operation, then even if the behavior discovery 142 check is only "correct" 75% of the time, its relative cheapness may 143 make it very useful for optimizing the behavior of the overlay 144 network. Section 2.2 describes this experimental application in more 145 detail and discusses how to evaluate its success or failure. 147 The applications of this STUN usage are very different than the 148 original use of RFC3489 [RFC3489], which was intended for static 149 determination of device behavior. The NAT Behavior Discovery STUN 150 usage makes an explicit statement that it is not, and cannot be, 151 correct 100% of the time, but is still very useful. It is submitted 152 to the Internet community as an experimental protocol that, when 153 applied with appropriate statistical underpinnings and application 154 behavior that is ultimately based on experienced connectivity 155 patterns, can lead to more stability and increased performance than 156 is available without the knowledge it provides. 158 2. Introduction 160 The Simple Traversal Underneath Network Address Translators (NAT) 161 (STUN) [I-D.ietf-behave-rfc3489bis] provides a mechanism to discover 162 the reflexive transport address toward the STUN server, using the 163 Binding Request. This specification defines the NAT Behavior 164 Discovery STUN usage, which allows a STUN client to probe the current 165 behaviour of the NAT/FW devices between the client and the STUN 166 server. This usage defines new STUN attributes for the Binding 167 Request and Binding Response. 169 Many NAT/FW devices do not behave consistently and will change their 170 behaviour under load and over time. Applications requiring high 171 reliability must be prepared for the NAT's behaviour to become more 172 restrictive. Specifically, it has been found that under load NATs 173 may transition to the most restrictive filtering and mapping 174 behaviour and shorten the lifetime of new and existing bindings. In 175 short, applications can discover how bad things currently are, but 176 not how bad things will get. 178 Despite this limitation, instantaneous observations are often quite 179 useful in troubleshooting network problems, and repeated tests over 180 time, or in known load situations, may be used to characterize a 181 NAT's behavior. In particular, in the hands of a person 182 knowledgeable about the needs of an application and the nodes an 183 application needs to communicate with, it can be a powerful tool. 185 2.1. Diagnostic Use 187 Applications that work well in the lab, but fail in a deployment, are 188 notoriously common within distributed systems. There are few systems 189 developers who have not had the experience of searching to determine 190 the difference in the environments for insight as to what real- 191 network behavior was missed in the testing lab. The behavior 192 discovery usage offers a powerful tool that can be used to check NAT 193 and firewall behavior as the application is running. 195 As they are being used to detect instantaneous behavior for analysis 196 by an experienced developer or administrator, there are relatively 197 few concerns about this application of the NAT Behavior Discovery 198 STUN usage. However, the user should be aware that 200 o adding new traffic to new destinations (STUN servers) has the 201 potential to itself change the behavior of a NAT and 203 o the user must be careful to select a STUN server that is 204 appropriately located, ideally collocated (or even integrated) 205 with the communication partners of the application in question, 206 for the results to be applicable to the network conditions 207 experienced by the application. 209 2.2. Example Use with P2P Overlays 211 An application could use Behavior Discovery in a P2P protocol to 212 determine if a particular endpoint is a reasonable candidate to 213 participate as a peer or supernode (defined here as a peer in the 214 overlay that offers services, including message routing, to other 215 members or clients of the overlay network). This P2P network 216 application is willing to select supernodes that might be located 217 behind NATs to avoid the cost of dedicated servers. A supernode 218 candidate requires that its NAT(s) offer(s) Address Independent 219 Filtering. It might periodically re-run tests and would remove 220 itself as a supernode if its NAT/FW chain lost this characteristic. 221 These tests could be run with other supernode candidates acting as 222 STUN servers as well as dedicated STUN servers. As many P2P 223 algorithms tolerate non-transitive connectivity between a portion of 224 their peers, guaranteed pair-wise reliable reach might be sacrificed 225 in order to distribute the P2P overlay's load across peers that can 226 be directly contacted by the majority of users. 228 Use of Behavior Discovery for such an application requires: 230 o Specification of protocols capable of offering reliable end-user 231 performance using unreliable links between peers. 233 o The application is deployed behind NATs that provide Address 234 Independent Filtering and that remain in this mode for an amount 235 of time sufficient for the application to identify their behavior, 236 distribute this information to the rest of the overlay, and 237 provide useful work for the application. 239 This draft is experimental as deployed applications implementing open 240 protocols have yet to be deployed in such environments to demonstrate 241 that these two requirements have been met. However, apocryphal 242 evidence suggests that household- and small business-targeted NAT 243 devices have stable behaviour, especially when there are few clients 244 behind them. Numerous P2P applications have been deployed that 245 appear to have these properties, although their protocols have not 246 yet been subjected to rigorous evaluation by standards bodies. 248 2.3. Experimental Success 250 The criteria for an application to successfully demonstrate use of 251 the NAT Behavior Discovery STUN usage would include: 253 o An implementation that relies on this usage to determine its run- 254 time behavior, most likely using it to determine an initial choice 255 of options that are then adjusted based on experience with its 256 network connections. 258 o The implementation must either demonstrate its applicability in 259 environments where it is realistic to expect a provider to deploy 260 dedicated STUN servers with multiple IP addresses, or it must 261 demonstrate duplicating the behavior of such a dedicated STUN 262 server with two nodes that share the role of providing the 263 address-changing operations required by this usage. 265 o Experimental evidence that the application of this usage results 266 in improved behavior of the application in real-world conditions. 267 The exact metrics for this improvement may vary, some 268 possibilities include: faster convergence to the proper 269 parameters, less work to set up initial connections, fewer 270 reconfigurations required after startup, etc. 272 o A protocol specification that defines how the implementation 273 applies this usage. 275 The P2P scenario described above is a likely experimental test case 276 for this usage, but others applications are possible as well. 278 3. Overview of Operations 280 In a typical configuration, a STUN client is connected to a private 281 network and through one or more NATs to the public Internet. The 282 client is configured with the address of a STUN server on the public 283 Internet. The Behavior Discovery usage makes use of SRV records so 284 that a server may use a different transport address for this usage 285 than for other usages. This usage does not provide backward 286 compatibility with RFC3489 [RFC3489] for either clients or servers. 287 Implementors of clients that wish to be compliant with RFC3489 288 servers should see that specification. Implementors of servers 289 SHOULD NOT include support for RFC3489 clients as the original uses 290 of that protocol have been deprecated. 292 The STUN NAT Behavior Discovery usage defines new attributes on the 293 STUN Binding Request and STUN Binding Response that allow these 294 messages to be used to diagnose the current behavior of the NAT(s) 295 between the client and server. 297 This section provides a descriptive overview of the typical use of 298 these attributes. Normative behavior is described in Sections 5, 6, 299 and 7. 301 3.1. Determining NAT Mapping 303 A client behind a NAT wishes to determine if the NAT it is behind is 304 currently using independent, address dependent, or port dependent 305 mapping[RFC4787]. The client performs a series of tests that make 306 use of the OTHER-ADDRESS attribute; these tests are described in 307 detail in Section 4. These tests send binding requests to the 308 alternate address and port of the STUN server to determine mapping 309 behaviour. These tests can be used for UDP, TCP, or TCP/TLS 310 connections. 312 3.2. Determining NAT Filtering 314 A client behind a NAT wishes to determine if the NAT it is behind is 315 currently using independent, address dependent, or port dependent 316 filtering[RFC4787]. The client performs a series of tests that make 317 use of the OTHER-ADDRESS and CHANGE-REQUEST attributes; these tests 318 are described in Section 4. These tests request responses from the 319 alternate address and port of the STUN server; a precondition to 320 these tests is that no binding be established to the alternate 321 address and port. Because the NAT does not know that the alternate 322 address and port belong to the same server as the primary address and 323 port, it treats these responses the same as it would those from any 324 other host on the Internet. Therefore, the success of the binding 325 responses sent from the alternate address and port indicate whether 326 the NAT is currently performing independent filtering, address 327 dependent filtering, or address and port dependent filtering. This 328 test applies only to UDP datagrams. 330 3.3. Binding Lifetime Discovery 332 Many systems, such as VoIP, rely on being able to keep a connection 333 open between a client and server or between peers of a P2P system. 334 Because NAT bindings expire over time, keepalive messages must be 335 sent across the connection to preserve it. Because keepalives impose 336 some overhead on the network and servers, reducing the frequency of 337 keepalives can be useful. 339 Binding lifetime can be discovered by performing timed tests that use 340 XOR-RESPONSE-TARGET. The client uses a second port and the STUN 341 server's alternate address to check if an existing binding that 342 hasn't had traffic sent on it is still open after time T. This 343 approach is described in detail in Section 4.5. This test applies 344 only to UDP datagrams. 346 3.4. Diagnosing NAT Hairpinning 348 STUN Binding Requests allow a client to determine whether it is 349 behind a NAT that supports hairpinning of connections. To perform 350 this test, the client first sends a Binding Request to its STUN 351 server to determine its mapped address. The client then sends a STUN 352 Binding Request to this mapped address from a different port. If the 353 client receives its own request, the NAT hairpins connections. This 354 test applies to UDP, TCP, or TCP/TLS connections. 356 3.5. Determining Fragment Handling 358 Some NATs exhibit different behavior when forwarding fragments than 359 when forwarding a single-frame datagram. In particular, some NATs do 360 not hairpin fragments at all and some platforms discard fragments 361 under load. To diagnose this behavior, STUN messages may be sent 362 with the PADDING attribute, which simply inserts additional space 363 into the message. By forcing the STUN message to be divided into 364 multiple fragments, the NAT's behavior can be observed. 366 All of the previous tests can be performed with PADDING if a NAT's 367 fragment behavior is important for an application, or only those 368 tests which are most interesting to the application can be retested. 369 PADDING only applies to UDP datagrams. PADDING can not be used with 370 XOR-RESPONSE-TARGET. 372 3.6. Detecting Generic ALGs 374 A number of NAT boxes are now being deployed into the market which 375 try to provide "generic" ALG functionality. These generic ALGs hunt 376 for IP addresses, either in text or binary form within a packet, and 377 rewrite them if they match a binding. This behavior can be detected 378 because the STUN server returns both the MAPPED-ADDRESS and XOR- 379 MAPPED-ADDRESS in the same response. If the result in the two does 380 not match, there is a NAT with a generic ALG in the path. 382 4. Discovery Process 384 The NAT Behavior Discovery usage provides primitives that allow STUN 385 checks to be made to determine the current behaviour of the NAT or 386 NATs an application is behind. These tests can only give the 387 instantaneous behaviour of a NAT; it has been found that NATs can 388 change behaviour under load and over time. An application must 389 assume that NAT behaviour can become more restrictive at any time. 390 The tests described here are for UDP connectivity, NAT mapping 391 behaviour, and NAT filtering behaviour; additional tests could be 392 designed using this usage's mechanisms. Definitions for NAT 393 filtering and mapping behaviour are from [RFC4787]. 395 4.1. Checking if UDP is Blocked 397 The client sends a STUN Binding Request to a server. This causes the 398 server to send the response back to the address and port that the 399 request came from. If this test yields no response, the client knows 400 right away that it is not capable of UDP connectivity. This test 401 requires only RFC3489-bis [I-D.ietf-behave-rfc3489bis] functionality. 403 4.2. Determining NAT Mapping Behavior 405 This will require at most three tests. In test I, the client 406 performs the UDP connectivity test. The server will return its 407 alternate address and port in OTHER-ADDRESS in the binding response. 408 If OTHER-ADDRESS is not returned, the server does not support this 409 usage and this test cannot be run. The client examines the XOR- 410 MAPPED-ADDRESS attribute. If this address and port are the same as 411 the local IP address and port of the socket used to send the request, 412 the client knows that it is not NATed and the effective mapping will 413 be Endpoint Independent. 415 In test II, the client sends a Binding Request to the alternate 416 address, but primary port. If the XOR-MAPPED-ADDRESS in the Binding 417 Response is the same as test I the NAT currently has Endpoint 418 Independent Mapping. If not, test III is performed: the client sends 419 a Binding Request to the alternate address and port. If the XOR- 420 MAPPED-ADDRESS matches test II, the NAT currently has Address 421 Dependent Mapping; if it doesn't match it currently has Address and 422 Port Dependent Mapping. 424 4.3. Determining NAT Filtering Behavior 426 This will also require at most three tests. These tests should be 427 performed using a port that wasn't used for mapping or other tests as 428 packets sent during those tests may affect results. In test I, the 429 client performs the UDP connectivity test. The server will return 430 its alternate address and port in OTHER-ADDRESS in the binding 431 response. If OTHER-ADDRESS is not returned, the server does not 432 support this usage and this test cannot be run. 434 In test II, the client sends a binding request to the primary address 435 of the server with the CHANGE-REQUEST attribute set to change-port 436 and change-IP. This will cause the server to send its response from 437 its alternate IP address and alternate port. If the client receives 438 a response the current behaviour of the NAT is Address Independent 439 Filtering. 441 If no response is received, test III must be performed to distinguish 442 between Address Dependent Filtering and Address and Port Dependent 443 Filtering. In test III, the client sends a binding request to the 444 original server address with CHANGE-REQUEST set to change-port. If 445 the client receives a response the current behaviour is Address 446 Dependent Filtering; if no response is received the current behaviour 447 is Address and Port Dependent Filtering. 449 4.4. Combining and Ordering Tests 451 Clients may wish to combine and parallelize these tests to reduce the 452 number of packets sent and speed the discovery process. For example, 453 test I of the filtering and mapping tests also checks if UDP is 454 blocked. Furthermore, an application or user may not need as much 455 detail as these sample tests provide. For example, establishing 456 connectivity between nodes becomes significantly more difficult if a 457 NAT has any behavior other than endpoint independent mapping, which 458 requires only test I and II of Section 4.2. An application 459 determining its NAT does not always provide independent mapping might 460 notify the user if no relay is configured, whereas an application 461 behind a NAT that provides endpoint independent mapping might not 462 notify the user until a subsequent connection actually fails or might 463 provide a less urgent notification that no relay is configured. Such 464 a test does not alleviate the need for ICE [I-D.ietf-mmusic-ice], but 465 it does provide some information regarding whether ICE is likely to 466 be successful establishing non-relayed connections. 468 Care must be taken when parallelizing tests, as some NAT devices have 469 an upper limit on how quickly bindings will be allocated. 471 4.5. Binding Lifetime Discovery 473 STUN can also be used to probe the lifetimes of the bindings created 474 by the NAT. For many NAT devices, an absolute refresh interval 475 cannot be determined; bindings might be closed quicker under heavy 476 load or might not behave as the tests suggest. For this reason 477 applications that require reliable bindings must send keep-alives as 478 frequently as required by all NAT devices that will be encountered. 479 Suggested refresh intervals are outside the scope of this document. 480 ICE [I-D.ietf-mmusic-ice] and OUTBOUND [I-D.ietf-sip-outbound] have 481 suggested refresh intervals. 483 To determine the binding lifetime, the client first sends a Binding 484 Request to the server from a particular socket, X. This creates a 485 binding in the NAT. The response from the server contains a MAPPED- 486 ADDRESS attribute, providing the public address and port on the NAT. 487 Call this Pa and Pp, respectively. The client then starts a timer 488 with a value of T seconds. When this timer fires, the client sends 489 another Binding Request to the server, using the same destination 490 address and port, but from a different socket, Y. This request 491 contains an XOR-RESPONSE-TARGET address attribute, set to (Pa,Pp). 492 This will create a new binding on the NAT, and cause the STUN server 493 to send a Binding Response that would match the old binding, if it 494 still exists. If the client receives the Binding Response on socket 495 X, it knows that the binding has not expired. If the client receives 496 the Binding Response on socket Y (which is possible if the old 497 binding expired, and the NAT allocated the same public address and 498 port to the new binding), or receives no response at all, it knows 499 that the binding has expired. 501 Because some NATs only refresh bindings when outbound traffic is 502 sent, the client must resend a binding request on the original port 503 before beginning a second test with a different value of T. The 504 client can find the value of the binding lifetime by doing a binary 505 search through T, arriving eventually at the value where the response 506 is not received for any timer greater than T, but is received for any 507 timer less than T. 509 This discovery process takes quite a bit of time and is something 510 that will typically be run in the background on a device once it 511 boots. 513 It is possible that the client can get inconsistent results each time 514 this process is run. For example, if the NAT should reboot, or be 515 reset for some reason, the process may discover a lifetime than is 516 shorter than the actual one. Binding lifetime may also be dependent 517 on the traffic load on the NAT. For this reason, implementations are 518 encouraged to run the test numerous times and be prepared to get 519 inconsistent results. 521 Like the other diagnostics, this test is inherently unstable. In 522 particular, an overloaded NAT might reduce binding lifetime to shed 523 load. A client might find this diagnostic useful at startup, for 524 example setting the initial keepalive interval on its connection to 525 the server to 10 seconds while beginning this check. After 526 determining the current lifetime, the keepalive interval used by the 527 connection to the server can be set to this appropriate value. 528 Subsequent checks of the binding lifetime can then be performed using 529 the keepalives in the server connection. The STUN Keepalive Usage 530 [I-D.ietf-sip-outbound]provides a response that confirms the 531 connection is open and allows the client to check that its mapped 532 address has not changed. As that provides both the keepalive action 533 and diagnostic that it is working, it should be preferred over any 534 attempt to characterize the connection by a secondary technique. 536 5. Client Behavior 538 Unless otherwise specified here, all procedures for preparing, 539 sending, and processing messages as described in the STUN Binding 540 Usage [I-D.ietf-behave-rfc3489bis] are followed. 542 If a client intends to utilize an XOR-RESPONSE-TARGET attribute in 543 future transactions, as described in Section 4.5, then it MUST 544 include a CACHE-TIMEOUT attribute in the Request with the value set 545 greater than the longest time duration it intends to test. The 546 server will also include this attribute in its Response, modified 547 with its estimate of how long it will be able to cache this 548 connection. Because the returned value is only an estimate, the 549 client must be prepared for the value to be wrong, and therefore to 550 receive a 481 response to its subsequent Requests with XOR-RESPONSE- 551 TARGET. 553 Support for XOR-RESPONSE-TARGET is optional due to the state cost on 554 the server. Therefore, a client MUST be prepared for receiving a 420 555 (Unknown Attribute) error to requests that include XOR-RESPONSE- 556 TARGET or CACHE-TIMEOUT. Support for OTHER-ADDRESS and CHANGE- 557 REQUEST is optional, but MUST be supported by servers advertised via 558 SRV, as described below. This is to allow the use of PADDING and 559 XOR-RESPONSE-TARGET in applications where servers do not have 560 multiple IP addresses. Clients MUST be prepared to receive a 420 for 561 requests that include CHANGE-REQUEST when OTHER-ADDRESS was not 562 received in Binding Response messages from the server. 564 If an application makes use of the NAT Behavior Discovery STUN usage 565 by multiplexing it in a flow with application traffic, a FINGERPRINT 566 attribute SHOULD be included unless it is always possible to 567 distinguish a STUN message from an application message based on their 568 header. 570 Clients SHOULD ignore an ALTERNATE-SERVER attribute in a response 571 unless they are using authentication with a provider of STUN servers 572 that is aware of the topology requirements of the tests being 573 performed. 575 5.1. Discovery 577 Unless the user or application is aware of the transport address of a 578 STUN server supporting the NAT Behavior Discovery usage through other 579 means, a client is configured with the domain name of the provider of 580 the STUN servers. The domain is resolved to a transport address 581 using SRV procedures [RFC2782]. The mechanism for configuring the 582 client with the domain name of the STUN servers or of acquiring a 583 specific transport address is out of scope for this document. 585 For the Behavior Discovery Usage the service name is "stun-behavior". 586 The protocol can be "udp", "tcp" or "tls". Other aspects of handling 587 failures and default ports are followed as described in STUN 588 [I-D.ietf-behave-rfc3489bis]. 590 5.2. Security 592 Servers MAY require authentication before allowing a client to make 593 use of its services. This is particularly important to requests used 594 to perform a Binding Lifetime Discovery test or other test requiring 595 use of the XOR-RESPONSE-TARGET attribute. The method for obtaining 596 these credentials, should the server require them, is outside the 597 scope of this usage. Presumably, the administrator or application 598 relying on this usage should have its own method for obtaining 599 credentials. If the client receives a 401 (Unauthorized) Response to 600 a Request, then it must either acquire the appropriate credential 601 from the application before retrying or report a permanent failure. 602 Procedures for encoding the MESSAGE-INTEGRITY attribute for a request 603 are described in STUN [I-D.ietf-behave-rfc3489bis]. 605 6. Server Behavior 607 Unless otherwise specified here, all procedures for preparing, 608 sending, and processing messages as described for the STUN Binding 609 Usage of STUN [I-D.ietf-behave-rfc3489bis] are followed. 611 A server implementing the NAT Behavior Discovery usage SHOULD be 612 configured with two separate IP addresses on the public Internet. On 613 startup, the server SHOULD allocate two UDP ports, such that it can 614 send and receive datagrams using the same ports on each IP address 615 (normally a wildcard binding accomplishes this). If a server cannot 616 allocate the same ports on two different IP address, then it MUST NOT 617 include an OTHER-ADDRESS attribute in any Response and MUST respond 618 with a 420 (Unknown Attribute) to any Request with a CHANGE-REQUEST 619 attribute. A server with only one IP address MUST NOT be advertised 620 using the SRV service name "stun-behavior". 622 6.1. Preparing the Response 624 After performing all authentication and verification steps the server 625 begins processing specific to this Usage if the Request contains any 626 request attributes defined in this document: XOR-RESPONSE-TARGET, 627 CHANGE-REQUEST, or PADDING. If the Request does not contain any 628 attributes from this document, OTHER-ADDRESS and RESPONSE-ORIGIN are 629 still included in the response. 631 The server MUST include both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS in 632 its Response. 634 If the Request contains CHANGE-REQUEST attribute and the server does 635 not have an alternate address and port as described above, the server 636 MUST generate an error response of type 420. 638 If the Request contains a CACHE-TIMEOUT attribute, then the server 639 SHOULD include a CACHE-TIMEOUT attribute in its response indicating 640 the duration (in seconds) it anticipates being able to cache this 641 binding request in anticipation of a future Request using the XOR- 642 RESPONSE-TARGET attribute. The CACHE-TIMEOUT response value can be 643 greater or less than the value in the request. If the server is not 644 prepared to provide such an estimate, it SHOULD NOT include the 645 CACHE-TIMEOUT attribute in its Response. The server SHOULD NOT 646 provide a CACHE-TIMEOUT length longer than the amount of time it has 647 been able to cache recent requests. 649 Because XOR-RESPONSE-TARGET offers the potential for minor 650 indirection attacks, a server MUST either authenticate the users 651 requesting its use or rate-limit its response to those requests. 653 If XOR-RESPONSE-TARGET is included in a Request, then the server must 654 verify that it has previously received a binding request from the 655 same address as is specified in XOR-RESPONSE-TARGET. If it has not, 656 or if sufficient time has passed that it no longer has a record of 657 having received such a request due to limited state, it MUST respond 658 with an error response of type 481. 660 If the Request contains a XOR-RESPONSE-TARGET attribute and the 661 server is authenticating such requests, then the server checks the 662 message for a MESSAGE-INTEGRITY attribute and a USERNAME. If they 663 are not present the server MUST generate an error response of type 664 401. 666 If the Request contains a XOR-RESPONSE-TARGET attribute and the 667 server is rate-limiting such requests, it MUST ensure that it does 668 not generate a Response on a particular address more often than one 669 per second. If it receives requests more often than one per second, 670 it MUST generate a 503 (Service unavailable) Response to the Request. 672 The source address and port of the Binding Response depend on the 673 value of the CHANGE-REQUEST attribute and on the address and port the 674 Binding Request was received on, and are summarized in Table 1. 676 Let Da represent the destination IP address of the Binding Request 677 (which will be either A1 or A2), and Dp represent the destination 678 port of the Binding Request (which will be either P1 or P2). Let Ca 679 represent the other address, so that if Da is A1, Ca is A2. If Da is 680 A2, Ca is A1. Similarly, let Cp represent the other port, so that if 681 Dp is P1, Cp is P2. If Dp is P2, Cp is P1. If the "change port" 682 flag was set in CHANGE-REQUEST attribute of the Binding Request, and 683 the "change IP" flag was not set, the source IP address of the 684 Binding Response MUST be Da and the source port of the Binding 685 Response MUST be Cp. If the "change IP" flag was set in the Binding 686 Request, and the "change port" flag was not set, the source IP 687 address of the Binding Response MUST be Ca and the source port of the 688 Binding Response MUST be Dp. When both flags are set, the source IP 689 address of the Binding Response MUST be Ca and the source port of the 690 Binding Response MUST be Cp. If neither flag is set, or if the 691 CHANGE-REQUEST attribute is absent entirely, the source IP address of 692 the Binding Response MUST be Da and the source port of the Binding 693 Response MUST be Dp. 695 +--------------------+----------------+-------------+---------------+ 696 | Flags | Source Address | Source Port | OTHER-ADDRESS | 697 +--------------------+----------------+-------------+---------------+ 698 | none | Da | Dp | Ca:Cp | 699 | Change IP | Ca | Dp | Ca:Cp | 700 | Change port | Da | Cp | Ca:Cp | 701 | Change IP and | Ca | Cp | Ca:Cp | 702 | Change port | | | | 703 +--------------------+----------------+-------------+---------------+ 705 Table 1: Impact of Flags on Packet Source and OTHER-ADDRESS 707 The server MUST add a RESPONSE-ORIGIN attribute to the Binding 708 Response, containing the source address and port used to send the 709 Binding Response. 711 If the server supports an alternate address and port the server MUST 712 add an OTHER-ADDRESS attribute to the Binding Response. This 713 contains the source IP address and port that would be used if the 714 client had set the "change IP" and "change port" flags in the Binding 715 Request. As summarized in Table 1, these are Ca and Cp, 716 respectively, regardless of the value of the CHANGE-REQUEST flags. 718 Next the server inspects the Request for a XOR-RESPONSE-TARGET 719 attribute. If the XOR-RESPONSE-TARGET attribute is included, then it 720 includes an XOR-REFLECTED-FROM attribute with the source address the 721 Request was received from. 723 If the Request contained a PADDING attribute, then the server SHOULD 724 insert a PADDING attribute of the same length into its response, but 725 no longer than 64K. If the Request also contains the XOR-RESPONSE- 726 TARGET attribute the server MUST return an error response of type 727 400. 729 Following that, the server completes the remainder of the processing 730 from STUN [I-D.ietf-behave-rfc3489bis]. The server MAY include a 731 SERVER attribute. If authentication is being required, the server 732 MUST include a MESSAGE-INTEGRITY and associated attributes as 733 appropriate. A FINGERPRINT attribute is only required if the STUN 734 messages are being multiplexed with application traffic that requires 735 use of a FINGERPRINT to distinguish STUN messages. An ALTERNATE- 736 SERVER attribute SHOULD NOT be included. 738 When the server sends the Response, it is sent from the source 739 address as determined above and to the destination address determined 740 from the XOR-RESPONSE-TARGET, or to the source address of the Request 741 otherwise. 743 7. New Attributes 745 This document defines several STUN attributes that are required for 746 NAT Behavior Discovery. These attributes are all used only with 747 Binding Requests and Binding Responses. CHANGE-REQUEST was 748 originally defined in RFC3489 [RFC3489] but is redefined here as that 749 document is obsoleted by RFC3489bis [I-D.ietf-behave-rfc3489bis]. 751 Comprehension-required range (0x0000-0x7FFF): 752 0x0003: CHANGE-REQUEST 753 0x0026: PADDING 754 0x0027: XOR-RESPONSE-TARGET 755 0x0028: XOR-REFLECTED-FROM 757 Comprehension-optional range (0x8000-0xFFFF) 758 0x8027: CACHE-TIMEOUT 759 0x802b: RESPONSE-ORIGIN 760 0x802c: OTHER-ADDRESS 762 7.1. Representing Transport Addresses 764 Whenever an attribute contains a transport address, it has the same 765 format as MAPPED-ADDRESS. Similarly, the XOR- attributes have the 766 same format as XOR-MAPPED-ADDRESS[I-D.ietf-behave-rfc3489bis]. 768 7.2. CHANGE-REQUEST 770 The CHANGE-REQUEST attribute contains two flags to control the IP 771 address and port the server uses to send the response. These flags 772 are called the "change IP" and "change port" flags. The CHANGE- 773 REQUEST attribute is allowed only in the Binding Request. The 774 "change IP" and "change port" flags are useful for determining the 775 current filtering behavior of a NAT. They instruct the server to 776 send the Binding Responses from the alternate source IP address 777 and/or alternate port. The CHANGE-REQUEST attribute is optional in 778 the Binding Request. 780 The attribute is 32 bits long, although only two bits (A and B) are 781 used: 782 0 1 2 3 783 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 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 |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| 786 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 788 The meanings of the flags are: 790 A: This is the "change IP" flag. If true, it requests the server to 791 send the Binding Response with a different IP address than the one 792 the Binding Request was received on. 794 B: This is the "change port" flag. If true, it requests the server 795 to send the Binding Response with a different port than the one 796 the Binding Request was received on. 798 7.3. RESPONSE-ORIGIN 800 The RESPONSE-ORIGIN attribute is inserted by the server and indicates 801 the source IP address and port the response was sent from. It is 802 useful for detecting twice NAT configurations. It is only present in 803 Binding Responses. 805 7.4. OTHER-ADDRESS 807 The OTHER-ADDRESS attribute is used in Binding Responses. It informs 808 the client of the source IP address and port that would be used if 809 the client requested the "change IP" and "change port" behavior. 810 OTHER-ADDRESS MUST NOT be inserted into a Binding Response unless the 811 server has a second IP address. 813 OTHER-ADDRESS uses the same attribute as CHANGED-ADDRESS from RFC3489 814 because it is simply a new name with the same semantics as CHANGED- 815 ADDRESS. It has been renamed to more clearly indicate its function. 817 7.5. XOR-REFLECTED-FROM 819 The XOR-REFLECTED-FROM attribute is present only in Binding Responses 820 when the Binding Request contained a XOR-RESPONSE-TARGET attribute. 821 The attribute contains the transport address of the source where the 822 request came from. Its purpose is to provide traceability, so that a 823 STUN server cannot be used as a reflector for anonymous denial-of- 824 service attacks. 826 The XOR-REFLECTED-FROM attribute is used in place of RFC3489's 827 REFLECTED-FROM attribute. It provides the same information, but 828 because the NAT's public address is obfuscated through the XOR 829 function, It can pass through a NAT that would otherwise attempt to 830 translate it to the private network address. 832 7.6. XOR-RESPONSE-TARGET 834 The XOR-RESPONSE-TARGET attribute contains an IP address and port. 835 The XOR-RESPONSE-TARGET attribute can be present in the Binding 836 Request and indicates where the Binding Response is to be sent. When 837 not present, the server sends the Binding Response to the source IP 838 address and port of the Binding Request. The server MUST NOT process 839 a request containing a XOR-RESPONSE-TARGET that does not contain 840 MESSAGE-INTEGRITY. The XOR-RESPONSE-TARGET attribute is optional in 841 the Binding Request. 843 XOR-RESPONSE-TARGET is used in place of RFC3489's RESPONSE-ADDRESS. 844 It provides the same information, but because the NAT's public 845 address is obfuscated through the XOR function, It can pass through a 846 NAT that would otherwise attempt to translate it to the private 847 network address. 849 7.7. PADDING 851 The PADDING attribute allows for the entire message to be padded to 852 force the STUN message to be divided into IP fragments. PADDING 853 consists entirely of a freeform string, the value of which does not 854 matter. When PADDING is used, it SHOULD be 1500 bytes long, unless a 855 more appropriate length is known based on the MTU of the path. 856 PADDING can be used in either Binding Requests or Binding Responses. 857 If PADDING is present in the Binding Request and the server supports 858 it, PADDING MUST be present in the Binding Response. The server 859 SHOULD use the same length PADDING as was used in the Binding 860 Request, but it MAY use another length if it knows what length is 861 required to cause fragmentation along the return path. If the server 862 supports PADDING (i.e. doesn't return a 420 in response to a Request 863 containing PADDING), then it MUST use either the requested length or 864 a length it knows is sufficient to cause fragmentation. 866 PADDING MUST be no longer than 64K and SHOULD be an even multiple of 867 four bytes. 869 7.8. CACHE-TIMEOUT 871 The CACHE-TIMEOUT is used in Binding Requests and Responses. It 872 indicates the time duration (in seconds) that the server will cache 873 the source address and USERNAME of an original binding request that 874 will later by followed by a request from a different source address 875 with a XOR-RESPONSE-TARGET asking that a response be reflected to the 876 source address of the original binding request. A server SHOULD NOT 877 send a response to a target address requested with XOR-RESPONSE- 878 TARGET unless it has cached that the same USERNAME made a previous 879 binding request from that target address. The client inserts a value 880 in CACHE-TIMEOUT into the Binding Request indicating the amount of 881 time it would like the server to cache that information. The server 882 responds with a CACHE-TIMEOUT in its Binding Response providing a 883 prediction of how long it will cache that information. The response 884 value can be greater than, equal to, or less than the requested 885 value. If the server is not able to provide such an estimate or the 886 information in the response would be meaningless, the server should 887 not include a CACHE-TIMEOUT attribute in its response. 889 8. New Response Codes 891 This draft defines new STUN response code. 893 8.1. 481 Connection does not exist 895 This code is generated when a server has received an XOR-RESPONSE- 896 TARGET, but the server has no record of having received a prior 897 binding Request from the address specified in XOR-RESPONSE-TARGET. 898 The client should re-submit the original binding request with an 899 appropriate CACHE-TIMEOUT attribute. If the server's response 900 includes a CACHE-TIMEOUT that is shorter than the client's request, 901 the server is unable to satisfy the caching time requested by the 902 client and the client SHOULD NOT continue to retry the request. 904 8.2. 503 Service Unavailable 906 This response is generated when a server receives Requests specifying 907 a particular address in their XOR-RESPONSE-TARGET attribute more 908 often than one per second. 910 9. IAB Considerations 912 The IAB has studied the problem of ``Unilateral Self Address 913 Fixing'', which is the general process by which a client attempts to 914 determine its address in another realm on the other side of a NAT 915 through a collaborative protocol reflection mechanism RFC 3424 916 [RFC3424]. The STUN NAT Behavior Discovery usage is an example of a 917 protocol that performs this type of function. The IAB has mandated 918 that any protocols developed for this purpose document a specific set 919 of considerations. This section meets those requirements. 921 9.1. Problem Definition 923 From RFC 3424 [RFC3424], any UNSAF proposal must provide: 925 Precise definition of a specific, limited-scope problem that is to 926 be solved with the UNSAF proposal. A short term fix should not be 927 generalized to solve other problems; this is why "short term fixes 928 usually aren't". 930 The specific problem being solved by the STUN NAT Behavior Discovery 931 usage is for a client, which may be located behind a NAT of any type, 932 to determine the instantaneous characteristics of that NAT in order 933 to either diagnose the cause of problems experienced by that or other 934 applications or for an application to modify its behavior based on 935 the current behavior of the NAT and an appropriate statistical model 936 of the behavior required for the application to succeed. 938 9.2. Exit Strategy 940 From [RFC3424], any UNSAF proposal must provide: 942 Description of an exit strategy/transition plan. The better short 943 term fixes are the ones that will naturally see less and less use 944 as the appropriate technology is deployed. 946 The STUN NAT Behavior Discovery usage does not itself provide an exit 947 strategy. Instead, that is provided by other initiatives. Work is 948 currently proceeding on proposals for protocols that allow clients to 949 determine the location of and control the behavior of NATs through 950 direct interaction with the NAT; Nat Control STUN Usage 951 [I-D.wing-behave-nat-control-stun-usage] STUN NAT Behavior Discovery 952 is no longer needed once NATs that can be communicated with directly 953 are in use. Finally, as NATs phase out and as IPv6 is deployed, STUN 954 NAT Behavior Discovery will no longer be of any interest. 956 9.3. Brittleness Introduced by STUN NAT Behavior Discovery 958 From [RFC3424], any UNSAF proposal must provide: 960 Discussion of specific issues that may render systems more 961 "brittle". For example, approaches that involve using data at 962 multiple network layers create more dependencies, increase 963 debugging challenges, and make it harder to transition. 965 The STUN NAT Behavior Discovery usage allows a client to determine 966 the current behavior of a NAT. This information can be quite useful 967 to a developer or network administrator outside of an application, 968 and as such can be used to diagnose the brittleness induced in 969 another application. When used within an application itself, STUN 970 NAT Behavior Discovery allows the application to adjust its behavior 971 according to the current behavior of the NAT. This draft is 972 experimental because the extent to which brittleness is introduced to 973 an application relying on the Behavior Discovery usage is unclear and 974 must be carefully evaluated by the designers of the protocol making 975 use of it. The experimental test for this protocol is essentially 976 determining whether an application can be made less brittle through 977 the use of behavior-discovery information than it would be if 978 attempted to make use of the network without any awareness of the 979 NATs its traffic must pass through. 981 9.4. Requirements for a Long Term Solution 983 From [RFC3424]}, any UNSAF proposal must provide: 985 Identify requirements for longer term, sound technical solutions 986 -- contribute to the process of finding the right longer term 987 solution. 989 As long as NATs are present, means of adapting to their presence will 990 be required. Direct control or discovery of NATs by applications, 991 such as proposed in Nat Control STUN Usage 992 [I-D.wing-behave-nat-control-stun-usage], will eliminate the need for 993 anonymous diagnostics of NAT behavior. 995 9.5. Issues with Existing NAPT Boxes 997 >From [RFC3424], any UNSAF proposal must provide: 999 Discussion of the impact of the noted practical issues with 1000 existing, deployed NA[P]Ts and experience reports. 1002 A number of NAT boxes are now being deployed into the market which 1003 try and provide "generic" ALG functionality. These generic ALGs hunt 1004 for IP addresses, either in text or binary form within a packet, and 1005 rewrite them if they match a binding. This usage avoids that problem 1006 by using the XOR-REFLECTED-FROM and XOR-RESPONSE-TARGET attributes 1007 instead of the older REFLECTED-FROM and RESPONSE-ADDRESS attributes. 1009 This usage provides a set of generic attributes that can be assembled 1010 to test many types of NAT behavior. While tests for the most 1011 commonly known NAT box behaviors are described, the BEHAVE mailing 1012 list regularly has descriptions of new behaviors, some of which may 1013 not be readily detected using the tests described herein. However, 1014 the techniques described in this usage can be assembled in different 1015 combinations to test NAT behaviors not now known or envisioned. 1017 10. IANA Considerations 1019 This specification defines several new STUN attributes. This section 1020 directs IANA to add these new protocol elements to the IANA registry 1021 of STUN protocol elements. 1023 OPEN ISSUE: does IANA consider CHANGE-REQUEST a new attribute or is 1024 it forever from original 3489? 1026 0x0003: CHANGE-REQUEST 1027 0x0027: XOR-RESPONSE-TARGET 1028 0x0028: XOR-REFLECTED-FROM 1029 0x0026: PADDING 1030 0x8027: CACHE-TIMEOUT 1031 0x802b: RESPONSE-ORIGIN 1032 0x802c: OTHER-ADDRESS 1034 This specification defines two new STUN error response codes. 1036 481: Connection does not exist 1037 503: Service Unavailable 1039 11. Security Considerations 1041 This usage inherits the security considerations of STUN 1042 [I-D.ietf-behave-rfc3489bis]. This usage adds several new 1043 attributes; security considerations for those are detailed here. 1045 OTHER-ADDRESS does not permit any new attacks; it provides another 1046 place where an attacker can impersonate a STUN server but it is not 1047 an interesting attack. An attacker positioned where it can 1048 compromise the Binding Request can completely hide the STUN server 1049 from the client. 1051 XOR-RESPONSE-TARGET allows a STUN server to be used as a reflector 1052 for denial-of-service attacks. It does not provide any amplification 1053 of the attack. The XOR-REFLECTED-FROM mitigates this by providing 1054 the identity (in terms of IP address) of the source where the request 1055 came from. Its purpose is to provide traceability, so that a STUN 1056 server cannot be used as an anonymous reflector for denial-of-service 1057 attacks. XOR-RESPONSE-TARGET is rate-limited or uses pre-existing 1058 credentials to alleviate this threat. Server caching previous 1059 contacts before directing a response to a XOR-RESPONSE-TARGET further 1060 eliminates the threat, although it introduces the complexity of state 1061 into a STUN server. CACHE-TIMEOUT is used to reduce the amount of 1062 additional state required. 1064 The only attack possible with the PADDING attribute is to have a 1065 large padding length which could cause a server to allocate a large 1066 amount of memory. As servers will ignore any padding length greater 1067 than 64k so the scope of this attack is limited. In general, servers 1068 should not allocate more memory than the size of the received 1069 datagram. This attack would only affect non-compliant 1070 implementations. 1072 CHANGE-REQUEST provides no attacks, but adds three more reflection 1073 sources for the XOR-RESPONSE-TARGET reflection attacks. It provides 1074 no additional amplification and the security mechanisms for XOR- 1075 RESPONSE-TARGET are deemed sufficient. 1077 RESPONSE-ORIGIN, CACHE-TIMEOUT and XOR-REFLECTED-FROM do not provide 1078 any additional attacks. 1080 12. Open Issues 1082 Does IANA consider attributes that were in 3489 but not in 3489bis to 1083 have been removed from the registry and should be re-registered by 1084 this document, or are there forever in the registry from 3489? 1086 13. Acknowledgements 1088 The authors would like to thank the authors of the original STUN 1089 specification [RFC3489] from which many of the ideas, attributes, and 1090 description in this document originated. 1092 14. References 1094 14.1. Normative References 1096 [I-D.ietf-behave-rfc3489bis] 1097 Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1098 "Session Traversal Utilities for (NAT) (STUN)", 1099 draft-ietf-behave-rfc3489bis-12 (work in progress), 1100 November 2007. 1102 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1103 Requirement Levels", BCP 14, RFC 2119, March 1997. 1105 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 1106 specifying the location of services (DNS SRV)", RFC 2782, 1107 February 2000. 1109 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1110 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1111 RFC 4787, January 2007. 1113 14.2. Informative References 1115 [I-D.ietf-mmusic-ice] 1116 Rosenberg, J., "Interactive Connectivity Establishment 1117 (ICE): A Protocol for Network Address Translator (NAT) 1118 Traversal for Offer/Answer Protocols", 1119 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 1121 [I-D.ietf-sip-outbound] 1122 Jennings, C. and R. Mahy, "Managing Client Initiated 1123 Connections in the Session Initiation Protocol (SIP)", 1124 draft-ietf-sip-outbound-10 (work in progress), July 2007. 1126 [I-D.wing-behave-nat-control-stun-usage] 1127 Wing, D., Rosenberg, J., and H. Tschofenig, "Discovering, 1128 Querying, and Controlling Firewalls and NATs", 1129 draft-wing-behave-nat-control-stun-usage-05 (work in 1130 progress), October 2007. 1132 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1133 Self-Address Fixing (UNSAF) Across Network Address 1134 Translation", RFC 3424, November 2002. 1136 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1137 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1138 Through Network Address Translators (NATs)", RFC 3489, 1139 March 2003. 1141 Appendix A. Change Log 1143 RFC-EDITOR: Please remove this entire Change Log section while 1144 formatting this document for publication. 1146 A.1. from draft-macdonald-behave-nat-behavior-diagnostics-00 1148 o Only OTHER-ADDRESS, CHANGE-ADDRESS, and XOR-RESPONSE-TARGET 1149 support is optional; support for PADDING and SOURCE-ADDRESS is now 1150 mandatory 1152 o PADDING is now a mandatory attribute 1154 o OTHER-ADDRESS is returned in all binding responses if the server 1155 has a second IP address 1157 A.2. from draft-ietf-behave-nat-behavior-discovery-00 1159 o Clarified that only servers with two IP addresses should have an 1160 SRV entry 1162 o Removed support for backward compatibility with 3489 clients by 1163 removing non-XOR forms of attributes. Language states that 1164 backward compatibility with 3489 clients is SHOULD NOT. 1165 Compatibility with 3489 servers is left unspecified. 1167 o PADDING is mandatory and language has been changed to indicate 1168 that if a server supports PADDING it must either actually provide 1169 the padding or return an error (can't support it but refuse to do 1170 it) 1172 o Require both MAPPED-ADDRESS and XOR-MAPPED-ADDRESS to be returned 1173 to support detection of generic ALGs 1175 A.3. from draft-ietf-behave-nat-behavior-discovery-01 1177 o Changed proposed status to experimental 1179 o Made significant changes to the introduction and applicability 1180 statements to reflect the experimental status 1182 o Fixed the New Attributes and IANA considerations not listing the 1183 same attribute numbers. 1185 o Removed mandatory shared secret credentials in favor of the option 1186 of rate limiting or credentials. Specified that credentials must 1187 be obtained from the user or parent application. 1189 o Made OTHER-ADDRESS and SOURCE-ADDRESS optional to address 1190 compatibility with 3489bis clients. Renamed SOURCE-ADDRESS as 1191 RESPONSE-ORIGIN to avoid conflicts with 3489. 1193 o Renamed XOR-RESPONSE-ADDRESS to XOR-RESPONSE-TARGET 1195 o Added discussion of FINGERPRINT and ALTERNATE-SERVER for 1196 compliance with 3489bis stun usage definition requirements. 1198 Authors' Addresses 1200 Derek C. MacDonald 1201 CounterPath Solutions, Inc. 1202 Suite 300, One Bentall Centre, 505 Burrard St 1203 Vancouver, BC V7X1M3 1204 Canada 1206 Phone: +1-604-320-3344 1207 Email: derek@counterpath.com 1209 Bruce B. Lowekamp 1210 SIPeerior Technologies and William & Mary 1211 3000 Easter Circle 1212 Williamsburg, Virginia 23188 1213 USA 1215 Phone: +1-757-565-0101 1216 Email: lowekamp@sipeerior.com 1218 Full Copyright Statement 1220 Copyright (C) The IETF Trust (2007). 1222 This document is subject to the rights, licenses and restrictions 1223 contained in BCP 78, and except as set forth therein, the authors 1224 retain all their rights. 1226 This document and the information contained herein are provided on an 1227 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1228 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1229 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1230 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1231 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1232 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1234 Intellectual Property 1236 The IETF takes no position regarding the validity or scope of any 1237 Intellectual Property Rights or other rights that might be claimed to 1238 pertain to the implementation or use of the technology described in 1239 this document or the extent to which any license under such rights 1240 might or might not be available; nor does it represent that it has 1241 made any independent effort to identify any such rights. Information 1242 on the procedures with respect to rights in RFC documents can be 1243 found in BCP 78 and BCP 79. 1245 Copies of IPR disclosures made to the IETF Secretariat and any 1246 assurances of licenses to be made available, or the result of an 1247 attempt made to obtain a general license or permission for the use of 1248 such proprietary rights by implementers or users of this 1249 specification can be obtained from the IETF on-line IPR repository at 1250 http://www.ietf.org/ipr. 1252 The IETF invites any interested party to bring to its attention any 1253 copyrights, patents or patent applications, or other proprietary 1254 rights that may cover technology that may be required to implement 1255 this standard. Please address the information to the IETF at 1256 ietf-ipr@ietf.org. 1258 Acknowledgment 1260 Funding for the RFC Editor function is provided by the IETF 1261 Administrative Support Activity (IASA).