idnits 2.17.00 (12 Aug 2021) /tmp/idnits38741/draft-wing-behave-nat-control-stun-usage-01.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, updated by RFC 4748 on line 868. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 879. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 892. 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 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 has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? 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 (February 13, 2007) is 5576 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 ** 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: 2 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE D. Wing 3 Internet-Draft J. Rosenberg 4 Intended status: Standards Track Cisco Systems 5 Expires: August 17, 2007 February 13, 2007 7 Controlling NAT Bindings using STUN 8 draft-wing-behave-nat-control-stun-usage-01 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 August 17, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 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. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Conventions Used in this Document . . . . . . . . . . . . . . 4 58 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 59 4.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . . . 7 60 4.2. Interacting with Legacy NATs . . . . . . . . . . . . . . . 9 61 5. NAT Control Usage . . . . . . . . . . . . . . . . . . . . . . 9 62 5.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 10 63 5.2. Client Discovery of Server . . . . . . . . . . . . . . . . 10 64 5.3. Server Determination of Usage . . . . . . . . . . . . . . 10 65 5.4. New Requests or Indications . . . . . . . . . . . . . . . 10 66 5.5. New Attributes . . . . . . . . . . . . . . . . . . . . . . 10 67 5.5.1. XOR-INTERNAL-ADDRESS . . . . . . . . . . . . . . . . . 11 68 5.5.2. REFRESH-INTERVAL . . . . . . . . . . . . . . . . . . . 11 69 5.6. Client Procedures . . . . . . . . . . . . . . . . . . . . 11 70 5.7. Server Procedures . . . . . . . . . . . . . . . . . . . . 12 71 6. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 72 6.1. Incremental Deployment . . . . . . . . . . . . . . . . . . 13 73 6.2. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 14 74 6.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 14 75 6.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 14 76 6.3.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 14 77 6.3.3. Learning STUN Servers without Configuration . . . . . 15 78 7. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 7.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 15 80 7.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 16 81 7.3. Address Dependent Filtering . . . . . . . . . . . . . . . 16 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 83 8.1. Authorization and Resource Exhaustion . . . . . . . . . . 17 84 8.2. Comparison to Other NAT Control Techniques . . . . . . . . 17 85 8.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 18 86 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 87 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 89 10.2. Informational References . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 Intellectual Property and Copyright Statements . . . . . . . . . . 21 93 1. Introduction 95 Two common usages of STUN [I-D.ietf-behave-rfc3489bis] are Binding 96 Discovery and NAT Keepalive. The Binding Discovery usage allows a 97 STUN client to learn its public IP address (from the perspective of 98 the STUN server it contacted) and the NAT keepalive usage allows a 99 STUN client to keep an active NAT binding alive. Unlike some other 100 techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), 101 STUN does not interact directly with the NAT. Because STUN doesn't 102 interact directly with the NAT, STUN cannot request additional 103 services from the NAT such as longer lifetimes (which would reduce 104 keepalive messages). 106 This paper describes a mechanism for the STUN client to interact 107 directly with the NAT and request additional services, by using the 108 STUN protocol itself. Thereafter, the STUN client need only ask that 109 NAT's embedded STUN server for public IP addresses and UDP ports -- 110 as it will return the same information as the public STUN server. 111 Additionally, the STUN client can ask the NAT's embedded STUN server 112 to extend the NAT binding for the flow, and the STUN client can learn 113 the IP address of the next-outermost NAT. By repeating this 114 procedure with the next-outermost NAT, all of the NATs along that 115 path can have their bindings extended. By learning all of the STUN 116 servers on the path between the public Internet and itself, an 117 endpoint can optimize the path of peer-to-peer communications. 119 2. Motivation 121 There are a number of problems with existing NAT traversal techniques 122 such as STUN [RFC3489], [UPnP], and [Bonjour]): 124 nested NATs 125 Today, many ISPs provide their subscribers with modems that have 126 embedded NATs, often with only one physical Ethernet port. These 127 subscribers then install NATs behind those devices to provide 128 additional features, such as wireless access. 130 Nested NATs are, unfortunately, becoming quite common and often 131 occur without the knowledge of users. For example, some ISPs 132 provide their subscribers with modems that include integrated NAT 133 functionality. When the subscriber installs another NAT, perhaps 134 to provide himself with wireless network access, the endpoints are 135 now behind nested NATs. Another example is a NAT in the basement 136 of an apartment building or a campus dormitory, which combined 137 with a NAT within the home or dormitory room also result in nested 138 NATs. In both of these situations, UPnP and Bonjour no longer 139 function at all, as those protocols can only control the first 140 NAT. STUN continues to function, but is unable to optimize 141 network traffic behind those nested NATs (e.g., traffic that stays 142 within the same house or within the same apartment building). The 143 technique described in this paper allows optimization of the 144 traffic behind those NATs so that the traffic can traverse the 145 fewest NATs possible. 147 chattiness 148 To perform its binding discovery, a STUN client communicates to a 149 server on the Internet. This consumes bandwidth across the user's 150 access network which in some cases is bandwidth constrained (e.g., 151 wireless, satellite). 153 STUN's chattiness is often cited as a reason to use other NAT 154 traversal techniques such as UPnP or Bonjour. However, those NAT 155 traversal techniques bring restrictions (they both require a UPnP- 156 aware or Bonjour-aware NAT, they do not work with nested NATs, and 157 they only work within one broadcast domain). The technique 158 described in this paper provides a significant reduction in STUN's 159 chattiness, to the point that the only time a STUN client needs to 160 communicate with the STUN server on the public Internet is when 161 the STUN client is initialized. 163 incremental deployment 164 Many NAT traversal techniques require the endpoint and the NAT to 165 both support the new feature or else NAT traversal isn't possible 166 at all. 168 However, the technique described in this paper allows incremental 169 deployment of local endpoints, local NATs, and remote endpoints 170 and their remote NATs which support the features described in this 171 paper. Only the local endpoints and the NATs on the path to their 172 STUN server need to implement the technique in this paper to 173 optimize their functionality. 175 3. Conventions Used in this Document 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 4. Overview of Operation 183 When a STUN client sends a STUN Request to a STUN server, it receives 184 a STUN Response which indicates the IP address and UDP port seen by 185 the STUN server. If the IP address and UDP port differs from the IP 186 address and UDP port of the socket used to send the request, the STUN 187 client knows there is at least one NAT between itself and the STUN 188 server, and knows the 'public' IP address of that NAT. For example, 189 in the following diagram, the STUN client learns the public IP 190 address of its NAT is 192.0.2.1: 192 +--------+ +---------------+ 193 | STUN | | 192.0.2.1 +--------+ 194 | Client +-------------+ +------+ STUN | 195 | 10.1.1.2/4193 10.1.1.1 | | Server | 196 +--------+ | | +--------+ 197 | NAT with | 198 | Embedded STUN | 199 | Server | 200 +---------------+ 202 Figure 1: One NAT with embedded STUN server 204 After learning the public IP address of its outer-most NAT, the STUN 205 client attempts to communicate with the STUN server embedded in that 206 outer-most NAT. The STUN client does this by first obtaining a 207 shared secret, over a TLS connection, to the NAT's public IP address 208 (192.0.2.1 in the figure above). After obtaining a shared secret, it 209 sends a STUN Binding Request to the NAT's public IP address. The NAT 210 will return a STUN Binding Response message including the XOR- 211 INTERNAL-ADDRESS attribute, which will indicate the IP address and 212 UDP port seen on the *internal* side of the NAT for that translation. 213 In the example above, the IP address and UDP port indicated in XOR- 214 INTERNAL-ADDRESS are the same as that used by the STUN client 215 (10.1.1.2/4193), which indicates there are no other NATs between the 216 STUN client and that outer-most NAT. 218 STUN Client NAT STUN Server 219 | | | 220 1. |-----TLS/TCP----------------------------->| } 221 2. |-----Shared Secret Request (TLS)--------->| } 222 3. |<----Shared Secret Response (TLS)---------| } normal STUN 223 4. |-----TCP connection closed--------------->| } behavior 224 5. |-----Binding Request (UDP)--------------->| } 225 6. |<----Binding Response (UDP)---------------| } 226 | | | 227 7. |-----TLS/TCP------------------>| | } 228 8. |--Shared Secret Request (TLS)->| | } 229 9. |<-Shared Secret Response (TLS)-| | } NAT Control 230 10. |--TCP connection closed------->| | } STUN Usage 231 11. |--Binding Request (UDP)------->| | } 232 12. |<-Binding Response (UDP)-------| | } 233 | | | 235 Figure 2: Communication Flow 237 In the call flow above, steps 1-6 are normal STUN behavior 238 [I-D.ietf-behave-rfc3489bis]: 240 1: STUN client initiates a TLS-over-TCP connection to its STUN 241 server on the Internet. 243 2: Using that connection, the STUN client sends Shared Secret 244 Request to that STUN server. 246 3: Using that connection, the STUN server sends Shared Secret 247 Response. This contains the STUN username the client should use 248 for subsequent queries to this STUN server, and the STUN password 249 that will be used to integrity-protect subsequent STUN messages 250 with this STUN server. 252 4: TCP connection is closed. 254 5: STUN client sends UDP Binding Request to its STUN server on the 255 Internet, using the STUN username obtained from that STUN server 256 (from step 3). 258 6: STUN server responds with UDP Binding Response, integrity 259 protected with the STUN password (from step 3). The STUN client 260 now knows the public IP address of its outer-most NAT. This is 261 used in the next step. 263 The next steps are the additional steps performed by a STUN client 264 that has implemented the NAT Control STUN Usage: 266 7: STUN client initiates a TLS-over-TCP connection to the STUN 267 server embedded in its outer-most NAT. 269 8: Using that connection, the STUN client sends Shared Secret 270 Request to that STUN server. 272 9: Using that connection, the STUN server sends Shared Secret 273 Response. This contains the STUN username the client should use 274 for subsequent queries to this STUN server, and the STUN 275 password that will be used to integrity-protect subsequent STUN 276 messages with this STUN server. 278 10: TCP connection is closed. 280 11: STUN client sends UDP Binding Request to the STUN server 281 embedded in its outer-most NAT, using the STUN username obtained 282 from from that STUN server (from step 10). 284 12: STUN server responds with UDP Binding Response, integrity 285 protected with the STUN password (from step 10). 287 The response obtained in the message 12 contains the XOR-MAPPED- 288 ADDRESS attribute which will have the same value as when the STUN 289 server on the Internet responded (in step 6). The STUN client can 290 perform steps 11-12 for any new UDP communication (e.g., for every 291 new phone call), without needing to repeat steps 1-10. This meets 292 the desire to reduce chattiness. 294 The response obtained in message 12 will also contain the XOR- 295 INTERNAL-ADDRESS, which allows the STUN client to repeat steps 7-12 296 in order to communicate with all the on-path NATs between itself and 297 its STUN server on the Internet. This is described in detail in 298 section Section 4.1. This meets the desire to optimize traffic 299 between nested NATs. 301 The STUN client can request each NAT to increase the binding 302 lifetime, as described in Section 5.5. The STUN client receives 303 positive confirmation that the binding lifetime has been extended, 304 allowing the STUN client to significantly reduces its NAT keepalive 305 traffic. Additionally, as long as the NAT complies with [RFC4787], 306 the STUN client's keepalive traffic need only be sent to the outer- 307 most NAT's IP address. This further meets the desire to reduce 308 chattiness. 310 4.1. Nested NATs 312 Nested NATs are controlled individually. The nested NATs are 313 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 314 INTERNAL-ADDRESS attribute. 316 The following diagram shows how a STUN client iterates over the NATs 317 to communicate with all of the NATs in the path. First, the STUN 318 client would learn the outer-most NAT's IP address by performing the 319 steps above. In the case below, however, the IP address and UDP port 320 indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's 321 own IP address and UDP port -- rather, it's the IP address and UDP 322 port on the *outer* side of the NAT-B -- 10.1.1.2. 324 Because of this, the STUN client repeats the procedure and sends 325 another STUN Binding Request to that newly-learned address (the 326 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 327 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 328 match the STUN client's IP address and UDP port. The STUN client 329 knows there are no other NATs between itself and NAT-B, and finishes. 331 +------+ +--------+ +--------+ 332 | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ 333 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 334 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 335 +------+ +--------+ +--------+ 337 Figure 3: Two NATs with embedded STUN servers 339 Internally, the NAT can be diagrammed to function like this, where 340 the NAT operation occurs before the STUN server. 342 | 343 | outside interface 344 | 345 +---------+---------------+ 346 | | | 347 | | +--------+ | 348 | |----+ STUN | | 349 | | | Server | | 350 | | +--------+ | 351 | | | 352 | +-------+-------------+ | 353 | | NAT Function | | 354 | +-------+-------------+ | 355 | | | 356 +---------+---------------+ 357 | 358 | inside interface 359 | 360 | 362 Figure 4: Block Diagram of Internal NAT Operation 364 4.2. Interacting with Legacy NATs 366 There will be cases where the STUN client attempts to communicate 367 with an on-path NAT which does not support the usage described in 368 this document. There are two cases: 370 o the NAT does not run a STUN server on its public interface (this 371 will be the most common) 373 o the NAT does run a STUN server on its public interface, but 374 doesn't return the XOR-INTERNAL-ADDRESS attribute defined in this 375 document 377 In both cases the optimizations described in this document won't be 378 available to the STUN client and the STUN client. This is no worse 379 than the condition today. This allows incremental upgrades of 380 applications and NATs that implement the technique described in this 381 document. 383 5. NAT Control Usage 385 This section describes a new STUN usage, following the recommendation 386 for defining a new usage in [I-D.ietf-behave-rfc3489bis]. 388 5.1. Applicability 390 This STUN usage MAY be used by a STUN client that discovers there is 391 a NAT between itself and its STUN server. Such discovery would most 392 likely occur with a STUN Binding Request / Binding Response exchange 393 to a STUN server on the Internet, and by noticing the IP address and 394 UDP port indicated by the XOR-MAPPED-ADDRESS attribute of the STUN 395 Binding Response differs from the local socket's IP address and UDP 396 port. Such a difference indicates a NAT is present between the STUN 397 client and its STUN server. 399 5.2. Client Discovery of Server 401 As this usage involves communicating with on-path NATs directly, the 402 client needs to find those NATs. The outer-most NAT is found by the 403 normal XOR-MAPPED-ADDRESS attribute in a STUN Response. To iterate 404 through the inner NATs, each NAT needs to support the usage described 405 in this document, and the STUN client discovers each of those NATs by 406 iterating through the XOR-INTERNAL-ADDRESS attribute returned by 407 those NATs. This is described in diagrams and examples in Section 4. 409 5.3. Server Determination of Usage 411 If a STUN Binding Request is received from a NAT's private interface 412 and sent to the IP address of its public interface, the STUN server 413 can assume the NAT Control Usage. 415 5.4. New Requests or Indications 417 This usage does not define any new message types. 419 5.5. New Attributes 421 The following figure indicates which attributes are present in which 422 messages for this usage. An M indicates that inclusion of the 423 attribute in the message is mandatory, O means its optional, C means 424 it's conditional based on some other aspect of the message, and - 425 means that the attribute is not applicable to that message type. 427 Error 428 Attribute Request Response Response Indication 429 _________________________________________________________________ 430 XOR-INTERNAL-ADDRESS - M - - 431 REFRESH-INTERVAL O C - - 433 5.5.1. XOR-INTERNAL-ADDRESS 435 This attribute MUST be present in a Binding Response and may be used 436 in other responses as well. This attribute is necessary to allow a 437 STUN client to 'walk backwards' and communicate directly with all of 438 the STUN-aware NATs along the path. 440 The format of the XOR-INTERNAL-ADDRESS attribute is: 442 0 1 2 3 443 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 444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 |x x x x x x x x| Family | X-Port | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | X-Address (Variable) | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 Figure 6: XOR-INTERNAL-ADDRESS Attribute 452 The meaning of Family, X-Port, and X-Address are exactly as in 453 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 454 address family (IPv4 or IPv6). 456 5.5.2. REFRESH-INTERVAL 458 The REFRESH-INTERVAL attribute is defined in 459 [I-D.ietf-behave-rfc3489bis] where it can only appear in a response. 460 In the NAT Control usage defined in this document, the REFRESH- 461 INTERVAL may also appear in a request. 463 In a Binding Request, the REFRESH-INTERVAL indicates the desired 464 mapping timeout. In a Binding Response, the REFRESH-INTERVAL 465 indicates the NAT's mapping timeout. 467 5.6. Client Procedures 469 The STUN client sends a STUN Binding Request to its STUN server on 470 the Internet and receives a STUN Binding Response, as normal. The 471 STUN Binding Response contains the XOR-MAPPED-ADDRESS attribute which 472 indicates the IP address and UDP port of the STUN Binding Request, as 473 seen by the STUN server. If this IP address differs from the STUN 474 client's IP address, the STUN client knows there is at least one NAT 475 between itself and the STUN server, and it continues with the 476 procedure; otherwise, it stops. 478 The STUN client now knows the public IP address of its outer-most NAT 479 -- it was returned in the XOR-MAPPED-ADDRESS attribute. The STUN 480 client performs the Shared Secret Usage (as described in 482 [I-D.ietf-behave-rfc3489bis]) with the public IP address of its 483 outer-most NAT. After performing that usage, the STUN client now has 484 a STUN USERNAME and PASSWORD which authenticate subsequent messages 485 between the STUN client and this NAT's STUN server. 487 If subsequent messages from the STUN server fail authentication, the 488 STUN client MUST re-obtain its IP address from a public STUN server, 489 not from its outer-most NAT (see section Section 8.3). 491 To modify an existing NAT mapping's attributes, or to request a new 492 NAT mapping for a new UDP port, the STUN client can now send a STUN 493 Binding Request to the IP address of address in its outer-most NAT's 494 STUN UDP port (3478). The NAT's STUN server will respond with a STUN 495 Binding Response containing an XOR-MAPPED-ADDRESS attribute (which 496 points at the NAT's public IP address and port -- just as if the STUN 497 Binding Request had been sent to a STUN server on the public 498 Internet) and an XOR-INTERNAL-ADDRESS attribute (which points to the 499 source IP address and UDP port the packet STUN Binding Request packet 500 had prior to being NATted). 502 If the XOR-INTERNAL-ADDRESS attribute indicates an IP address and UDP 503 port different from the STUN client's own IP address and port, the 504 STUN client knows there is at least one NAT between itself and the 505 STUN server it last contacted. If the STUN client wants to use 506 multiple STUN servers, or wants to control the properties of the NAT 507 bindings in each of those NATs, the STUN client can iteratively 508 perform the Short-Term Password Usage followed by the Binding 509 Discovery Usage with each NAT learned via the XOR-INTERNAL-ADDRESS 510 attribute from the previous NAT. 512 In each case where the STUN client is sending STUN Binding Requests 513 to the NATs, the STUN client can also include other STUN attributes 514 to request certain properties for the flow. Requesting certain 515 properties may require the STUN client to obtain short-term 516 credentials. Defined in this document is a requested lifetime for 517 the NAT binding in order to reduce keepalive traffic (REFRESH- 518 INTERVAL). 520 5.7. Server Procedures 522 The server should listen for STUN Shared Secret Requests and STUN 523 Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478) 524 on its public IP address, from hosts connected to its private 525 interface(s). The NAT SHOULD only respond to such message which 526 arrive from its 'internal' interface. STUN Binding Requests sent to 527 the NAT's public IP address which arrived from its public interface 528 SHOULD be handled as if the NAT isn't listening on that port (e.g., 529 return an ICMP error). 531 After receiving a STUN Shared Secret Request, the NAT follows the 532 procedures described in the Short-Term Usage section of 533 [I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store 534 that username and password so long as any NAT bindings, created or 535 adjusted with that same STUN username, have active mappings on the 536 NAT. 538 After receiving a STUN Binding Request containing the REFRESH- 539 INTERVAL attribute, the server SHOULD authenticate the request using 540 the USERNAME attribute and the previously-shared STUN password (this 541 is to defend against resource starvation attacks, see Section 8.1). 542 If authenticated, the new binding's lifetime can be maximized against 543 the NAT's configured sanity check and the lifetime indicated in the 544 REFRESH-INTERVAL attribute of the STUN Binding Response. 546 In addition to its other attributes, the Binding Response always 547 contains the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes. 548 The XOR-MAPPED-ADDRESS contains the public IP address and UDP port 549 for this binding. The XOR-INTERNAL-ADDRESS contains the IP address 550 and UDP port of the STUN Binding Request prior to the NAT 551 translation. The XOR-INTERNAL-ADDRESS is used by the STUN client to 552 walk backwards through nested NATs. 554 For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the 555 IP address and UDP port _prior to_ the NAPT operation. If there 556 is only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would 557 contain the STUN client's own IP address and UDP port. If there 558 are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP 559 address of the next NAT (that is, the next NAT closer to the STUN 560 client). Iterating over this procedure allows the STUN client to 561 find all of the NATs along the path. 563 6. Benefits 565 6.1. Incremental Deployment 567 NAT Control can be incrementally deployed. If the outer-most NAT 568 does not support it, the STUN client behaves as normal. Where the 569 outer-most STUN NAT does support it, the STUN client can gain some 570 significant optimizations as described in the following sections. 572 Likewise, there is no change to applications if NATs are deployed 573 which support NAT Control. 575 6.2. Optimize SIP-Outbound 577 In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 578 STUN server. This document enables two optimizations of SIP- 579 Outbound's keepalive mechanism: 581 1. STUN keepalive messages need only be sent to the outer-most NAT, 582 rather than across the access link to the SIP proxy, which vastly 583 reduces the traffic to the SIP proxy, and; 585 2. all of the on-path NATs can explicitly indicate their timeouts, 586 reducing the frequency of keepalive messages. 588 6.3. Optimize ICE 590 The NAT Control usage provides several opportunities to optimize ICE 591 [I-D.ietf-mmusic-ice]. 593 6.3.1. Candidate Gathering 595 During its candidate gathering phase, an ICE endpoint normally 596 contacts a STUN server on the Internet. If an ICE endpoint discovers 597 that its outer-most NAT runs a STUN server, the ICE endpoint can use 598 the outer-most NAT's STUN server rather than using the STUN server on 599 the Internet. This saves access bandwidth and reduces the reliance 600 on the STUN server on the Internet -- the STUN server on the Internet 601 need only be contacted once. 603 6.3.2. Keepalive 605 [Note: In ICE-13, the keepalives were changed to STUN 606 Indications. If this change to ICE becomes working group 607 consensus for ICE keepalives, this section in this document should 608 be deleted.] 610 ICE uses STUN as its primary media stream keepalive mechanism. This 611 document enables two optimizations of ICE's keepalive techniques: 613 1. STUN keepalive messages need only be sent to the outer-most NAT, 614 rather than across the access link to the remote peer, and; 616 2. all of the on-path NATs can explicitly indicate their timeouts, 617 reducing the frequency of keepalive messages. 619 6.3.3. Learning STUN Servers without Configuration 621 ICE allows endpoints to have multiple STUN servers, but it is 622 difficult to configure all of the STUN servers in the ICE endpoint -- 623 it requires some awareness of network topology. By using the 'walk 624 backward' technique described in this document, all the on-path NATs 625 and their embedded STUN servers can be learned without additional 626 configuration. By knowing the STUN servers at each address domain, 627 ICE endpoints can optimize the network path between two peers. 629 For example, if endpoint-1 is only configured with the IP address of 630 the STUN server on the left, endpoint-1 can learn about NAT-B and 631 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 632 can optimize their media path so they make the optimal path from 633 endpoint-1 to NAT-A to endpoint-2: 635 +-------+ +-------+ +-------------+ 636 endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | 637 +-------+ | +-------+ +-------------+ 638 | 639 endpoint-2 641 7. Limitations 643 7.1. Overlapping IP Addresses with Nested NATs 645 If nested NATs have overlapping IP address space, there will be 646 undetected NATs on the path. When this occurs, the STUN client will 647 be unable to detect the presence of NAT-A if NAT-A assigns the same 648 UDP port. For example, in the following figure, NAT-A and NAT-B are 649 both using 10.1.1.x as their 'private' network. 651 +------+ +--------+ +--------+ 652 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1 653 | STUN +-------+ NAT-A +-----+ NAT-B +------ 654 |client| 10.1.1.1 | 10.1.1.1 | 655 +------+ +--------+ +--------+ 657 Figure 8: Overlapping Addresses with Nested NATs 659 When this situation occurs, the STUN client can only learn the outer- 660 most address. This isn't a problem -- the STUN client is still able 661 to communicate with the outer-most NAT and is still able to avoid 662 consuming access network bandwidth and avoid communicating with the 663 public STUN server. All that is lost is the ability to optimize 664 paths within the private network that has overlapped addresses. 666 7.2. Address Dependent NAT on Path 668 In order to utilize the mechanisms described in this document, a STUN 669 Request is sent from the same source IP address and source port as 670 the original STUN Binding Discovery message, but is sent to a 671 different destination IP address -- it is sent to the IP address of 672 an on-path NAT. If there is an on-path NAT, between the STUN client 673 and the STUN server, with 'address dependent' or 'address and port- 674 dependent' mapping behavior (as described in section 4.1 of 675 [RFC4787]), that NAT will prevent a STUN client from taking advantage 676 of the technique described in this document. When this occurs, the 677 ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and 678 the NAT's embedded STUN server will differ. 680 An example of such a topology is shown in the following figure: 682 +------+ +--------+ +--------+ 683 | STUN | | 10.1.1.2 | 192.0.2.1 684 |client+-----+ NAT-A +---+ NAT-B +------ 685 | | 10.1.1.1 | 10.1.1.1 | 686 +------+ +--------+ +--------+ 688 In this figure, NAT-A is a NAT that has address dependent mapping. 689 Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1 690 on UDP/3478, NAT-A will choose a new public UDP port for that 691 communication. NAT-B will function normally, returning a different 692 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 693 that a symmetric NAT exists between the STUN client and the STUN 694 server it just queried (NAT-B, in this example). 696 Figure 9: Address Dependant NAT on Path 698 Open issue: We could resolve this problem by introducing a new 699 STUN attribute which indicates the UDP port the STUN client wants 700 to control. However, this changes the security properties of NAT 701 Control, so this seems undesirable. 703 Open issue: When the STUN client detects this situation, should 704 we recommend it abandon the NAT Control usage, and revert to 705 operation as if it doesn't support the NAT Control usage? 707 7.3. Address Dependent Filtering 709 If there is an NAT along the path that has address dependent 710 filtering (as described in section 5 of [RFC4787]), and the STUN 711 client sends a STUN packet directly to any of the on-path NATs public 712 addresses, the address-dependent filtering NAT will filter packets 713 from the remote peer. Thus, after communicating with all of the on- 714 path NATs the STUN client MUST send a UDP packet to the remote peer, 715 if the remote peer is known. 717 Discussion: How many filter entries are in address dependent 718 filtering NATs? If only one, this does become a real limitation 719 if NATs are nested; if they're not nested, the outer-most NAT can 720 avoid overwriting its own address in its address dependent filter. 722 8. Security Considerations 724 This security considerations section will be expanded in a subsequent 725 version of this document. So far, the authors have identified the 726 following considerations: 728 8.1. Authorization and Resource Exhaustion 730 Only hosts that are 'inside' a NAT, which a NAT is already providing 731 services for, can query or adjust the timeout of a NAT mapping. 733 A malicious STUN client could ask for absurdly long NAT bindings 734 (days) for many UDP sessions, which would exhaust the resources in 735 the NAT. To ensure the STUN client is not spoofing its IP address 736 when launching such an attack, the STUN server can challenge requests 737 to extend the timeout by sending a NONCE to the STUN client. The 738 STUN server can authorize an extension to the refresh timeout if a 739 new request is sent with that same NONCE value. 741 Without considering this document and without considering STUN or 742 other UNSAF NAT traversal techniques, a malicious TCP client can open 743 many TCP connections, and keep them open, causing resource exhaustion 744 in the NAT. A NAT which provide protection against such a TCP attack 745 can provide a similar level of protection, via the NONCE challange/ 746 response, as they can for TCP sessions. 748 8.2. Comparison to Other NAT Control Techniques 750 Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage 751 described in this document allows a host to learn its public IP 752 address and UDP port mapping, and to request a specific lifetime for 753 that mapping. 755 However, unlike those technologies, the NAT Control usage described 756 in this document only allows each UDP port on the host to create and 757 adjust the mapping timeout of its own NAT mappings. Specifically, an 758 application on a host can only adjust the duration of a NAT bindings 759 for itself, and not for another application on that same host, and 760 not for other hosts. This provides security advantages over other 761 NAT control mechanisms where malicious software on a host can 762 surreptitiously create NAT mappings to another application or to 763 another host. 765 8.3. Rogue STUN Server 767 As described in Section 6, a STUN client can learn its outer-most NAT 768 runs an embedded STUN server. However, without the STUN client's 769 knowledge, the outer-most NAT may acquire a new IP address. This 770 could occur when the NAT moves to a new mobile network or its DHCP 771 lease expires. When the NAT acquires a new IP address, the STUN 772 client will send a STUN Binding Request to the NAT's prior public IP 773 address, which will be routed to the NAT's previous address. 775 If an attacker runs a rogue STUN server on that address, the attacker 776 has effectively compromised the STUN server (the attacked described 777 in section 12.2.1 of [RFC3489]). The attacker will send STUN Binding 778 Responses indicating his IP address, which will be indistinguishable, 779 to the STUN client, from the behavior of the legitimate STUN server. 781 To defend against this attack, the STUN client and STUN server obtain 782 a short-term password as described in section Section 5.6. 784 9. IANA Considerations 786 This section registers one new STUN attribute per the procedures in 787 [I-D.ietf-behave-rfc3489bis]: 789 0x0026 XOR-INTERNAL-ADDRESS 791 10. References 793 10.1. Normative References 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, March 1997. 798 [I-D.ietf-behave-rfc3489bis] 799 Rosenberg, J., "Simple Traversal Underneath Network 800 Address Translators (NAT) (STUN)", 801 draft-ietf-behave-rfc3489bis-05 (work in progress), 802 October 2006. 804 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 805 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 806 RFC 4787, January 2007. 808 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 809 "STUN - Simple Traversal of User Datagram Protocol (UDP) 810 Through Network Address Translators (NATs)", RFC 3489, 811 March 2003. 813 10.2. Informational References 815 [UPnP] UPnP Forum, "Universal Plug and Play", 2000, 816 . 818 [Bonjour] Apple Computer, "Bonjour", 2005, 819 . 821 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 822 A. Rayhan, "Middlebox communication architecture and 823 framework", RFC 3303, August 2002. 825 [I-D.ietf-mmusic-ice] 826 Rosenberg, J., "Interactive Connectivity Establishment 827 (ICE): A Methodology for Network Address Translator (NAT) 828 Traversal for Offer/Answer Protocols", 829 draft-ietf-mmusic-ice-13 (work in progress), January 2007. 831 [I-D.ietf-sip-outbound] 832 Jennings, C. and R. Mahy, "Managing Client Initiated 833 Connections in the Session Initiation Protocol (SIP)", 834 draft-ietf-sip-outbound-07 (work in progress), 835 January 2007. 837 Authors' Addresses 839 Dan Wing 840 Cisco Systems 841 170 West Tasman Drive 842 San Jose, CA 95134 843 USA 845 Email: dwing@cisco.com 846 Jonathan Rosenberg 847 Cisco Systems 848 600 Lanidex Plaza 849 Parsippany, NJ 07054 850 USA 852 Email: jdrosen@cisco.com 854 Full Copyright Statement 856 Copyright (C) The IETF Trust (2007). 858 This document is subject to the rights, licenses and restrictions 859 contained in BCP 78, and except as set forth therein, the authors 860 retain all their rights. 862 This document and the information contained herein are provided on an 863 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 864 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 865 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 866 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 867 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 868 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 870 Intellectual Property 872 The IETF takes no position regarding the validity or scope of any 873 Intellectual Property Rights or other rights that might be claimed to 874 pertain to the implementation or use of the technology described in 875 this document or the extent to which any license under such rights 876 might or might not be available; nor does it represent that it has 877 made any independent effort to identify any such rights. Information 878 on the procedures with respect to rights in RFC documents can be 879 found in BCP 78 and BCP 79. 881 Copies of IPR disclosures made to the IETF Secretariat and any 882 assurances of licenses to be made available, or the result of an 883 attempt made to obtain a general license or permission for the use of 884 such proprietary rights by implementers or users of this 885 specification can be obtained from the IETF on-line IPR repository at 886 http://www.ietf.org/ipr. 888 The IETF invites any interested party to bring to its attention any 889 copyrights, patents or patent applications, or other proprietary 890 rights that may cover technology that may be required to implement 891 this standard. Please address the information to the IETF at 892 ietf-ipr@ietf.org. 894 Acknowledgment 896 Funding for the RFC Editor function is provided by the IETF 897 Administrative Support Activity (IASA).