idnits 2.17.00 (12 Aug 2021) /tmp/idnits43336/draft-wing-behave-nat-control-stun-usage-00.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 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 715. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 722. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 728. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 : ---------------------------------------------------------------------------- == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 248: '... This STUN usage MAY be used by a STUN...' RFC 2119 keyword, line 293: '... This attribute MUST be present in a ...' RFC 2119 keyword, line 347: '... STUN client MUST re-obtain its IP a...' RFC 2119 keyword, line 384: '...ace(s). The NAT SHOULD only respond t...' RFC 2119 keyword, line 387: '... SHOULD be handled as if the NAT isn...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 15, 2006) is 5697 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: draft-ietf-behave-nat-udp has been published as RFC 4787 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 Summary: 5 errors (**), 0 flaws (~~), 7 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Wing 3 Internet-Draft J. Rosenberg 4 Intended status: Standards Track Cisco Systems 5 Expires: April 18, 2007 October 15, 2006 7 Controlling NAT Bindings using STUN 8 draft-wing-behave-nat-control-stun-usage-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 18, 2007. 35 Copyright Notice 37 Copyright (C) The Internet Society (2006). 39 Abstract 41 Simple Traversal Underneath NAT (STUN) is a mechanism for traversing 42 NATs. STUN requests are transmitted through a NAT to external STUN 43 servers. While this works very well, its two primary drawbacks are 44 the inability to modify the properties of a NAT binding and the need 45 to query a public STUN server for every NAT binding. These drawbacks 46 require frequent messages which present a load on servers (like SIP 47 servers and STUN servers) and are bad for low speed access networks, 48 such as cellular. This document proposes that the STUN server be 49 embedded in the NAT itself, and describes how these STUN servers can 50 be readily discovered and utilized to reduce queries to public STUN 51 servers and to reduce NAT keepalive traffic. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Overview of Operation . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Interacting with Legacy NATs . . . . . . . . . . . . . . . 6 59 3. NAT Control Usage . . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 7 61 3.2. Client Discovery of Server . . . . . . . . . . . . . . . . 7 62 3.3. Server Determination of Usage . . . . . . . . . . . . . . 7 63 3.4. New Requests or Indications . . . . . . . . . . . . . . . 7 64 3.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 7 65 3.5.1. XOR-INTERNAL-ADDRESS . . . . . . . . . . . . . . . . . 8 66 3.5.2. REFRESH-INTERVAL . . . . . . . . . . . . . . . . . . . 8 67 3.6. Client Procedures . . . . . . . . . . . . . . . . . . . . 8 68 3.7. Server Procedures . . . . . . . . . . . . . . . . . . . . 9 69 4. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 70 4.1. Incremental Deployment . . . . . . . . . . . . . . . . . . 10 71 4.2. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 11 72 4.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 11 73 4.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 11 74 4.3.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 11 75 4.3.3. Learning STUN Servers without Configuration . . . . . 11 76 5. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 5.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . 12 78 5.2. Address Dependent Mapping . . . . . . . . . . . . . . . . 12 79 5.3. Address Dependent Filtering . . . . . . . . . . . . . . . 13 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 81 6.1. Authorization and Resource Exhaustion . . . . . . . . . . 14 82 6.2. Comparison to Other NAT Control Techniques . . . . . . . . 14 83 6.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 14 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 86 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 87 8.2. Informational References . . . . . . . . . . . . . . . . . 15 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 89 Intellectual Property and Copyright Statements . . . . . . . . . . 17 91 1. Introduction 93 Two common usages of STUN [I-D.ietf-behave-rfc3489bis] are Binding 94 Discovery and NAT Keepalive. The Binding Discovery usage allows a 95 STUN client to learn its public IP address (from the perspective of 96 the STUN server it contacted) and the NAT keepalive usage allows a 97 STUN client to keep an active NAT binding alive. Unlike some other 98 techniques (UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), STUN 99 does not interact directly with the NAT. Because STUN doesn't 100 interact directly with the NAT, STUN cannot request additional 101 services from the NAT such as longer lifetimes (which would reduce 102 keepalive messages). 104 This paper describes a mechanism for the STUN client to communicate 105 directly with the NAT and request additional services. To achieve 106 this optimization, the STUN client communicates to outer-most NAT's 107 embedded STUN server. Thereafter, the STUN client need only ask that 108 NAT's embedded STUN server for public IP addresses and UDP ports -- 109 as it will return the same information as the public STUN server. 110 Additionally, the STUN client can ask the NAT's embedded STUN server 111 to extend the NAT binding for the flow, and the STUN client can learn 112 the IP address of the next-outer-most NAT. By repeating this 113 procedure with the next-outer-most NAT, all of the NATs along that 114 path can have their bindings extended. By learning all of the STUN 115 servers on the path between the public Internet and itself, an 116 endpoint can optimize the path of peer-to-peer communications. 118 2. Overview of Operation 120 When a STUN client sends a STUN Request to a STUN server, it receives 121 a STUN Response which indicates the IP address and UDP port seen by 122 the STUN server. If the IP address and UDP port differs from the IP 123 address and UDP port of the socket used to send the request, the STUN 124 client knows there is at least one NAT between itself and the STUN 125 server, and knows the 'public' IP address of that NAT. For example, 126 in the following diagram, the STUN client learns the public IP 127 address of its NAT is 161.44.1.1: 129 +------+ +--------+ 130 | STUN | | 161.44.1.1 +-------------+ 131 |client+------------+ +------+ STUN Server | 132 | 10.1.1.2/4193 10.1.1.1 | +-------------+ 133 +------+ +--------+ 134 NAT with 135 embedded STUN server 137 Figure 1: One NAT 139 After learning the public IP address of its outer-most NAT, the STUN 140 client attempts to communicate with the STUN server embedded in that 141 outer-most NAT. The STUN client does this by sending a STUN Binding 142 Request to the public IP address of the NAT itself -- 161.44.1.1, in 143 the figure above. If the NAT is running a STUN server and supports 144 the usage described in this document, the NAT will return a STUN 145 Binding Response message including the XOR-INTERNAL-ADDRESS 146 attribute, which will indicate the IP address and UDP port seen on 147 the *internal* side of the NAT. In the example above, the IP address 148 and UDP port indicated in XOR-INTERNAL-ADDRESS are the same as that 149 used by the STUN client (10.1.1.2/4193), which indicates there are no 150 other NATs between the STUN client and that outer-most NAT. 152 The preceeding technique allows the STUN client to communicate 153 directly with all of the on-path NATs, even if there are multiple 154 NATs in the path. This is described in section Section 2.1. 156 The STUN client can request each NAT to increase the binding 157 lifetime, as described in Section 3.5. The STUN client receives 158 positive confirmation that the binding lifetime has been extended, 159 allowing the STUN client to significantly reduces its NAT keepalive 160 traffic. Additionally, as long as the NAT complies with 161 [I-D.ietf-behave-nat-udp], the STUN client's keepalive traffic need 162 only be sent to the outer-most NAT's IP address. 164 Additionally, the STUN client can request additional service from the 165 NAT for that flow via the new attributes defined in . 167 2.1. Nested NATs 169 Nested NATs are controlled individually. The nested NATs are 170 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 171 INTERNAL-ADDRESS attribute. 173 The following diagram shows how a STUN client iterates over the NATs 174 to communicate with all of the NATs in the path. First, the STUN 175 client would learn the outer-most NAT's IP address by performing the 176 steps above. In the case below, however, the IP address and UDP port 177 indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's 178 own IP address and UDP port -- rather, it's the IP address and UDP 179 port on the *outer* side of the NAT-B -- 10.1.1.2. 181 Because of this, the STUN client repeats the procedure and sends 182 another STUN Binding Request to that newly-learned address (the 183 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 184 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 185 match the STUN client's IP address and UDP port. The STUN client 186 knows there are no other NATs between itself and NAT-B, and finishes. 188 +------+ +--------+ +--------+ 189 | 192.168.1.2 | 10.1.1.2 | 161.44.1.1 +-----------+ 190 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 191 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 192 +------+ +--------+ +--------+ 194 Figure 2: Two NATs 196 Internally, the NAT can be diagrammed to function like this, where 197 the NAT operation occurs before the STUN server. 199 | 200 | 201 | outside 202 +---------+---------------+ 203 | | | 204 | | +--------+ | 205 | | | | | 206 | |----+ STUN | | 207 | | | | | 208 | | | | | 209 | | +--------+ | 210 | | | 211 | +---------------------+ | 212 | | | | 213 | | | | 214 | | NAT Function | | 215 | | | | 216 | +---------------------+ | 217 +------------+------------+ 218 | 219 |inside 220 | 221 | 223 Figure 3: Block Diagram of Internal NAT Operation 225 2.2. Interacting with Legacy NATs 227 There will be cases where the STUN client attempts to communicate 228 with an on-path NAT which does not support the usage described in 229 this document (that is, does not return the IP address of the 230 internal NAT binding using the XOR-INTERNAL-ADDRESS attribute) or 231 does not run a STUN server on its public interface. In both cases 232 cases the optimizations described in this document won't be available 233 to the STUN client and the STUN client will have to guess or assume 234 the NAT binding timeout of the on-path NATs between itself and the 235 first NAT that didn't run a STUN server. 237 Note: This is no worse than the condition today, and allows 238 incremental upgrades of applications and NATs that implement the 239 technique described in this document. 241 3. NAT Control Usage 243 This section describes a new STUN usage, following the recommendation 244 for defining a new usage in [I-D.ietf-behave-rfc3489bis]. 246 3.1. Applicability 248 This STUN usage MAY be used by a STUN client that discovers there is 249 a NAT between itself and its STUN server. Such discovery would most 250 likely occur with a STUN Bindng Request / Binding Response exchange 251 to a STUN server on the Internet, and by noticing the IP address and 252 UDP port indicated by the XOR-MAPPED-ADDRESS attribute of the STUN 253 Binding Response differs from the local socket's IP address and UDP 254 port. Such a difference indicates a NAT is present between the STUN 255 client and its STUN server. 257 3.2. Client Discovery of Server 259 As this usage involves communicating with on-path NATs directly, the 260 client needs to find those NATs. The outer-most NAT is found by the 261 normal XOR-MAPPED-ADDRESS attribute in a STUN Response. To iterate 262 through the inner NATs, each NAT needs to support the usage described 263 in this document, and the STUN client discovers each of those NATs by 264 iterating through the XOR-INTERNAL-ADDRESS attribute returned by 265 those NATs. This is described in diagrams and examples in Section 2. 267 3.3. Server Determination of Usage 269 If a STUN Binding Request is received from a NAT's private interface 270 and sent to the IP address of its public interface, the STUN server 271 can assume the NAT Control Usage. 273 3.4. New Requests or Indications 275 This usage does not define any new message types. 277 3.5. New Attributes 279 The following figure indicates which attributes are present in which 280 messages for this usage. An M indicates that inclusion of the 281 attribute in the message is mandatory, O means its optional, C means 282 it's conditional based on some other aspect of the message, and - 283 means that the attribute is not applicable to that message type. 285 Error 286 Attribute Request Response Response Indication 287 _________________________________________________________________ 288 XOR-INTERNAL-ADDRESS - M - - 289 REFRESH-INTERVAL O C - - 291 3.5.1. XOR-INTERNAL-ADDRESS 293 This attribute MUST be present in a Binding Response and may be used 294 in other responses as well. This attribute is necessary to allow a 295 STUN client to 'walk backwards' and communicate directly with all of 296 the STUN-aware NATs along the path. 298 The format of the XOR-INTERNAL-ADDRESS attribute is: 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |x x x x x x x x| Family | X-Port | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | X-Address (Variable) | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 Figure 5: XOR-INTERNAL-ADDRESS Attribute 310 The meaning of Family, X-Port, and X-Address are exactly as in 311 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 312 address family (IPv4 or IPv6). 314 3.5.2. REFRESH-INTERVAL 316 The REFRESH-INTERVAL attribute is defined in 317 [I-D.ietf-behave-rfc3489bis] where it can only appear in a response. 318 In the NAT Control usage defined in this document, the REFRESH- 319 INTERVAL may also appear in a request. 321 In a Binding Request, the REFRESH-INTERVAL indicates the desired 322 mapping timeout. In a Binding Response, the REFRESH-INTERVAL 323 indicates the NAT's mapping timeout. 325 3.6. Client Procedures 327 The STUN client sends a STUN Binding Request to its STUN server and 328 receives a STUN Binding Response, as normal. The STUN Binding 329 Response contains the XOR-MAPPED-ADDRESS attribute which indicates 330 the IP address and UDP port of the STUN Binding Request, as seen by 331 the STUN server. If this IP address differs from the STUN client's 332 IP address, the STUN client knows there is at least one NAT between 333 itself and the STUN server, and it continues with the procedure; 334 otherwise, it stops. 336 The STUN client now knows the public IP address of its outer-most NAT 337 -- it was returned in the XOR-MAPPED-ADDRESS attribute. The STUN 338 client performs the Short-Term Password usage with the public IP 339 address of its outer-most NAT, which is done over a TLS connection to 340 the STUN TCP port (3478), following the procedures in the Short-Term 341 Usage section of [I-D.ietf-behave-rfc3489bis]. As a result of the 342 Short-Term Password usage, the STUN client now has a STUN USERNAME 343 and PASSWORD which authenticate subsequent messages between the STUN 344 client and server. 346 If subsequent messages from the STUN server fail authentication, the 347 STUN client MUST re-obtain its IP address from a public STUN server, 348 not from its outer-most NAT (Section 6.3). 350 To modify an existing NAT mapping's attributes, or to request a new 351 NAT mapping, the STUN client can now send a STUN Binding Request to 352 the IP address of address in its outer-most NAT's STUN UDP port 353 (3478). The STUN server will respond with a STUN Binding Response 354 containing an XOR-MAPPED-ADDRESS attribute (which points at the NAT's 355 public IP address and port -- just as if the STUN Binding Request had 356 been sent to a STUN server on the public Internet) and an XOR- 357 INTERNAL-ADDRESS attribute (which points to the source IP address and 358 UDP port the packet STUN Binding Request packet had prior to being 359 NATted). 361 If the XOR-INTERNAL-ADDRESS attribute indicates an IP address and UDP 362 port different from the STUN client's own IP address and port, the 363 STUN client knows there is at least one NAT between itself and the 364 STUN server it last contacted. If the STUN client wants to use 365 multiple STUN servers, or wants to control the properties of the NAT 366 bindings in each of those NATs, the STUN client can iteratively 367 perform the Short-Term Password Usage followed by the Binding 368 Discovery Usage with each NAT learned via the XOR-INTERNAL-ADDRESS 369 attribute from the previous NAT. 371 In each case where the STUN client is sending STUN Binding Requests 372 to the NATs, the STUN client can also include other STUN attributes 373 to request certain properties for the flow. Requesting certain 374 properties may require the STUN client to obtain short-term 375 credentials. Defined in this document is a requested lifetime for 376 the NAT binding in order to reduce keepalive traffic (REFRESH- 377 INTERVAL). 379 3.7. Server Procedures 381 The server should listen for STUN Shared Secret Requests and STUN 382 Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478) 383 on its public IP address, from hosts connected to its private 384 interface(s). The NAT SHOULD only respond to such messags which 385 arrive from its 'internal' interface. STUN Binding Requests sent to 386 the NAT's public IP address which arrived from its public interface 387 SHOULD be handled as if the NAT isn't listening on that port (e.g., 388 return an ICMP error). 390 After receiving a STUN Shared Secret Request, the NAT follows the 391 procedures described in the Short-Term Usage section of 392 [I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store 393 that username and password so long as any NAT bindings, created or 394 adjusted with that same STUN username, have active mappings on the 395 NAT. 397 After receiving a STUN Binding Request containing the REFRESH- 398 INTERVAL attribute, the server SHOULD authenticate the request using 399 the USERNAME attribute and the previously-shared STUN password (this 400 is to defend against resource starvation attacks, see Section 6.1). 401 If authenticated, the new binding's lifetime can be maximized against 402 the NAT's configured sanity check and the lifetime indicated in the 403 REFRESH-INTERVAL attribute of the STUN Binding Response. 405 In addition to its other attributes, the Binding Response always 406 contains the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes. 407 The XOR-MAPPED-ADDRESS contains the public IP address and UDP port 408 for this binding. The XOR-INTERNAL-ADDRESS contains the IP address 409 and UDP port of the STUN Binding Request prior to the NAT 410 translation. The XOR-INTERNAL-ADDRESS is used by the STUN client to 411 walk backwards through nested NATs. 413 For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the 414 IP address and UDP port _prior to_ the NAPT operation. If there 415 is only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would 416 contain the STUN client's own IP address and UDP port. If there 417 are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP 418 address of the next NAT (that is, the next NAT closer to the STUN 419 client). Iterating over this procedure allows the STUN client to 420 find all of the NATs along the path. 422 4. Benefits 424 4.1. Incremental Deployment 426 NAT Control can be incrementally deployed. If the outer-most NAT 427 does not support it, the STUN client behaves as normal. Where the 428 outer-most STUN NAT does support it, the STUN client can gain some 429 significant optimizations as described in the following sections. 431 Likewise, there is no change to applications if NATs are deployed 432 which support NAT Control. 434 4.2. Optimize SIP-Outbound 436 In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 437 STUN server. This document enables two optimizations of SIP- 438 Outbound's keepalive mechanism: 440 1. STUN keepalive messages need only be sent to the outer-most NAT, 441 rather than across the access link to the SIP proxy, which vastly 442 reduces the traffic to the SIP proxy, and; 443 2. all of the on-path NATs can explicitly indicate their timeouts, 444 reducing the frequency of keepalive messages. 446 4.3. Optimize ICE 448 The NAT Control usage provides several opportunities to optimize ICE 449 [I-D.ietf-mmusic-ice]. 451 4.3.1. Candidate Gathering 453 During its candidate gathering phase, an ICE endpoint normally 454 contacts a STUN server on the Internet. If an ICE endpoint discovers 455 that its outer-most NAT runs a STUN server, the ICE endpoint can use 456 the outer-most NAT's STUN server rather than using the STUN server on 457 the Internet. This saves access bandwidth and reduces the reliance 458 on the STUN server on the Internet -- the STUN server on the Internet 459 need only be contacted once. 461 4.3.2. Keepalive 463 ICE uses STUN as its primary media stream keepalive mechansim. This 464 document enables two optimizations of ICE's keepalive techniques: 465 1. STUN keepalive messages need only be sent to the outer-most NAT, 466 rather than across the access link to the remote peer, and; 467 2. all of the on-path NATs can explicitly indicate their timeouts, 468 reducing the frequency of keepalive messages. 470 4.3.3. Learning STUN Servers without Configuration 472 ICE allows endpoints to have multiple STUN servers, but it is 473 difficult to configure all of the STUN servers in the ICE endpoint -- 474 it requires some awareness of network topology. By using the 'walk 475 backward' technique described in this document, all the on-path NATs 476 and their embedded STUN servers can be learned without additional 477 configuration. By knowing the STUN servers at each address domain, 478 ICE endpoints can optimize the network path between two peers. 480 For example, if endpoint-1 is only configured with the IP address of 481 the STUN server on the left, endpoint-1 can learn about NAT-B and 482 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 483 can optimize their media path so they make the optimial path from 484 endpoint-1 to NAT-A to endpoint-2: 486 +-------+ +-------+ +-------------+ 487 endpoint-1---| NAT-A +--+--+ NAT-B +---| STUN Server | 488 +-------+ | +-------+ +-------------+ 489 | 490 endpoint-2 492 5. Limitations 494 5.1. Nested NATs 496 If nested NATs have overlapping IP address space, there will be 497 undetected NATs on the path. Looking at the following figure, NAT-A 498 and NAT-B are both using 10.1.1.x as their 'private' network. When 499 this occurs, the STUN client will be unable to detect the presence of 500 NAT-A if NAT-A assigns the same UDP port. 502 +------+ +--------+ +--------+ 503 | 10.1.1.2 | 10.1.1.2 | 161.44.1.1 504 | STUN +-------+ NAT-A +-----+ NAT-B +------ 505 |client| 10.1.1.1 | 10.1.1.1 | 506 +------+ +--------+ +--------+ 508 5.2. Address Dependent Mapping 510 In order to utilize the mechanisms described in this document, a STUN 511 Request is sent from the same IP address and source port as the 512 original STUN Binding Discovery message, but is sent to a different 513 IP address (the IP address of an on-path NAT). If there is an on- 514 path NAT, between the STUN client and the STUN server, with address 515 depenent mapping behavior (as described in section 4.1 of 516 [I-D.ietf-behave-nat-udp]), that NAT will prevent a STUN client from 517 taking advantage of the technique described in this document. 519 An example of such a topology is shown in the following figure: 521 +------+ +--------+ +--------+ 522 | STUN | | 10.1.1.2 | 161.44.1.1 523 |client+-----+ NAT-A +---+ NAT-B +------ 524 | | 10.1.1.1 | 10.1.1.1 | 525 +------+ +--------+ +--------+ 526 address 527 dependent 528 mapping NAT 530 In this figure, NAT-A is a NAT that has address depenend mapping. 531 Thus, when the STUN client sends a STUN Binding Request to 161.44.1.1 532 on UDP/3478, NAT-A will choose a new public UDP port for that 533 communication. NAT-B will function normally, returning a different 534 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 535 that a symmetric NAT exists between the STUN client and the STUN 536 server it just queried (NAT-B, in this example). 538 Open issue: We could resolve this problem by introducing a new 539 STUN attribute which indicates the UDP port the STUN client wants 540 to control. However, this changes the security properties of NAT 541 Control, so this seems undesirable. 542 Open issue: When the STUN client detects this situation, should 543 we recommend it abandon the NAT Control usage, and revert to 544 operation as if it doesn't support the NAT Control usage? 546 5.3. Address Dependent Filtering 548 If there is an NAT along the path that has address dependent 549 filtering (as described in section 5 of NAT-UDP), and the STUN client 550 sends a STUN packet directly to any of the on-path NATs public 551 addresses, the address-dependent filtering NAT will filter packets 552 from the remote peer. Thus, after communicating with all of the on- 553 path NATs the STUN client MUST send a UDP packet to the remote peer, 554 if the remote peer is known. 556 Discussion: How many filter entries are in address dependent 557 filtering NATs? If only one, this does become a real limitation 558 if NATs are nested; if they're not nested, the outer-most NAT can 559 avoid overwriting its own address in its address depenent filter. 561 6. Security Considerations 563 This security considerations section will be expanded in a subsequent 564 version of this document. So far, the authors have identified the 565 following considerations: 567 6.1. Authorization and Resource Exhaustion 569 Only hosts that are 'inside' a NAT, which a NAT is already providing 570 services for, can query or adjust the timeout of a NAT mapping. 572 A malicious STUN client could ask for absurdly long NAT bindings 573 (days) for many UDP sessions, which would exhaust the resources in 574 the NAT. To ensure the STUN client is not spoofing its IP address 575 when launching such an attack, the STUN server can challange requests 576 to extend the timeout by sending a NONCE to the STUN client. The 577 STUN server can authorize an extension to the refresh timeout if a 578 new request is sent with that same NONCE value. 580 Without considering this document and without considering STUN or 581 other UNSAF NAT traversal techniques, a malicious TCP client can open 582 many TCP connections, and keep them open, causing resource exhaustion 583 in the NAT. A NAT which provide protection against such a TCP attack 584 can provide a similar level of protection, via the NONCE challange/ 585 response, as they can for TCP sessions. 587 6.2. Comparison to Other NAT Control Techniques 589 Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage 590 described in this document alllows a host to learn its public IP 591 address and UDP port mapping, and to request a specific lifetime for 592 that mapping. 594 However, unlike those technologies, the NAT Control usage described 595 in this dcoument only allows each UDP port on the host to create and 596 adjust the mapping timeout of its own NAT mappings. Specifically, an 597 application on a host can only adjust the duration of a NAT bindings 598 for itself, and not for another application on that same host, and 599 not for other hosts. This provides security advantages over other 600 NAT control mechanisms where malicious software on a host can 601 surreptitiously create NAT mappings to another application or to 602 another host. 604 6.3. Rogue STUN Server 606 As described in Section 4, a STUN client can learn its outer-most NAT 607 runs an embedded STUN server. Without the STUN client's knowledge, 608 the outer-most NAT may acquire a new IP address (after moving to a 609 new mobile network or DHCP lease expiration). When it acquires a new 610 IP address, the STUN client will send a STUN Binding Request to the 611 NAT's prior public IP address. If an attacker acquires that public 612 IP address and installs a rogue STUN server, the attacker has 613 effectively acheived the attack "Compromise a Legitimate STUN Server" 614 (section 12.2.1 of [RFC3489]). The attacker will send STUN Binding 615 Responses indicating his IP address, which will be indistingushable, 616 to the STUN client, from the behavior of the legitimate STUN server. 617 To defend against this attack, the STUN client and STUN server need 618 to obtain a short-term password as described in 619 [I-D.ietf-behave-rfc3489bis]. 621 7. IANA Considerations 623 This document will add new IANA registrations for new STUN 624 attributes. 626 [[This section will be completed in a later version of this 627 document.]] 629 8. References 631 8.1. Normative References 633 [I-D.ietf-behave-rfc3489bis] 634 Rosenberg, J., "Simple Traversal Underneath Network 635 Address Translators (NAT) (STUN)", 636 draft-ietf-behave-rfc3489bis-04 (work in progress), 637 July 2006. 639 [I-D.ietf-behave-nat-udp] 640 Audet, F. and C. Jennings, "NAT Behavioral Requirements 641 for Unicast UDP", draft-ietf-behave-nat-udp-08 (work in 642 progress), October 2006. 644 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 645 "STUN - Simple Traversal of User Datagram Protocol (UDP) 646 Through Network Address Translators (NATs)", RFC 3489, 647 March 2003. 649 8.2. Informational References 651 [UPnP] UPnP Forum, "Universal Plug and Play", 2000, 652 . 654 [Bonjour] Apple Computer, "Bonjour", 2005, 655 . 657 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 658 A. Rayhan, "Middlebox communication architecture and 659 framework", RFC 3303, August 2002. 661 [I-D.ietf-mmusic-ice] 662 Rosenberg, J., "Interactive Connectivity Establishment 663 (ICE): A Methodology for Network Address Translator (NAT) 664 Traversal for Offer/Answer Protocols", 665 draft-ietf-mmusic-ice-11 (work in progress), October 2006. 667 [I-D.ietf-sip-outbound] 668 Jennings, C. and R. Mahy, "Managing Client Initiated 669 Connections in the Session Initiation Protocol (SIP)", 670 draft-ietf-sip-outbound-04 (work in progress), June 2006. 672 Authors' Addresses 674 Dan 675 Cisco Systems 676 170 West Tasman Drive 677 San Jose, CA 95134 678 USA 680 Email: dwing@cisco.com 682 Jonathan 683 Cisco Systems 684 600 Lanidex Plaza 685 Parsippany, NJ 07054 686 USA 688 Email: jdrosen@cisco.com 690 Full Copyright Statement 692 Copyright (C) The Internet Society (2006). 694 This document is subject to the rights, licenses and restrictions 695 contained in BCP 78, and except as set forth therein, the authors 696 retain all their rights. 698 This document and the information contained herein are provided on an 699 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 700 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 701 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 702 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 703 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 704 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Intellectual Property 708 The IETF takes no position regarding the validity or scope of any 709 Intellectual Property Rights or other rights that might be claimed to 710 pertain to the implementation or use of the technology described in 711 this document or the extent to which any license under such rights 712 might or might not be available; nor does it represent that it has 713 made any independent effort to identify any such rights. Information 714 on the procedures with respect to rights in RFC documents can be 715 found in BCP 78 and BCP 79. 717 Copies of IPR disclosures made to the IETF Secretariat and any 718 assurances of licenses to be made available, or the result of an 719 attempt made to obtain a general license or permission for the use of 720 such proprietary rights by implementers or users of this 721 specification can be obtained from the IETF on-line IPR repository at 722 http://www.ietf.org/ipr. 724 The IETF invites any interested party to bring to its attention any 725 copyrights, patents or patent applications, or other proprietary 726 rights that may cover technology that may be required to implement 727 this standard. Please address the information to the IETF at 728 ietf-ipr@ietf.org. 730 Acknowledgment 732 Funding for the RFC Editor function is provided by the IETF 733 Administrative Support Activity (IASA).