idnits 2.17.00 (12 Aug 2021) /tmp/idnits38213/draft-wing-behave-nat-control-stun-usage-03.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 1126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1150. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == 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 (July 8, 2007) is 5431 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) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 == Outdated reference: draft-ietf-sip-outbound has been published as RFC 5626 == Outdated reference: draft-ietf-nsis-nslp-natfw has been published as RFC 5973 == Outdated reference: A later version (-06) exists of draft-shore-nls-tl-05 Summary: 4 errors (**), 0 flaws (~~), 8 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: January 9, 2008 H. Tschofenig 6 Nokia Siemens Networks 7 July 8, 2007 9 Discovering, Querying, and Controlling Firewalls and NATs using STUN 10 draft-wing-behave-nat-control-stun-usage-03 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 January 9, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 Simple Traversal Underneath NAT (STUN) is a mechanism for traversing 44 NATs. STUN requests are transmitted through a NAT to external STUN 45 servers. While this works very well, its two primary drawbacks are 46 the inability to modify the properties of a NAT binding and the need 47 to query a public STUN server for every new NAT binding (e.g., every 48 phone call). These drawbacks require frequent messages which present 49 a load on servers (like SIP servers and STUN servers) and are bad for 50 low speed access networks, such as cellular access. 52 This document describes two mechanisms to discover NATs and firewalls 53 and a mechanism to query and control them. With these mechanisms, 54 binding discovery and keepalive traffic can be reduced to involve 55 only the necessary NATs or firewalls. At the same time, backwards 56 compatibility with NATs and firewalls that do not support this 57 document is retained, which allows for incremental deployment of 58 these mechanisms. 60 This document is discussed on the SAFE mailing list, 61 . 63 Terminology 65 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 66 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 67 document are to be interpreted as described in [RFC2119]. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 74 4. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 6 75 4.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 6 76 4.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. Query and Control . . . . . . . . . . . . . . . . . . . . . . 11 79 5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 11 80 5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 11 81 6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 12 83 6.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 12 84 6.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 13 85 6.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 13 86 6.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 14 87 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 15 89 7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 15 90 7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 15 91 7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 16 92 7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 16 93 7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 16 94 7.4.3. Learning STUN Servers without Configuration . . . . . 16 95 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 17 96 8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 17 97 8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 17 98 8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 18 99 8.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 18 100 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 19 102 9.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 19 103 9.3. Comparison to Other NAT Control Techniques . . . . . . . . 19 104 9.4. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 20 105 10. Open Issues and Discussion Points . . . . . . . . . . . . . . 20 106 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 107 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 108 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 109 13.1. Normative References . . . . . . . . . . . . . . . . . . . 22 110 13.2. Informational References . . . . . . . . . . . . . . . . . 23 111 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 24 112 A.1. Changes between -03 and 02 . . . . . . . . . . . . . . . . 24 113 Appendix B. Block Diagram of Internal NAT Operation . . . . . . . 24 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 115 Intellectual Property and Copyright Statements . . . . . . . . . . 27 117 1. Introduction 119 Two common usages of Simple Traversal Underneath NAT (STUN) 120 ([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and 121 NAT Keepalive. The Binding Discovery usage allows a STUN client to 122 learn its public IP address (from the perspective of the STUN server 123 it contacted) and the NAT keepalive usage allows a STUN client to 124 keep an active NAT binding alive. Unlike some other techniques 125 (e.g., UPnP [UPnP], MIDCOM [RFC3303], Bonjour [Bonjour]), STUN does 126 not interact directly with the NAT. Thus, STUN cannot request 127 additional services from the NAT, such as longer lifetimes which 128 would reduce keepalive messages. Furthermore, allocating new NAT 129 bindings (e.g., each phone call) requires communication with a STUN 130 server located somewhere on the Internet. 132 This document describes three mechanisms for the STUN client to 133 discover NATs and firewalls that are on path with its STUN server. 134 After discovering the NATs and firewalls, the STUN client can query 135 and control those devices using STUN. The STUN client needs to only 136 ask those STUN servers (embedded in the NATs and firewalls) for 137 public IP addresses and UDP ports, thereby offloading that traffic 138 from the STUN server on the Internet. Additionally, the STUN client 139 can ask the NAT's embedded STUN server to extend the NAT binding for 140 the flow, and the STUN client can learn the IP address of the next- 141 outermost NAT. By repeating this procedure with the next-outermost 142 NAT, all of the NATs along that path can have their bindings 143 extended. By learning all of the STUN servers on the path between 144 the public Internet and itself, an endpoint can optimize the path of 145 peer-to-peer communications. 147 2. Motivation 149 There are a number of problems with existing NAT traversal 150 techniques, such as STUN [RFC3489], [UPnP], and [Bonjour]): 152 nested NATs: 153 Today, many ISPs provide their subscribers with modems that have 154 embedded NATs, often with only one physical Ethernet port. These 155 subscribers then install NATs behind those devices to provide 156 additional features, such as wireless access. Another example is 157 a NAT in the basement of an apartment building or a campus 158 dormitory, which combined with a NAT within the home or dormitory 159 room also result in nested NATs. In both of these situations, 160 UPnP and Bonjour no longer function at all, as those protocols can 161 only control the first NAT closest to the host. STUN continues to 162 function, but is unable to optimize network traffic behind those 163 nested NATs (e.g., traffic that stays within the same house or 164 within the same apartment building). 166 One technique to avoid nested NATs is to disable one of the NATs, 167 if it obtains an RFC 1918 address on its WAN interface. This 168 merely sidesteps the problem. This technique is also ineffective 169 if the ISP is NATting its subscribers and the ISP restricts each 170 subscriber to one IP address. 172 The technique described in this document allows optimization of 173 the traffic behind those NATs so that the traffic can traverse the 174 fewest NATs possible. 176 chattiness: 177 To perform its binding discovery, a STUN client communicates to a 178 server on the Internet. This consumes bandwidth across the user's 179 access network, which in some cases is bandwidth constrained 180 (e.g., wireless, satellite). STUN's chattiness is often cited as 181 a reason to use other NAT traversal techniques such as UPnP or 182 Bonjour. 184 The technique described in this document provides a significant 185 reduction in STUN's chattiness, to the point that the only time a 186 STUN client needs to communicate with the STUN server on the 187 public Internet is when the STUN client is initialized. 189 incremental deployment: 190 Many other NAT traversal techniques require the endpoint and its 191 NAT to both support the new feature or else NAT traversal is not 192 possible at all. 194 The technique described in this document allows incremental 195 deployment of local endpoints and NATs that support STUN Control. 196 If the local endpoint, or its NATs, does not support the STUN 197 Control functionality, then STUN (see 198 [I-D.ietf-behave-rfc3489bis]) and ICE [I-D.ietf-mmusic-ice] 199 procedures are used to traverse the NATs without the optimizations 200 described in this document. 202 3. Overview of Operation 204 This document describes three functions, which are all implemented 205 using the STUN protocol: 207 Discovery of Middleboxes (NATs and Firewalls): 208 This document describes two techniques for finding NATs or 209 firewalls (see Section 4). These two approaches are: 211 Outside-In: 212 Uses STUN to find the outer-most NAT and works itself towards 213 the host. 215 Tagging: 216 Send a STUN Request packet to your STUN server, and asks for 217 compliant firewalls along the path to indicate their presence 218 by adding an IP address to the STUN Response packet. 220 Querying Discovered Middleboxes: 221 After discovering a NAT or a firewall, it is useful to determine 222 characteristics of the NAT binding or the firewall pinhole. Two 223 of the most useful things to learn is the duration the NAT binding 224 or firewall pinhole will remain open if there is no traffic, and 225 the filtering applied to that binding or pinhole. This is 226 described in Section 5. 228 Controlling Discovered Middleboxes: 229 A NAT or a firewall might default to a more restrictive behavior 230 than desired by an application (e.g., aggressive timeout, 231 filtering). Requesting the NAT or firewall to change its default 232 behavior is useful for traffic optimization (e.g., reduce 233 keepalive traffic) and network optimization (e.g., adjust filters 234 to eliminate the need for a media relay device 235 [I-D.ietf-behave-turn]). A discussion of this functionality can 236 be found in Section 5. 238 4. Discovery of Middleboxes (NATs and Firewalls) 240 This document investigates two techniques to discover a NAT and a 241 firewall: outside-in and by tagging. 243 Ideally, a single technique could be selected as an outcome of the 244 standardization process. However, it is possible to combine these 245 two techniques. 247 4.1. Outside-In 249 When a STUN client sends a STUN Request to a STUN server, it receives 250 a STUN Response that indicates the IP address and UDP port seen by 251 the STUN server. If the IP address and UDP port differs from the IP 252 address and UDP port of the socket used to send the request, the STUN 253 client knows there is at least one NAT between itself and the STUN 254 server, and knows the 'public' IP address (and port) allocated by the 255 outermost NAT. For example, in the following diagram, the STUN 256 client learns the public IP address of its NAT is 192.0.2.1: 258 +--------+ +---------------+ 259 | STUN | | 192.0.2.1 +--------+ 260 | Client +-------------+ +------+ STUN | 261 | 10.1.1.2/4193 10.1.1.1 | | Server | 262 +--------+ | | +--------+ 263 | NAT with | 264 | Embedded STUN | 265 | Server | 266 +---------------+ 268 Figure 1: One NAT with embedded STUN server 270 After learning the public IP address of its outer-most NAT, the STUN 271 client attempts to communicate with the STUN server embedded in that 272 outer-most NAT. The STUN client does this by sending a STUN Binding 273 Request to the NAT's public IP address. The NAT will return a STUN 274 Binding Response message including the XOR-INTERNAL-ADDRESS 275 attribute, which will indicate the IP address and UDP port seen on 276 the *internal* side of the NAT for that translation (see Figure 14 in 277 Appendix B). In the example above, the IP address and UDP port 278 indicated in XOR-INTERNAL-ADDRESS are the same as that used by the 279 STUN client (10.1.1.2/4193), which indicates there are no other NATs 280 between the STUN client and that outer-most NAT. 282 STUN Client NAT STUN Server 283 | | | 284 1. |-----Binding Request (UDP)--------------->| 285 2. |<----Binding Response (UDP)---------------| 286 | | | 287 3. |--Binding Request (UDP)------->| | 288 4. |<-Binding Response (UDP)-------| | 289 | | | 291 Figure 2: Communication Flow 293 In the call flow above, steps 1 and 2 correspond to the STUN behavior 294 described in [I-D.ietf-behave-rfc3489bis]: 296 1: The STUN client sends a UDP Binding Request to its STUN server 297 that is located on the Internet. 299 2: The STUN server on the Internet responds with a UDP Binding 300 Response. 302 The next steps are the additional steps performed by a STUN client 303 that has implemented the STUN Control functionality: 305 3: The STUN client sends a UDP Binding Request to the IP address 306 learned from the STUN server on the Internet. This will be 307 received by the STUN server embedded in the outer-most NAT. 309 4: The STUN server (embedded in the NAT) responds with a UDP Binding 310 Response. 312 The response obtained in message (4) contains the XOR-MAPPED-ADDRESS 313 attribute, which will have the same value as when the STUN server on 314 the Internet responded (in step 2). The STUN client can perform 315 steps (3) and (4) for any new UDP communication, without needing to 316 repeat steps (1) and (2). This meets the desire to reduce 317 chattiness. The STUN client also only needs to send keepalives 318 towards the outer-most NAT's IP address, as well (reduces chatter for 319 SIP outbound [I-D.ietf-sip-outbound]). 321 The response obtained in message (4) will also contain the XOR- 322 INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3) 323 and (4) in order to query or control those on-path NATs between 324 itself and its STUN server on the Internet. This is described in 325 detail in Section 4.1.1. This functionality meets the need to 326 optimize traffic between nested NATs, without requiring configuration 327 of intermediate STUN servers. 329 The STUN client can request each NAT to increase the binding 330 lifetime, as described in Section 6.1. The STUN client receives 331 positive confirmation that the binding lifetime has been extended, 332 allowing the STUN client to significantly reduces its NAT keepalive 333 traffic. Additionally, as long as the NAT complies with [RFC4787] 334 (which is indicated by its support of this document), the STUN 335 client's keepalive traffic need only be sent to the outer-most NAT's 336 IP address. This functionality meets the need to reduce STUN's 337 chattiness. 339 4.1.1. Nested NATs 341 Nested NATs are controlled individually. The nested NATs are 342 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 343 INTERNAL-ADDRESS attribute. 345 The example in Figure 3 shows how a STUN client iterates over the 346 NATs to communicate with all of the NATs in the path. 348 The following figure shows two nested NATs: 350 +------+ +--------+ +--------+ 351 | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ 352 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 353 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 354 +------+ +--------+ +--------+ 356 Figure 3: Two nested NATs with embedded STUN servers 358 First, the STUN client would learn the outer-most NAT's IP address by 359 performing the steps shown in Figure 2. In the case below, however, 360 the IP address and UDP port indicated by the XOR-INTERNAL-ADDRESS 361 will not be the STUN client's own IP address and UDP port -- rather, 362 it is the IP address and UDP port on the *outer* side of the NAT-B -- 363 10.1.1.2. 365 Because of this, the STUN client repeats the procedure and sends 366 another STUN Binding Request to that newly-learned address (the 367 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 368 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 369 match the STUN client's IP address and UDP port. The STUN client 370 knows there are no other NATs between itself and NAT-B, and finishes. 372 The message flow with two nested NATs is shown below: 374 STUN Client NAT-B NAT-A STUN Server 375 | | | | 376 1. |-----Binding Request (UDP)--------------->| 377 2. |<----Binding Response (UDP)---------------| 378 | | | | 379 3. |--Binding Request (UDP)------->| | } 380 4. |<-Binding Response (UDP)-------| | } NAT Control 381 | | | | } STUN Usage 382 5. |--Binding Req (UDP)-->| | | } 383 6. |<-Binding Resp (UDP)--| | | } 384 | | | | 386 Figure 4: Message Flow for Outside-In with Two NATs 388 Once a shared secret has been obtained with each of the on-path NATs, 389 the STUN client no longer needs the TLS/TCP connection -- all 390 subsequent bindings for individual UDP streams (that is, for each 391 subsequent call) are obtained by just sending a Binding Request to 392 each of the NATs. By sending a Binding Request to both NAT-A and 393 NAT-B, the STUN client has the opportunity to optimize the packet 394 flow if their UDP peer is also behind the same NAT. 396 4.2. Tagging 398 To discover an on-path firewall, the PLEASE-TAG attribute is used 399 with a STUN Binding Request (a STUN packet sent to UDP/3478) message. 400 A firewall would inspect bypassing Binding Request messages and 401 determine whether there is a PLEASE-TAG attribute. When the firewall 402 sees the associated Binding Response, the firewall appends a TAG 403 attribute as the last attribute of the Binding Response. This TAG 404 attribute contains the firewall's management IP address and UDP port. 405 Each on-path firewall would be able to insert its own TAG attribute. 406 In this way, the STUN Response would contain a pointer to each of the 407 on-path firewalls between the client and that STUN server. 409 Motivation for developing the Tagging mechanism: The Outside-In 410 discovery technique (Section 4.1) uses the public IP address of 411 the NAT to find the outer-most NAT that supports STUN Control. 412 Firewalls do not translate packets and hence a different technique 413 is needed to identify firewalls. 415 Note that tagging is similar to how NSIS 416 [I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS 417 [I-D.shore-nls-tl] function. 419 This figure shows how tagging functions. 421 STUN Client firewall STUN Server 422 | | | 423 1. |--Binding Request->|------------------>| 424 2. | |<-Binding Response-| 425 3. | [inserts tag] | 426 4. |<-Binding Response-| | 427 5. [firewall discovered] | | 429 Figure 5: Tagging Message Flow 431 1. A Binding Request, containing the PLEASE-TAG attribute, is sent 432 to the IP address of the STUN server that is located somewhere on 433 the Internet. This is seen by the firewall, and the firewall 434 remembers the STUN transaction id, and permits the STUN Binding 435 Request packet. 437 2. When the firewall observes a STUN Binding Response packet it 438 checks its cache for the previously stored STUN transaction id. 440 If a previous STUN transaction id was found then the firewall 441 inserts the TAG attribute, which contains the firewall's 442 management address. 444 3. The firewall sends the (modified) STUN Binding Response towards 445 the STUN client. 447 4. The STUN client has now discovered the firewall, and can query it 448 or control it. 450 5. Query and Control 452 This section describes how to use STUN to query and control a NAT 453 that was discovered using the technique described in Section 4. 455 5.1. Client Procedures 457 After discovering on-path NATs and firewalls with the procedure 458 described in Section 4, the STUN client begins querying and 459 controlling those devices. 461 To modify an existing NAT mapping's attributes, or to request a new 462 NAT mapping for a new UDP port, the STUN client can now send a STUN 463 Binding Request to the IP address of address of the respective NAT or 464 firewall (at STUN UDP port (3478)). 466 Client produces for handling the BOOTNONCE attribute can be found in 467 Section 6.5. 469 5.2. Server Procedures 471 When receiving a STUN Binding Request the STUN controlled NAT will 472 respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS 473 attribute (which points at the NAT's public IP address and port -- 474 just as if the STUN Binding Request had been sent to a STUN server on 475 the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which 476 points to the source IP address and UDP port the packet STUN Binding 477 Request packet had prior to being NATted). 479 For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the 480 IP address and UDP port prior to the NAPT operation. If there is 481 only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would 482 contain the STUN client's own IP address and UDP port. If there 483 are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP 484 address of the next NAT (that is, the next NAT closer to the STUN 485 client). 487 When receiving a STUN Binding Request the STUN controlled firewall 488 will respond with a STUN Binding Response containing an XOR-MAPPED- 489 ADDRESS attribute (which points at the public IP address and port) 490 and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP 491 address of the interface and UDP port where the packet STUN Binding 492 Request packet was received, i.e., the internal interface. 494 Server produces for handling the BOOTNONCE attribute can be found in 495 Section 6.5. 497 STUN Binding Requests, which arrived from its public interface(s), 498 MAY be handled as if the server is not listening on that port (e.g., 499 return an ICMP error) -- this specification does not need them. 501 6. New Attributes 503 6.1. REFRESH-INTERVAL Attribute 505 In a STUN request per [I-D.ietf-behave-rfc3489bis], the REFRESH- 506 INTERVAL attribute indicates the number of milliseconds that the 507 client wants the NAT binding (or firewall pinhole) to be opened. 508 When the NAT Keepalive usage is being used, the server may become 509 overloaded with keepalive messages (Binding Requests or other 510 application-level keepalive messages). The REFRESH-INTERVAL provies 511 a mechanism for the client to learn and adjust the NAT's binding 512 lifetime and thus reduce the frequency of client-initiated keepalive 513 messages. 515 In a STUN response, the same attribute indicates how long the STUN 516 controlled NAT (or a STUN controlled firewall) is willing to allocate 517 the binding (or to create the pinhole). 519 REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and 520 represents an interval measured in milliseconds (thus the maximum 521 value is approximately 50 days). This attribute can be present in 522 Binding Requests and in Binding Responses. 524 6.2. XOR-INTERNAL-ADDRESS Attribute 526 This attribute MUST be present in a Binding Response and is necessary 527 to allow a STUN client to perform the outside-in discovery technique, 528 in order to discover all of the STUN Control-aware NATs along the 529 path. 531 The format of the XOR-INTERNAL-ADDRESS attribute is: 533 0 1 2 3 534 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 535 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 536 |x x x x x x x x| Family | X-Port | 537 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 538 | X-Address (32 bits or 128 bits) | 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 Figure 6: XOR-INTERNAL-ADDRESS Attribute 543 The meaning of Family, X-Port, and X-Address are exactly as in 544 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 545 address family (IPv4 or IPv6). 547 6.3. PLEASE-TAG Attribute 549 If a STUN client wants to discover on-path firewalls, it MUST include 550 this attribute in its Binding Response when performing the Binding 551 Discovery usage. 553 STUN servers are not expected to understand this attribute; if they 554 return this attribute as an unknown attribute, it does not affect the 555 operation described in this document. 557 The format of the PLEASE-TAG attribute is: 559 0 1 2 3 560 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 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 |Mech.|x x x x x x x x x x x x x x x x x x x x x x x x x x x x x| 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 565 Figure 7: PLEASE-TAG Attribute 567 The 3-bit Mechanism field indicates the control mechanism desired. 568 Currently, the only defined mechanism is STUN Control, and is 569 indicated with all zeros. The intent of this field is to allow 570 additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM). 572 6.4. TAG Attribute 574 The TAG attribute contains the XOR'd management transport address of 575 the middlebox. Typically, a firewall as well as a NAT may find this 576 technique useful as well. 578 If the associated STUN Request contained the PLEASE-TAG attribute, a 579 middlebox MUST append this attribute as the last attribute of the 580 STUN Response (with that same transaction-id). After appending this 581 attribute, the STUN length field MUST be also be adjusted. 583 The format of the TAG attribute is: 585 0 1 2 3 586 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 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 |Mech.|M|x x x x| Family | X-Port | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | X-Address (32 bits or 128 bit) | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 593 Figure 8: TAG Attribute 595 Mech: The 3-bit Mechanism field indicates the control mechanism 596 supported on the described port. Currently, the only defined 597 mechanism is STUN Control, and is indicated with 0x0. The intent of 598 this field is to allow additional control mechanisms (e.g., UPnP, 599 Bonjour, MIDCOM). 601 The one-bit M field indicates if this firewall permits Mobility 602 Header packets to flow through it ([RFC3775]). 604 The meaning of Family, X-Port, and X-Address are exactly as in 605 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 606 address family (IPv4 or IPv6). 608 6.5. BOOTNONCE Attribute 610 The BOOTNONCE attribute protects against the attack described in 611 Section 9.4. 613 Client procedures: The STUN client expects each NAT to return the 614 same BOOTNONCE value each time that NAT is contacted. If a NAT 615 returns a different value, the STUN client MUST NOT use any 616 information returned in the Binding Response and MUST re-run the NAT 617 Control procedures from the beginning (i.e., obtain its public IP 618 address from the STUN server on the Internet). This would only occur 619 if an attack is in progress or if the NAT rebooted. If the NAT 620 rebooted, it is good practice to re-run the NAT Control procedures 621 anyway, as the network topology could be different as well. 623 Server procedures: This attribute's value is a hash of the STUN 624 client's IP address and a value that is randomly-generated each time 625 the NAT is initialized. The STUN client's IP address is included in 626 this hash to thwart an attacker attaching to the NAT's internal 627 network and learning the BOOTNONCE value. 629 The format of the BOOTNONCE attribute is: 631 0 1 2 3 632 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 633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 | Boot Nonce value (32 bits) | 635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 Figure 9: BOOTNONCE Attribute 639 7. Benefits 641 7.1. Simple Security Model 643 Unlike other middlebox control techniques which have relatively 644 complex security models because a separate control channel is used, 645 STUN Control's is simple. It's simple because only the flow being 646 used can be controlled (e.g., have its NAT timeout queried or 647 extended). Other flows cannot be created, queried, or controlled via 648 STUN Control. 650 7.2. Incremental Deployment 652 NAT Control can be incrementally deployed. If the outer-most NAT 653 does not support it, the STUN client behaves as normal. In this 654 case, the tagging procedure described in Section 4.2, will still 655 allow to gain some optimizations. Where the outer-most STUN NAT does 656 support it, the STUN client can gain some significant optimizations 657 as described in the following sections. 659 Likewise, there is no change required to applications if NATs are 660 deployed which support NAT Control: such applications will be 661 unaware of the additional functionality in the NAT, and will not be 662 subject to any worse security risks due to the additional 663 functionality in the NAT. 665 7.3. Optimize SIP-Outbound 667 In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 668 STUN server. STUN Control as described in this document enables two 669 optimizations of SIP-Outbound's keepalive mechanism: 671 1. STUN keepalive messages need only be sent to the outer-most NAT, 672 rather than across the access link to the SIP proxy, which vastly 673 reduces the traffic to the SIP proxy, and; 675 2. all of the on-path NATs can explicitly indicate their timeouts, 676 reducing the frequency of keepalive messages. 678 7.4. Optimize ICE 680 The NAT Control usage provides several opportunities to optimize ICE 681 [I-D.ietf-mmusic-ice], as described in this section. 683 7.4.1. Candidate Gathering 685 During its candidate gathering phase, an ICE endpoint normally 686 contacts a STUN server on the Internet. If an ICE endpoint discovers 687 that its outer-most NAT runs a STUN server, the ICE endpoint can use 688 the outer-most NAT's STUN server rather than using the STUN server on 689 the Internet. This saves access bandwidth and reduces the reliance 690 on the STUN server on the Internet -- the STUN server on the Internet 691 need only be contacted once -- when the ICE endpoint first 692 initializes. 694 7.4.2. Keepalive 696 ICE uses STUN Indications as its primary media stream keepalive 697 mechanism. This document enables two optimizations of ICE's 698 keepalive technique: 700 1. STUN keepalive messages need only be sent to the outer-most NAT, 701 rather than across the access link to the remote peer, and; 703 2. all of the on-path NATs can explicitly indicate their timeouts, 704 which allows reducing the keepalive frequency. 706 7.4.3. Learning STUN Servers without Configuration 708 ICE allows endpoints to have multiple STUN servers, but it is 709 difficult to configure all of the STUN servers in the ICE endpoint -- 710 it requires some awareness of network topology. By using the 'walk 711 backward' technique described in this document, all the on-path NATs 712 and their embedded STUN servers can be learned without additional 713 configuration. By knowing the STUN servers at each address domain, 714 ICE endpoints can optimize the network path between two peers. 716 For example, if endpoint-1 is only configured with the IP address of 717 the STUN server on the left, endpoint-1 can learn about NAT-B and 718 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 719 can optimize their media path so they make the optimal path from 720 endpoint-1 to NAT-A to endpoint-2: 722 +-------+ +-------+ +-------------+ 723 endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | 724 +-------+ | +-------+ +-------------+ 725 | 726 endpoint-2 728 8. Limitations 730 8.1. Overlapping IP Addresses with Nested NATs 732 If nested NATs have overlapping IP address space, there will be 733 undetected NATs on the path. When this occurs, the STUN client will 734 be unable to detect the presence of NAT-A if NAT-A assigns the same 735 UDP port. For example, in the following figure, NAT-A and NAT-B are 736 both using 10.1.1.x as their 'private' network. 738 +------+ +--------+ +--------+ 739 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1 740 | STUN +-------+ NAT-A +-----+ NAT-B +------ 741 |client| 10.1.1.1 | 10.1.1.1 | 742 +------+ +--------+ +--------+ 744 Figure 11: Overlapping Addresses with Nested NATs 746 When this situation occurs, the STUN client can only learn the outer- 747 most address. This is not a problem -- the STUN client is still able 748 to communicate with the outer-most NAT and is still able to avoid 749 consuming access network bandwidth and avoid communicating with the 750 public STUN server. All that is lost is the ability to optimize 751 paths within the private network that has overlapped addresses. 753 Of course when such an overlap occurs the end host (STUN client) 754 cannot successfully establish bi-directional communication with hosts 755 in the overlapped network, anyway. 757 8.2. Address Dependent NAT on Path 759 In order to utilize the mechanisms described in this document, a STUN 760 Request is sent from the same source IP address and source port as 761 the original STUN Binding Discovery message, but is sent to a 762 different destination IP address -- it is sent to the IP address of 763 an on-path NAT. If there is an on-path NAT, between the STUN client 764 and the STUN server, with 'address dependent' or 'address and port- 765 dependent' mapping behavior (as described in Section 4.1 of 766 [RFC4787]), that NAT will prevent a STUN client from taking advantage 767 of the technique described in this document. When this occurs, the 768 ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and 769 the NAT's embedded STUN server will differ. 771 An example of such a topology is shown in the following figure: 773 +------+ +--------+ +--------+ 774 | STUN | | 10.1.1.2 | 192.0.2.1 775 |client+-----+ NAT-A +---+ NAT-B +------ 776 | | 10.1.1.1 | 10.1.1.1 | 777 +------+ +--------+ +--------+ 779 In this figure, NAT-A is a NAT that has address dependent mapping. 780 Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1 781 on UDP/3478, NAT-A will choose a new public UDP port for that 782 communication. NAT-B will function normally, returning a different 783 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 784 that a symmetric NAT exists between the STUN client and the STUN 785 server it just queried (NAT-B, in this example). 787 Figure 12: Address Dependant NAT on Path 789 8.3. Address Dependent Filtering 791 If there is an NAT along the path that has address dependent 792 filtering (as described in section 5 of [RFC4787]), and the STUN 793 client sends a STUN packet directly to any of the on-path NATs public 794 addresses, the address-dependent filtering NAT will filter packets 795 from the remote peer. Thus, after communicating with all of the on- 796 path NATs the STUN client MUST send a UDP packet to the remote peer, 797 if the remote peer is known. 799 8.4. Interacting with Legacy NATs 801 There will be cases where the STUN client attempts to communicate 802 with an on-path NAT, which does not support the outside-in usage. 803 There are two cases: 805 o the NAT does not run a STUN server on its public interface (this 806 will be the most common) 808 o the NAT does run a STUN server on its public interface, but does 809 not return the XOR-INTERNAL-ADDRESS attribute defined in this 810 document 812 In both cases the optimizations described in this section will not be 813 available to the STUN client. This is no worse than the condition 814 today. This allows incremental upgrades of applications and NATs 815 that implement the technique described in this document. 817 9. Security Considerations 819 This security considerations section will be expanded in a subsequent 820 version of this document. So far, the authors have identified the 821 following considerations: 823 9.1. Authorization 825 Only hosts that are 'inside' a NAT, which a NAT is already providing 826 services for, can query or adjust the timeout of a NAT mapping. 828 A discussion of additional authorization mechanisms that might be 829 needed for firewall traversal can be found at 830 [I-D.wing-session-auth]. 832 9.2. Resource Exhaustion 834 A malicious STUN client could ask for absurdly long NAT bindings 835 (days) for many UDP sessions, which would exhaust the resources in 836 the NAT. The same attack is possible (without considering this 837 document and without considering STUN or other UNSAF [RFC3424] NAT 838 traversal techniques) -- a malicious TCP (or UDP) client can open 839 many TCP (or UDP) connections, and keep them open, causing resource 840 exhaustion in the NAT. 842 9.3. Comparison to Other NAT Control Techniques 844 Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage 845 described in this document allows a host to learn its public IP 846 address and UDP port mapping, and to request a specific lifetime for 847 that mapping. 849 However, unlike those technologies, the NAT Control usage described 850 in this document only allows each UDP port on the host to create and 851 adjust the mapping timeout of its own NAT mappings. Specifically, an 852 application on a host can only adjust the duration of a NAT bindings 853 for itself, and not for another application on that same host, and 854 not for other hosts. This provides security advantages over other 855 NAT control mechanisms where malicious software on a host can 856 surreptitiously create NAT mappings to another application or to 857 another host. 859 9.4. Rogue STUN Server 861 Using the mechanisms described in this document, a STUN client learns 862 the public IP addresses of its NATs which support the mechanisms 863 described in this document. However, without the STUN client's 864 knowledge, those NATs may acquire a new IP address (e.g., DHCP lease 865 expiration, a moving network). When any of those NAT acquire a new 866 IP address without the STUN client's knowledge, the STUN client will 867 send a STUN Binding Request to the NAT's previous public IP address. 868 If an attacker were to run a rogue STUN server on that address, the 869 attacker will have effectively compromised the STUN server, as 870 described in Section 12.2.1 of [RFC3489]. The attacker, upon 871 receiving STUN Binding Requests, will reply with STUN Binding 872 Responses indicating an IP address the attacker controls. The 873 attacker will thus ensure access to whatever media stream is being 874 established by the STUN client (e.g., RTP traffic). When such an 875 attack occurs, the STUN client is unable to distinguish the 876 attacker's replies from legitimate replies from the STUN server 877 embedded in the STUN client's NAT. 879 To defend against this attack, the STUN server embedded in the NAT 880 returns a BOOTNONCE value. The STUN client validates that it 881 receives the same BOOTNONCE value in each STUN Binding Response from 882 that NAT. 884 A weakness of this approach is that an attacker can learn the 885 BOOTNONCE value if the attacker is able to connect to the NAT's 886 internal network prior to initiating the attack; this is plausible if 887 the internal network has no security (e.g., public WiFi network). 888 For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed 889 with the STUN client's IP address. Doing so means the attacker must 890 acquire the same IP address as the victim from behind the NAT (to 891 learn the BOOTNONCE), and must also acquire the NAT's previous public 892 IP address. 894 10. Open Issues and Discussion Points 896 o Discussion Point: After discovering NATs and firewalls, 897 controlling those devices might also be done with a middlebox 898 control protocol (e.g., by using standard or slightly modified 899 versions of SIMCO, UPnP, MIDCOM, or Bonjour). This is open for 900 discussion as this document is scoped within the IETF. 902 o Discussion Point: Tagging would also be useful for the 903 Connectivity Check usage (which is used by ICE), especially 904 considering that a different firewall may be traversed for media 905 than for the initial Binding Discovery usage. In such a 906 situation, the new on-path firewall's policy might not allow a 907 binding request to leave the network or allow a binding response 908 to return. In this case, the firewall would need to indicate its 909 presence to the STUN client in another way. An ICMP error message 910 may be appropriate, and an ICMP extension [RFC4884] could indicate 911 the firewall is controllable. 913 o Open issue: We could resolve the problem of address dependant 914 NATs along the path by introducing a new STUN attribute which 915 indicates the UDP port the STUN client wants to control. However, 916 this changes the security properties of STUN Control, so this 917 seems undesirable. 919 Open issue: When the STUN client detects an address dependant 920 NAT, should we recommend it abandon the STUN Control usage, and 921 revert to operation as if it doesn't support the STUN Control 922 usage? 924 o Open issue: How many filter entries are in address dependent 925 filtering NATs? If only one, this does become a real limitation 926 if NATs are nested; if they're not nested, the outer-most NAT can 927 avoid overwriting its own address in its address dependent filter. 929 o Discussion: One way to thwart a resource consumption attack is to 930 challenge the STUN client. This would allow the STUN server to 931 delay the establishment of resources before a return-routability 932 test is performed. This functionality is currently not provided 933 by this specification. The NONCE attribute 934 [I-D.ietf-behave-rfc3489bis] could be useful to provide this 935 function. However, the mere sending of a UDP packet across a NAT 936 creates a binding (for ~2 minutes), and there isn't a return- 937 routability check for that. 939 o The inside-out discovery technique was removed with version -03 of 940 this document. The procedure worked as follows: The STUN client 941 sends a STUN request to UDP/3478 of the IP address of its default 942 router. If there is a STUN server listening there, it will 943 respond, and will indicate its default route via the new DEFAULT- 944 ROUTE attribute. With that information, the STUN client can 945 discover the next-outermost NAT by repeating the procedure. More 946 feedback is needed to determine whether the functionality is 947 needed. 949 11. IANA Considerations 951 This section registers new STUN attributes per the procedures in 952 [I-D.ietf-behave-rfc3489bis]: 954 Mandatory range: 955 0x0029 XOR-INTERNAL-ADDRESS 956 0x00.. BOOTNONCE 958 Optional range: 959 0x8024 REFRESH-INTERVAL 960 0x80.. PLEASE-TAG 961 0x80.. TAG 963 12. Acknowledgements 965 Thanks to Remi Denis-Courmont, Bajko Gabor, Markus Isomaki, Cullen 966 Jennings, and Philip Matthews for their suggestions which have 967 improved this document. 969 13. References 971 13.1. Normative References 973 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 974 Requirement Levels", BCP 14, RFC 2119, March 1997. 976 [I-D.ietf-behave-rfc3489bis] 977 Rosenberg, J., "Session Traversal Utilities for (NAT) 978 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 979 progress), March 2007. 981 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 982 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 983 RFC 4787, January 2007. 985 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 986 "STUN - Simple Traversal of User Datagram Protocol (UDP) 987 Through Network Address Translators (NATs)", RFC 3489, 988 March 2003. 990 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 991 in IPv6", RFC 3775, June 2004. 993 13.2. Informational References 995 [I-D.ietf-behave-turn] 996 Rosenberg, J., "Obtaining Relay Addresses from Simple 997 Traversal Underneath NAT (STUN)", 998 draft-ietf-behave-turn-03 (work in progress), March 2007. 1000 [UPnP] UPnP Forum, "Universal Plug and Play", 2000, 1001 . 1003 [Bonjour] Apple Computer, "Bonjour", 2005, 1004 . 1006 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1007 A. Rayhan, "Middlebox communication architecture and 1008 framework", RFC 3303, August 2002. 1010 [I-D.ietf-mmusic-ice] 1011 Rosenberg, J., "Interactive Connectivity Establishment 1012 (ICE): A Protocol for Network Address Translator (NAT) 1013 Traversal for Offer/Answer Protocols", 1014 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 1016 [I-D.ietf-sip-outbound] 1017 Jennings, C. and R. Mahy, "Managing Client Initiated 1018 Connections in the Session Initiation Protocol (SIP)", 1019 draft-ietf-sip-outbound-09 (work in progress), June 2007. 1021 [I-D.ietf-nsis-nslp-natfw] 1022 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1023 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in 1024 progress), March 2007. 1026 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1027 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1028 April 2007. 1030 [I-D.shore-tist-prot] 1031 Shore, M., "The TIST (Topology-Insensitive Service 1032 Traversal) Protocol", draft-shore-tist-prot-00 (work in 1033 progress), May 2002. 1035 [I-D.shore-nls-tl] 1036 Shore, M., "Network-Layer Signaling: Transport Layer", 1037 draft-shore-nls-tl-05 (work in progress), June 2007. 1039 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1040 Self-Address Fixing (UNSAF) Across Network Address 1041 Translation", RFC 3424, November 2002. 1043 [I-D.wing-session-auth] 1044 Wing, D., "Media Session Authorization", 1045 draft-wing-session-auth-00 (work in progress), 1046 February 2006. 1048 Appendix A. Changes 1050 A.1. Changes between -03 and 02 1052 o Removed TLS from normal STUN operation (as few use it, and ICE 1053 makes it unnecessary anyway) 1055 o BOOTNONCE attribute replaces STUN Control's previous use of TLS. 1057 o Added "MIP-capable" bit to TAG attribute 1059 o Removed "inside-out" discovery technique. 1061 Appendix B. Block Diagram of Internal NAT Operation 1062 Internally, the NAT can be diagrammed to function like this, where 1063 the NAT operation occurs before the STUN server: 1065 | 1066 | outside interface 1067 | 1068 +---------+---------------+ 1069 | | | 1070 | | +--------+ | 1071 | |----+ STUN | | 1072 | | | Server | | 1073 | | +--------+ | 1074 | | | 1075 | +-------+-------------+ | 1076 | | NAT Function | | 1077 | +-------+-------------+ | 1078 | | | 1079 +---------+---------------+ 1080 | 1081 | inside interface 1082 | 1083 | 1085 Figure 14: Block Diagram of Internal NAT Operation 1087 Authors' Addresses 1089 Dan Wing 1090 Cisco Systems, Inc. 1091 170 West Tasman Drive 1092 San Jose, CA 95134 1093 USA 1095 Email: dwing@cisco.com 1097 Jonathan Rosenberg 1098 Cisco Systems, Inc. 1099 Edison, NJ 07054 1100 USA 1102 Email: jdrosen@cisco.com 1103 Hannes Tschofenig 1104 Nokia Siemens Networks 1105 Otto-Hahn-Ring 6 1106 Munich, Bavaria 81739 1107 Germany 1109 Email: Hannes.Tschofenig@nsn.com 1110 URI: http://www.tschofenig.com 1112 Full Copyright Statement 1114 Copyright (C) The IETF Trust (2007). 1116 This document is subject to the rights, licenses and restrictions 1117 contained in BCP 78, and except as set forth therein, the authors 1118 retain all their rights. 1120 This document and the information contained herein are provided on an 1121 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1122 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1123 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1124 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1125 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1126 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1128 Intellectual Property 1130 The IETF takes no position regarding the validity or scope of any 1131 Intellectual Property Rights or other rights that might be claimed to 1132 pertain to the implementation or use of the technology described in 1133 this document or the extent to which any license under such rights 1134 might or might not be available; nor does it represent that it has 1135 made any independent effort to identify any such rights. Information 1136 on the procedures with respect to rights in RFC documents can be 1137 found in BCP 78 and BCP 79. 1139 Copies of IPR disclosures made to the IETF Secretariat and any 1140 assurances of licenses to be made available, or the result of an 1141 attempt made to obtain a general license or permission for the use of 1142 such proprietary rights by implementers or users of this 1143 specification can be obtained from the IETF on-line IPR repository at 1144 http://www.ietf.org/ipr. 1146 The IETF invites any interested party to bring to its attention any 1147 copyrights, patents or patent applications, or other proprietary 1148 rights that may cover technology that may be required to implement 1149 this standard. Please address the information to the IETF at 1150 ietf-ipr@ietf.org. 1152 Acknowledgment 1154 Funding for the RFC Editor function is provided by the IETF 1155 Administrative Support Activity (IASA).