idnits 2.17.00 (12 Aug 2021) /tmp/idnits41116/draft-wing-behave-nat-control-stun-usage-04.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 1237. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1248. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1255. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1261. 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 (October 10, 2007) is 5337 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-cheshire-nat-pmp has been published as RFC 6886 == 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 (~~), 9 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: April 12, 2008 H. Tschofenig 6 Nokia Siemens Networks 7 October 10, 2007 9 Discovering, Querying, and Controlling Firewalls and NATs using STUN 10 draft-wing-behave-nat-control-stun-usage-04 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 April 12, 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 keepalive messages, 49 which contribute negatively to server and network load. 51 This document describes two mechanisms to discover NATs and firewalls 52 and a mechanism to query and control them. With these mechanisms, 53 binding discovery and keepalive traffic can be reduced to involve 54 only the necessary NATs or firewalls. This eliminates the keepalive 55 traffic to servers, and vastly reduces keepalive traffic across the 56 network. At the same time, backwards compatibility with NATs and 57 firewalls that do not support this specification is retained, which 58 allows for incremental deployment of 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 2. Motivation and Benefits . . . . . . . . . . . . . . . . . . . 5 73 2.1. Comparison with other NAT Traversal Techniques . . . . . . 7 74 2.1.1. Simple Security Model . . . . . . . . . . . . . . . . 7 75 2.1.2. Incremental Deployment . . . . . . . . . . . . . . . . 7 76 2.2. Optimize STUN keepalive messages . . . . . . . . . . . . . 7 77 2.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 8 79 2.3.2. Learning STUN Servers without Configuration . . . . . 8 80 2.3.3. Media Keepalive . . . . . . . . . . . . . . . . . . . 8 81 2.4. Reduce IPsec keepalive messages . . . . . . . . . . . . . 9 82 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 83 4. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 10 84 4.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 10 85 4.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 12 86 4.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 13 87 5. Query and Control . . . . . . . . . . . . . . . . . . . . . . 14 88 5.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 14 89 5.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 15 90 6. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 15 91 6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 15 92 6.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 16 93 6.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 16 94 6.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 17 95 6.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 18 96 7. Limitations of STUN Control . . . . . . . . . . . . . . . . . 18 97 7.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 19 98 7.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 19 99 7.3. Address Dependent Filtering . . . . . . . . . . . . . . . 20 100 7.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 20 101 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 102 8.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 103 8.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 21 104 8.3. Comparison to Other NAT Control Techniques . . . . . . . . 21 105 8.4. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 21 106 9. Open Issues and Discussion Points . . . . . . . . . . . . . . 22 107 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 108 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 109 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 110 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 111 12.2. Informational References . . . . . . . . . . . . . . . . . 25 112 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 26 113 A.1. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 26 114 A.2. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 26 115 Appendix B. Implementation Details . . . . . . . . . . . . . . . 27 116 B.1. Internal NAT Operation . . . . . . . . . . . . . . . . . . 27 117 B.2. Linux specifics . . . . . . . . . . . . . . . . . . . . . 27 118 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 28 119 Intellectual Property and Copyright Statements . . . . . . . . . . 30 121 1. Introduction 123 Two common usages of Simple Traversal Underneath NAT (STUN) 124 ([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and 125 NAT Keepalive. The Binding Discovery usage allows a STUN client to 126 learn its public IP address (from the perspective of the STUN server 127 it contacted) and the NAT keepalive usage allows a STUN client to 128 keep an active NAT binding alive. Unlike some other techniques 129 (e.g., UPnP [UPnP], MIDCOM [RFC3303], NAT-PMP 130 [I-D.cheshire-nat-pmp]), NSIS-NSLP [I-D.ietf-nsis-nslp-natfw], STUN 131 does not interact directly with the NAT. Thus, STUN cannot request 132 additional services from the NAT, such as longer lifetimes which 133 would reduce keepalive messages. Furthermore, allocating new NAT 134 bindings (e.g., each phone call) requires communication with a STUN 135 server located somewhere on the Internet. 137 This document describes three mechanisms for the STUN client to 138 discover NATs and firewalls that are on path with its STUN server. 139 After discovering the NATs and firewalls, the STUN client can query 140 and control those devices using STUN. The STUN client needs to only 141 ask those STUN servers (embedded in the NATs and firewalls) for 142 public IP addresses and UDP ports, thereby offloading that traffic 143 from the STUN server on the Internet. Additionally, the STUN client 144 can ask the NAT's embedded STUN server to extend the NAT binding for 145 the flow, and the STUN client can learn the IP address of the next- 146 outermost NAT. By repeating this procedure with the next-outermost 147 NAT, all of the NATs along that path can have their bindings 148 extended. By learning all of the STUN servers on the path between 149 the public Internet and itself, an endpoint can optimize the path of 150 peer-to-peer communications. 152 2. Motivation and Benefits 154 There are a number of problems with existing NAT traversal 155 techniques, such as STUN, UPnP, MIDCOM, NAT-PMP, and NSIS-NSLP: 157 nested NATs: 158 Today, many ISPs provide their subscribers with modems that have 159 embedded NATs or within the ISP's network. These subscribers then 160 install NATs behind those devices to provide additional features, 161 such as wireless access. In these situations, UPnP and NAT-PMP no 162 longer function, as those protocols can only control the first NAT 163 closest to the host. STUN continues to function, but is unable to 164 optimize network traffic behind those nested NATs (e.g., traffic 165 that stays within the same house or within the same apartment 166 building). 168 One technique to avoid nested NATs is to disable one of the NATs, 169 as recommended by [Vista-cert]. However, this merely sidesteps 170 the problem of nested NATs, as some NATs are installed for a 171 reason (e.g., reduce IP address consumption or provide a modicum 172 of security). Disabling the NAT is also ineffective if the ISP is 173 NATting subscribers within the ISP's network, as ISP NATs do not 174 typically support UPnP. 176 The technique described in this document allows optimization of 177 the traffic behind those NATs so that the traffic can traverse the 178 fewest NATs possible. 180 chattiness: 181 To keep NAT bindings from timing out and to perform its binding 182 discovery, a STUN packets are sent to a server on the Internet. 183 This consumes bandwidth across the user's access network, which in 184 some cases is bandwidth constrained (e.g., wireless, satellite) 185 and also creates a load on the server. STUN's chattiness is often 186 cited as a reason to use other NAT traversal techniques such as 187 UPnP or NAT-PMP. 189 The technique described in this document provides a significant 190 reduction in STUN's chattiness, to the point that the only time a 191 STUN client needs to communicate with the STUN server on the 192 public Internet is when the STUN client is initialized. 194 lack of incremental deployment: 195 Many other NAT traversal techniques require the endpoint and its 196 NAT to both support the same NAT traversal technique or else NAT 197 traversal is not possible at all. Examples include NSIS-NSLP, 198 NAT-PMP, UPnP, and MIDCOM. 200 The technique described in this document allows incremental 201 deployment of local endpoints and NATs that support STUN Control. 202 If the local endpoint, or its NATs, does not support the STUN 203 Control functionality, then STUN (see 204 [I-D.ietf-behave-rfc3489bis]), [I-D.ietf-sip-outbound], and ICE 205 [I-D.ietf-mmusic-ice] procedures are used to traverse the NATs 206 without the optimizations described in this document. 208 The protocol described in this document retains the positive features 209 of STUN -- incremental deployment and support of nested NATs -- 210 without introducing drawbacks inherent in other NAT traversal 211 techniques. The protocol optimizes the operation of STUN clients 212 when those STUN clients are behind a NAT that supports the protocol 213 described in this document. STUN clients that are behind a NAT that 214 doesn't support the protocol described in this document continue to 215 function as they do today, without those optimizations. 217 2.1. Comparison with other NAT Traversal Techniques 219 STUN Control offers the following benefits over other NAT traversal 220 and NAT control techniques such as NSIS-NSLP, MIDCOM, NAT-PMP, and 221 UPnP. 223 2.1.1. Simple Security Model 225 Unlike other middlebox control techniques which have relatively 226 complex security models because a separate control channel is used, 227 STUN Control's is simple. It is simple because only flows 228 originating from the same source IP and UDP port can be controlled 229 (i.e., have its NAT timeout queried or extended). Other flows cannot 230 be created, queried, or controlled via STUN Control. 232 2.1.2. Incremental Deployment 234 STUN Control can be incrementally deployed. If the outer-most NAT 235 does not support it, the STUN client behaves as normal -- it merely 236 isn't able to optimize its keepalive (see also Section Section 7.4). 237 If the outer-most NAT does support STUN Control, the STUN client can 238 gain some significant optimizations as described in the following 239 sections. 241 Likewise, there is no change required to applications if NATs are 242 deployed which support STUN Control: such applications will be 243 unaware of the additional functionality in the NAT, and will not be 244 subject to any worse security risks due to the additional 245 functionality in the NAT. 247 2.2. Optimize STUN keepalive messages 249 The primary value of the protocol and technique described in this 250 document is the reduction of STUN's chattiness. 252 In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 253 STUN server, and a UDP keepalive message is sent every 30 seconds to 254 that server. STUN Control as described in this document enables two 255 optimizations of SIP-Outbound's keepalive mechanism: 257 1. all of the on-path NATs can explicitly indicate their timeouts, 258 reducing the frequency of keepalive messages. 260 2. STUN keepalive messages need only be sent to the outer-most NAT, 261 rather than across the access link to the SIP proxy, which vastly 262 reduces the traffic to the SIP proxy, and; 264 2.3. Optimize ICE 266 The STUN Control usage provides several opportunities to optimize ICE 267 [I-D.ietf-mmusic-ice], as described in this section. 269 2.3.1. Candidate Gathering 271 During its candidate gathering phase, an ICE endpoint normally 272 contacts a STUN server on the Internet. If an ICE endpoint discovers 273 that its outer-most NAT runs a STUN server, the ICE endpoint can use 274 the outer-most NAT's STUN server rather than using the STUN server on 275 the Internet. This saves access bandwidth and reduces the reliance 276 on the STUN server on the Internet -- the STUN server on the Internet 277 need only be contacted once -- when the ICE endpoint first 278 initializes. 280 2.3.2. Learning STUN Servers without Configuration 282 ICE allows endpoints to have multiple STUN servers, but it is 283 difficult to configure all of the STUN servers in the ICE endpoint -- 284 it requires some awareness of network topology. By using the 'walk 285 backward' technique described in this document, all the on-path NATs 286 and their embedded STUN servers can be learned without additional 287 configuration. By knowing the STUN servers at each address domain, 288 ICE endpoints can optimize the network path between two peers. 290 For example, if endpoint-1 is only configured with the IP address of 291 the STUN server on the left, endpoint-1 can learn about NAT-B and 292 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 293 can optimize their media path so they make the optimal path from 294 endpoint-1 to NAT-A to endpoint-2: 296 +-------+ +-------+ +-------------+ 297 endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | 298 +-------+ | +-------+ +-------------+ 299 | 300 endpoint-2 302 2.3.3. Media Keepalive 304 While very minor, STUN Control makes it possible to optimize media 305 keepalives. This is useful if a video or audio stream is placed on 306 'hold' or 'mute', but is expected to be resumed in the future. ICE 307 uses STUN Indications as its primary media stream keepalive 308 mechanism. This document enables two optimizations of ICE's 309 keepalive technique: 311 1. STUN keepalive messages need only be sent to the outer-most NAT, 312 rather than across the access link to the remote peer, and; 314 2. all of the on-path NATs can explicitly indicate their timeouts, 315 which allows reducing the keepalive frequency. 317 2.4. Reduce IPsec keepalive messages 319 STUN Control is also able to reduce keepalive traffic for non-STUN 320 protocols. In Section 4 of [RFC3948], it is suggested that IPsec 321 keepalive packets be sent every 20 seconds if an on-path NAT is 322 detected. If a host and its NAT were to implement STUN Control, the 323 host can query and control the NAT's binding lifetime, and thus 324 reduce the NAT keepalive traffic. This reduction in keepalive 325 traffic would slightly reduce the load on its IPsec concentrator. 327 3. Overview of Operation 329 This document describes three functions, which are all implemented 330 using the STUN protocol: 332 Discovery of Middleboxes (NATs and Firewalls): 333 This document describes two techniques for finding NATs or 334 firewalls (see Section 4). These two approaches are: 336 Outside-In: 337 Uses STUN to find the outer-most NAT and works itself towards 338 the host. 340 Tagging: 341 Send a STUN Request packet to your STUN server, and asks for 342 compliant firewalls along the path to indicate their presence 343 by adding an IP address to the STUN Response packet. 345 Querying Discovered Middleboxes: 346 After discovering a NAT or a firewall, it is useful to determine 347 characteristics of the NAT binding or the firewall pinhole. Two 348 of the most useful things to learn is the duration the NAT binding 349 or firewall pinhole will remain open if there is no traffic, and 350 the filtering applied to that binding or pinhole. This is 351 described in Section 5. 353 Controlling Discovered Middleboxes: 354 A NAT or a firewall might default to a more restrictive behavior 355 than desired by an application (e.g., aggressive timeout, 356 filtering). Requesting the NAT or firewall to change its default 357 behavior is useful for traffic optimization (e.g., reduce 358 keepalive traffic) and network optimization (e.g., adjust filters 359 to eliminate the need for a media relay device 360 [I-D.ietf-behave-turn]). A discussion of this functionality can 361 be found in Section 5. 363 4. Discovery of Middleboxes (NATs and Firewalls) 365 This document investigates two techniques to discover a NAT and a 366 firewall: outside-in and by tagging. 368 Ideally, a single technique could be selected as an outcome of the 369 standardization process. However, it is possible to combine these 370 two techniques. 372 4.1. Outside-In 374 When a STUN client sends a STUN Request to a STUN server, it receives 375 a STUN Response that indicates the IP address and UDP port seen by 376 the STUN server. If the IP address and UDP port differs from the IP 377 address and UDP port of the socket used to send the request, the STUN 378 client knows there is at least one NAT between itself and the STUN 379 server. The STUN client also learns the 'public' IP address (and 380 port) allocated by the outermost NAT. For example, in the following 381 diagram, the STUN client learns the public IP address of its NAT is 382 192.0.2.1: 384 +--------+ +---------------+ 385 | STUN | | 192.0.2.1 +--------+ 386 | Client +-------------+ +------+ STUN | 387 | 10.1.1.2/4193 10.1.1.1 | | Server | 388 +--------+ | | +--------+ 389 | NAT with | 390 | Embedded STUN | 391 | Server | 392 +---------------+ 394 Figure 2: One NAT with embedded STUN server 396 After learning the public IP address of its outer-most NAT, the STUN 397 client attempts to communicate with the STUN server embedded in that 398 outer-most NAT. The STUN client does this by sending a STUN Binding 399 Request to the NAT's public IP address. The NAT will return a STUN 400 Binding Response message including the XOR-INTERNAL-ADDRESS 401 attribute, which will indicate the IP address and UDP port seen on 402 the *internal* side of the NAT for that translation (see Figure 14). 404 In the example above, the IP address and UDP port indicated in XOR- 405 INTERNAL-ADDRESS are the same as that used by the STUN client 406 (10.1.1.2/4193), which indicates there are no other NATs between the 407 STUN client and that outer-most NAT. 409 STUN Client NAT STUN Server 410 | | | 411 1. |-----Binding Request (UDP)--------------->| 412 2. |<----Binding Response (UDP)---------------| 413 | | | 414 3. |--Binding Request (UDP)------->| | 415 4. |<-Binding Response (UDP)-------| | 416 | | | 418 Figure 3: Communication Flow 420 In the call flow above, steps 1 and 2 correspond to the STUN behavior 421 described in [I-D.ietf-behave-rfc3489bis]: 423 1: The STUN client sends a UDP Binding Request to its STUN server 424 that is located on the Internet. 426 2: The STUN server on the Internet responds with a UDP Binding 427 Response. 429 The next steps are the additional steps performed by a STUN client 430 that has implemented the STUN Control functionality: 432 3: The STUN client sends a UDP Binding Request to the IP address 433 learned from the STUN server on the Internet. This will be 434 received by the STUN server embedded in the outer-most NAT. 436 4: The STUN server (embedded in the NAT) responds with a UDP Binding 437 Response. 439 The response obtained in message (4) contains the XOR-MAPPED-ADDRESS 440 attribute, which will have the same value as when the STUN server on 441 the Internet responded (in step 2). Thereafter, so long as the 442 BOOTNONCE value doesn't change, the STUN client can perform steps (3) 443 and (4) for any new UDP communication, without needing to repeat 444 steps (1) and (2). This meets the desire to reduce chattiness. The 445 STUN client also only needs to send keepalives towards the outer-most 446 NAT's IP address, as well (reduces chatter for SIP outbound 447 [I-D.ietf-sip-outbound]). 449 The response obtained in message (4) will also contain the XOR- 450 INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3) 451 and (4) in order to query or control those on-path NATs between 452 itself and its STUN server on the Internet. This is described in 453 detail in Section 4.1.1. This functionality meets the need to 454 optimize traffic between nested NATs, without requiring configuration 455 of intermediate STUN servers. 457 The STUN client can request each NAT to increase the binding lifetime 458 for that source IP address and source UDP port, as described in 459 Section 6.1. The STUN client receives positive confirmation that the 460 binding lifetime has been extended, allowing the STUN client to 461 significantly reduces its NAT keepalive traffic. Additionally, as 462 long as the NAT complies with [RFC4787] (which is indicated by its 463 support of this document), the STUN client's keepalive traffic need 464 only be sent to the outer-most NAT's IP address. This functionality 465 meets the need to reduce STUN's chattiness. 467 4.1.1. Nested NATs 469 Nested NATs are controlled individually. The nested NATs are 470 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 471 INTERNAL-ADDRESS attribute. 473 The example in Figure 4 shows how a STUN client iterates over the 474 NATs to communicate with all of the NATs in the path. 476 The following figure shows two nested NATs: 478 +------+ +--------+ +--------+ 479 | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ 480 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 481 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 482 +------+ +--------+ +--------+ 484 Figure 4: Two nested NATs with embedded STUN servers 486 First, the STUN client would learn the outer-most NAT's IP address by 487 performing the steps shown in Figure 3. In the case below, however, 488 the IP address and UDP port indicated by the XOR-INTERNAL-ADDRESS 489 will not be the STUN client's own IP address and UDP port -- rather, 490 it is the IP address and UDP port on the *outer* side of the NAT-B -- 491 10.1.1.2. 493 Because of this, the STUN client repeats the procedure and sends 494 another STUN Binding Request to that newly-learned address (the 495 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 496 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 497 match the STUN client's IP address and UDP port. The STUN client 498 knows there are no other NATs between itself and NAT-B, and finishes. 500 The message flow with two nested NATs is shown below: 502 STUN Client NAT-B NAT-A STUN Server 503 | | | | 504 1. |-----Binding Request (UDP)--------------->| 505 2. |<----Binding Response (UDP)---------------| 506 | | | | 507 3. |--Binding Request (UDP)------->| | } 508 4. |<-Binding Response (UDP)-------| | } NAT Control 509 | | | | } STUN Usage 510 5. |--Binding Req (UDP)-->| | | } 511 6. |<-Binding Resp (UDP)--| | | } 512 | | | | 514 Figure 5: Message Flow for Outside-In with Two NATs 516 Once a shared secret has been obtained with each of the on-path NATs, 517 the STUN client no longer needs the TLS/TCP connection -- all 518 subsequent bindings for individual UDP streams (that is, for each 519 subsequent call) are obtained by just sending a Binding Request to 520 each of the NATs. By sending a Binding Request to both NAT-A and 521 NAT-B, the STUN client has the opportunity to optimize the packet 522 flow if their UDP peer is also behind the same NAT. 524 4.2. Tagging 526 To discover an on-path firewall, the PLEASE-TAG attribute is used 527 with a STUN Binding Request (a STUN packet sent to UDP/3478) message. 528 A firewall would inspect bypassing Binding Request messages and 529 determine whether there is a PLEASE-TAG attribute. When the firewall 530 sees the associated Binding Response, the firewall appends a TAG 531 attribute as the last attribute of the Binding Response. This TAG 532 attribute contains the firewall's management IP address and UDP port. 533 Each on-path firewall would be able to insert its own TAG attribute. 534 In this way, the STUN Response would contain a pointer to each of the 535 on-path firewalls between the client and that STUN server. 537 Motivation for developing the Tagging mechanism: The Outside-In 538 discovery technique (Section 4.1) uses the public IP address of 539 the NAT to find the outer-most NAT that supports STUN Control. 540 Firewalls do not translate packets and hence a different technique 541 is needed to identify firewalls. 543 Note that tagging is similar to how NSIS-NSLP 545 [I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS 546 [I-D.shore-nls-tl] function. 548 This figure shows how tagging functions. 550 STUN Client firewall STUN Server 551 | | | 552 1. |--Binding Request->|------------------>| 553 2. | |<-Binding Response-| 554 3. | [inserts tag] | 555 4. |<-Binding Response-| | 556 5. [firewall discovered] | | 558 Figure 6: Tagging Message Flow 560 1. A Binding Request, containing the PLEASE-TAG attribute, is sent 561 to the IP address of the STUN server that is located somewhere on 562 the Internet. This is seen by the firewall, and the firewall 563 remembers the STUN transaction id, and permits the STUN Binding 564 Request packet. 566 2. When the firewall observes a STUN Binding Response packet it 567 checks its cache for the previously stored STUN transaction id. 568 If a previous STUN transaction id was found then the firewall 569 inserts the TAG attribute, which contains the firewall's 570 management address. 572 3. The firewall sends the (modified) STUN Binding Response towards 573 the STUN client. 575 4. The STUN client has now discovered the firewall, and can query it 576 or control it. 578 5. Query and Control 580 This section describes how to use STUN to query and control a NAT 581 that was discovered using the technique described in Section 4. 583 5.1. Client Procedures 585 After discovering on-path NATs and firewalls with the procedure 586 described in Section 4, the STUN client begins querying and 587 controlling those devices. 589 To modify an existing NAT mapping's attributes, or to request a new 590 NAT mapping for a new UDP port, the STUN client can now send a STUN 591 Binding Request to the IP address of address of the respective NAT or 592 firewall (using the STUN UDP port, 3478). 594 Client produces for handling the BOOTNONCE attribute can be found in 595 Section 6.5. 597 5.2. Server Procedures 599 When receiving a STUN Binding Request the STUN controlled NAT will 600 respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS 601 attribute (which points at the NAT's public IP address and port -- 602 just as if the STUN Binding Request had been sent to a STUN server on 603 the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which 604 points to the source IP address and UDP port the packet STUN Binding 605 Request packet had prior to being NATted). See Figure 14 which 606 depicts how this might be implemented in a NAT. 608 For example, looking at Figure 2, the XOR-INTERNAL-ADDRESS is the 609 IP address and UDP port prior to the NAPT operation. If there is 610 only one NAT, as shown in Figure 2, XOR-INTERNAL-ADDRESS would 611 contain the STUN client's own IP address and UDP port. If there 612 are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP 613 address of the next NAT (that is, the next NAT closer to the STUN 614 client). 616 When receiving a STUN Binding Request the STUN controlled firewall 617 will respond with a STUN Binding Response containing an XOR-MAPPED- 618 ADDRESS attribute (which points at the public IP address and port) 619 and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP 620 address of the interface and UDP port where the packet was received, 621 i.e., the internal interface). 623 Server procedures for handling the BOOTNONCE and REFRESH-INTERVAL 624 attributes can be found in Section 6.5 and Section 6.1. 626 STUN Binding Requests, which arrived from its public interface(s), 627 MAY be handled as if the server is not listening on that port (e.g., 628 return an ICMP error). This specification does not need them. 630 6. New Attributes 632 6.1. REFRESH-INTERVAL Attribute 634 In a STUN request, the REFRESH-INTERVAL attribute indicates the 635 number of milliseconds that the client wants the NAT binding (or 636 firewall pinhole) to be opened. This applies to all bindings that 637 exist in that NAT from that same source IP address and same source 638 UDP port (see also Appendix B.2). In a STUN response, the REFRESH- 639 INTERVAL attribute indicates the number of milliseconds the STUN 640 server (embedded in the NAT or firewall) will keep the bindings open. 642 REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and 643 represents an interval measured in milliseconds (thus the maximum 644 value is approximately 50 days). This attribute can be present in 645 Binding Requests and in Binding Responses. 647 6.2. XOR-INTERNAL-ADDRESS Attribute 649 This attribute MUST be present in a Binding Response and is necessary 650 to allow a STUN client to perform the outside-in discovery technique, 651 in order to discover all of the STUN Control-aware NATs along the 652 path. 654 The format of the XOR-INTERNAL-ADDRESS attribute is: 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 |x x x x x x x x| Family | X-Port | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 | X-Address (32 bits or 128 bits) | 662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 664 Figure 7: XOR-INTERNAL-ADDRESS Attribute 666 The meaning of Family, X-Port, and X-Address are exactly as in 667 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 668 address family (IPv4 or IPv6). 670 6.3. PLEASE-TAG Attribute 672 If a STUN client wants to discover on-path firewalls, it MUST include 673 this attribute in its Binding Response when performing the Binding 674 Discovery usage. 676 STUN servers are not expected to understand this attribute; if they 677 return this attribute as an unknown attribute, it does not affect the 678 operation described in this document. 680 The format of the PLEASE-TAG attribute is: 682 0 1 2 3 683 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 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 |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| 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 Figure 8: PLEASE-TAG Attribute 690 The 3-bit Mechanism field indicates the control mechanism desired. 691 Currently, the only defined mechanism is STUN Control, and is 692 indicated with all zeros. The intent of this field is to allow 693 additional control mechanisms (e.g., UPnP, NAT-PMP, MIDCOM). 695 6.4. TAG Attribute 697 The TAG attribute contains the XOR'd management transport address of 698 the middlebox. Typically, a firewall as well as a NAT may find this 699 technique useful as well. 701 If the associated STUN Request contained the PLEASE-TAG attribute, a 702 middlebox MUST append this attribute as the last attribute of the 703 STUN Response (with that same transaction-id). After appending this 704 attribute, the STUN length field MUST be also be adjusted. 706 The format of the TAG attribute is: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 |Mech.|M|x x x x| Family | X-Port | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | X-Address (32 bits or 128 bit) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Figure 9: TAG Attribute 718 Mech: The 3-bit Mechanism field indicates the control mechanism 719 supported on the described port. Currently, the only defined 720 mechanism is STUN Control, and is indicated with 0x0. The intent of 721 this field is to allow additional control mechanisms (e.g., UPnP, 722 NAT-PMP, MIDCOM). 724 The one-bit M field indicates if this firewall permits Mobility 725 Header packets to flow through it ([RFC3775]). 727 The meaning of Family, X-Port, and X-Address are exactly as in 728 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 729 address family (IPv4 or IPv6). 731 6.5. BOOTNONCE Attribute 733 The BOOTNONCE attribute protects against the attack described in 734 Section 8.4. 736 Client procedures: The STUN client expects each NAT to return the 737 same BOOTNONCE value each time that NAT is contacted. If a NAT 738 returns a different value, the STUN client MUST NOT use any 739 information returned in the Binding Response and MUST re-run the STUN 740 Control procedures from the beginning (i.e., obtain its public IP 741 address from the STUN server on the Internet). This would only occur 742 if an attack is in progress or if the NAT rebooted. If the NAT 743 rebooted, it is good practice to re-run the STUN Control procedures 744 anyway, as the network topology could be different as well. 746 Server procedures: This attribute's value is a hash of the STUN 747 client's IP address and a value that is randomly-generated each time 748 the NAT is initialized. The STUN client's IP address is included in 749 this hash to thwart an attacker attaching to the NAT's internal 750 network and learning the BOOTNONCE value. 752 The format of the BOOTNONCE attribute is: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Boot Nonce value (32 bits) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Figure 10: BOOTNONCE Attribute 762 7. Limitations of STUN Control 763 7.1. Overlapping IP Addresses with Nested NATs 765 If nested NATs have overlapping IP address space, there will be 766 undetected NATs on the path. When this occurs, the STUN client will 767 be unable to detect the presence of NAT-A if NAT-A assigns the same 768 UDP port. For example, in the following figure, NAT-A and NAT-B are 769 both using 10.1.1.x as their 'private' network. 771 +------+ +--------+ +--------+ 772 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1 773 | STUN +-------+ NAT-A +-----+ NAT-B +------ 774 |client| 10.1.1.1 | 10.1.1.1 | 775 +------+ +--------+ +--------+ 777 Figure 11: Overlapping Addresses with Nested NATs 779 When this situation occurs, the STUN client can only learn the outer- 780 most address. This is not a problem -- the STUN client is still able 781 to communicate with the outer-most NAT and is still able to avoid 782 consuming access network bandwidth and avoid communicating with the 783 public STUN server. All that is lost is the ability to optimize 784 paths within the private network that has overlapped addresses. 786 Of course when such an overlap occurs the end host (STUN client) 787 cannot successfully establish bi-directional communication with hosts 788 in the overlapped network, anyway. 790 7.2. Address Dependent NAT on Path 792 In order to utilize the mechanisms described in this document, a STUN 793 Request is sent from the same source IP address and source port as 794 the original STUN Binding Discovery message, but is sent to a 795 different destination IP address -- it is sent to the IP address of 796 an on-path NAT. If there is an on-path NAT, between the STUN client 797 and the STUN server, with 'address dependent' or 'address and port- 798 dependent' mapping behavior (as described in Section 4.1 of 799 [RFC4787]), that NAT will prevent a STUN client from taking advantage 800 of the technique described in this document. When this occurs, the 801 ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and 802 the NAT's embedded STUN server will differ. 804 An example of such a topology is shown in the following figure: 806 +------+ +--------+ +--------+ 807 | STUN | | 10.1.1.2 | 192.0.2.1 808 |client+-----+ NAT-A +---+ NAT-B +------ 809 | | 10.1.1.1 | 10.1.1.1 | 810 +------+ +--------+ +--------+ 812 In this figure, NAT-A is a NAT that has address dependent mapping. 813 Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1 814 on UDP/3478, NAT-A will choose a new public UDP port for that 815 communication. NAT-B will function normally, returning a different 816 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 817 that a symmetric NAT exists between the STUN client and the STUN 818 server it just queried (NAT-B, in this example). 820 Figure 12: Address Dependant NAT on Path 822 7.3. Address Dependent Filtering 824 If there is an NAT along the path that has address dependent 825 filtering (as described in section 5 of [RFC4787]), and the STUN 826 client sends a STUN packet directly to any of the on-path NATs public 827 addresses, the address-dependent filtering NAT will filter packets 828 from the remote peer. Thus, after communicating with all of the on- 829 path NATs the STUN client MUST send a UDP packet to the remote peer, 830 if the remote peer is known. 832 7.4. Interacting with Legacy NATs 834 There will be cases where the STUN client attempts to communicate 835 with an on-path NAT, which does not support STUN Control. There are 836 two cases: 838 o the NAT does not run a STUN server on its public interface (this 839 will be the most common) 841 o the NAT does run a STUN server on its public interface, but does 842 not return the XOR-INTERNAL-ADDRESS attribute defined in this 843 document 845 In both cases the optimizations described in this section will not be 846 available to the STUN client. This is no worse than the condition 847 today. This allows incremental upgrades of applications and NATs 848 that implement the technique described in this document. 850 8. Security Considerations 852 This security considerations section will be expanded in a subsequent 853 version of this document. So far, the authors have identified the 854 following considerations: 856 8.1. Authorization 858 Only hosts that are 'inside' a NAT, which a NAT is already providing 859 services for, can query or adjust the timeout of a NAT mapping. 861 A discussion of additional authorization mechanisms that might be 862 needed for firewall traversal can be found at 863 [I-D.wing-session-auth]. 865 8.2. Resource Exhaustion 867 A malicious STUN client could ask for absurdly long NAT bindings 868 (days) for many UDP sessions, which would exhaust the resources in 869 the NAT. The same attack is possible (without considering this 870 document and without considering STUN or other UNSAF [RFC3424] NAT 871 traversal techniques) -- a malicious TCP (or UDP) client can open 872 many TCP (or UDP) connections, and keep them open, causing resource 873 exhaustion in the NAT. 875 8.3. Comparison to Other NAT Control Techniques 877 Like UPnP, NAT-PMP, and host-initiated MIDCOM, the STUN usage 878 described in this document allows a host to learn its public IP 879 address and UDP port mapping, and to request a specific lifetime for 880 mappings from that same source IP address and same source UDP port. 882 However, unlike other NAT traversal technologies, STUN Control 883 described in this document only allows each UDP port on the host to 884 create and adjust the mapping timeout of its own NAT mappings. 885 Specifically, an application on a host can only adjust the duration 886 of a NAT bindings for itself, and not for another application on that 887 same host, and not for other hosts. This provides security 888 advantages over other NAT control mechanisms where malicious software 889 on a host can surreptitiously create NAT mappings to another 890 application or to another host. 892 8.4. BOOTNONCE Attribute 894 Using the mechanisms described in this document, a STUN client learns 895 the public IP addresses of its NAT which supports the mechanisms 896 described in this document. However, without the STUN client's 897 knowledge, that NAT may acquire a new IP address (e.g., due to DHCP 898 lease expiration or network renumbering). When this occurs, the STUN 899 client will send a STUN Binding Request to the NAT's previous public 900 IP address. If an attacker were to run a rogue STUN server on that 901 address, the attacker will have effectively compromised the STUN 902 server, as described in Section 12.2.1 of [RFC3489]. The attacker, 903 upon receiving STUN Binding Requests, will reply with STUN Binding 904 Responses indicating an IP address the attacker controls. The 905 attacker will thus have access to the subsequent flow established by 906 the STUN client (e.g., RTP traffic). This attack is possible because 907 the STUN client is unable to distinguish the attacker's replies from 908 replies from the legitimate NAT. 910 To defend against this attack, the STUN server embedded in the NAT 911 returns a BOOTNONCE value. The STUN client validates that it 912 receives the same BOOTNONCE value in each STUN Binding Response from 913 that NAT. If the STUN client receives a new BOOTNONCE value, the 914 STUN client discards information about NATs it has learned through 915 the procedures in this document, and restarts the procedure described 916 in this document. 918 A weakness of this approach is that an attacker can learn the 919 BOOTNONCE value if the attacker is able to connect to the NAT's 920 internal network prior to initiating the attack. This is plausible 921 if the internal network has no security (e.g., public WiFi network). 922 For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed 923 with the STUN client's IP address. Doing so means that a successful 924 attacker must acquire both the same IP address as the victim from 925 behind the NAT (to learn the BOOTNONCE), and must also acquire the 926 NAT's previous public IP address, or needs to be on-path between the 927 victim and its NAT (in which case the attacker has no incentive to 928 redirect traffic elsewhere to observe such traffic; however, the 929 attacker might be interested in redirecting traffic towards another 930 endpoint on the Internet. To thwart that attack, the STUN client 931 MUST only honor STUN responses that have an X-MAPPED-ADDRESS that 932 matches the public IP address of the NAT-embedded STUN server. 934 9. Open Issues and Discussion Points 936 o Discussion Point: After discovering NATs and firewalls, 937 controlling those devices might also be done with a middlebox 938 control protocol (e.g., by using standard or slightly modified 939 versions of SIMCO, UPnP, MIDCOM, or NAT-PMP). This is open for 940 discussion as this document is scoped within the IETF. 942 o Discussion Point: Tagging would also be useful for the 943 Connectivity Check usage (which is used by ICE), especially 944 considering that a different firewall may be traversed for media 945 than for the initial Binding Discovery usage. In such a 946 situation, the new on-path firewall's policy might not allow a 947 binding request to leave the network or allow a binding response 948 to return. In this case, the firewall would need to indicate its 949 presence to the STUN client in another way. An ICMP error message 950 may be appropriate, and an ICMP extension [RFC4884] could indicate 951 the firewall is controllable. 953 o Open issue: We could resolve the problem of address dependant 954 NATs along the path by introducing a new STUN attribute which 955 indicates the UDP port the STUN client wants to control. However, 956 this changes the security properties of STUN Control, so this 957 seems undesirable. 959 Open issue: When the STUN client detects an address dependant 960 NAT, should we recommend it abandon the STUN Control usage, and 961 revert to operation as if it doesn't support the STUN Control 962 usage? 964 o Open issue: How many filter entries are in address dependent 965 filtering NATs? If only one, this does become a real limitation 966 if NATs are nested; if they're not nested, the outer-most NAT can 967 avoid overwriting its own address in its address dependent filter. 969 o Discussion: One way to thwart a resource consumption attack is to 970 challenge the STUN client. This would allow the STUN server to 971 delay the establishment of resources before a return-routability 972 test is performed. This functionality is currently not provided 973 by this specification. The NONCE attribute 974 [I-D.ietf-behave-rfc3489bis] could be useful to provide this 975 function. However, the mere sending of a UDP packet across a NAT 976 creates a binding (for ~2 minutes), and there isn't a return- 977 routability check for that. 979 o The inside-out discovery technique was removed with version -03 of 980 this document. The procedure worked as follows: The STUN client 981 sends a STUN request to UDP/3478 of the IP address of its default 982 router. If there is a STUN server listening there, it will 983 respond, and will indicate its default route via the new DEFAULT- 984 ROUTE attribute. With that information, the STUN client can 985 discover the next-outermost NAT by repeating the procedure. More 986 feedback is needed to determine whether the functionality is 987 needed. 989 10. IANA Considerations 991 This section registers new STUN attributes per the procedures in 992 [I-D.ietf-behave-rfc3489bis]: 994 Mandatory range: 995 0x0029 XOR-INTERNAL-ADDRESS 996 0x00.. BOOTNONCE 998 Optional range: 999 0x8024 REFRESH-INTERVAL 1000 0x80.. PLEASE-TAG 1001 0x80.. TAG 1003 11. Acknowledgements 1005 Thanks to Remi Denis-Courmont, Christian Dickmann, Bajko Gabor, 1006 Markus Isomaki, Cullen Jennings, and Philip Matthews for their 1007 suggestions which have improved this document. 1009 Thanks to Christian Dickmann and Yan Sun for their initial 1010 implementations of STUN Control. 1012 12. References 1014 12.1. Normative References 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, March 1997. 1019 [I-D.ietf-behave-rfc3489bis] 1020 Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 1021 Wing, "Session Traversal Utilities for (NAT) (STUN)", 1022 draft-ietf-behave-rfc3489bis-10 (work in progress), 1023 September 2007. 1025 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1026 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1027 RFC 4787, January 2007. 1029 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1030 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1031 Through Network Address Translators (NATs)", RFC 3489, 1032 March 2003. 1034 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1035 in IPv6", RFC 3775, June 2004. 1037 12.2. Informational References 1039 [I-D.ietf-behave-turn] 1040 Rosenberg, J., "Traversal Using Relays around NAT (TURN): 1041 Relay Extensions to Session Traversal Utilities for NAT 1042 (STUN)", draft-ietf-behave-turn-04 (work in progress), 1043 July 2007. 1045 [UPnP] UPnP Forum, "Universal Plug and Play", 2000, 1046 . 1048 [Vista-cert] 1049 Microsoft, "Windows Logo Program Device Requirements", 1050 2006, . 1054 [I-D.cheshire-nat-pmp] 1055 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1056 draft-cheshire-nat-pmp-02 (work in progress), 1057 October 2006. 1059 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1060 A. Rayhan, "Middlebox communication architecture and 1061 framework", RFC 3303, August 2002. 1063 [I-D.ietf-mmusic-ice] 1064 Rosenberg, J., "Interactive Connectivity Establishment 1065 (ICE): A Protocol for Network Address Translator (NAT) 1066 Traversal for Offer/Answer Protocols", 1067 draft-ietf-mmusic-ice-18 (work in progress), 1068 September 2007. 1070 [I-D.ietf-sip-outbound] 1071 Jennings, C. and R. Mahy, "Managing Client Initiated 1072 Connections in the Session Initiation Protocol (SIP)", 1073 draft-ietf-sip-outbound-10 (work in progress), July 2007. 1075 [I-D.ietf-nsis-nslp-natfw] 1076 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1077 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in 1078 progress), July 2007. 1080 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1081 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1082 April 2007. 1084 [I-D.shore-tist-prot] 1085 Shore, M., "The TIST (Topology-Insensitive Service 1086 Traversal) Protocol", draft-shore-tist-prot-00 (work in 1087 progress), May 2002. 1089 [I-D.shore-nls-tl] 1090 Shore, M., "Network-Layer Signaling: Transport Layer", 1091 draft-shore-nls-tl-05 (work in progress), June 2007. 1093 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1094 Self-Address Fixing (UNSAF) Across Network Address 1095 Translation", RFC 3424, November 2002. 1097 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1098 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1099 RFC 3948, January 2005. 1101 [I-D.wing-session-auth] 1102 Wing, D., "Media Session Authorization", 1103 draft-wing-session-auth-00 (work in progress), 1104 February 2006. 1106 Appendix A. Changes 1108 A.1. Changes in -04 1110 o Clarified that all existing bindings, for that source IP address 1111 and UDP port, are controlled with STUN Control. 1113 o Introduction now concentrates on the primary purpose of STUN 1114 Control, namely reducing keepalive traffic for SIP-Outbound. 1116 A.2. Changes in -03 1118 o Removed TLS from normal STUN operation (as few use it, and ICE 1119 makes it unnecessary anyway) 1121 o BOOTNONCE attribute replaces STUN Control's previous use of TLS. 1123 o Added "MIP-capable" bit to TAG attribute 1125 o Removed "inside-out" discovery technique. 1127 Appendix B. Implementation Details 1129 B.1. Internal NAT Operation 1131 Internally, the NAT can be diagrammed to function like this, where 1132 the NAT operation occurs before the STUN server: 1134 | 1135 | outside interface 1136 | 1137 +---------+---------------+ 1138 | | | 1139 | | +--------+ | 1140 | |----+ STUN | | 1141 | | | Server | | 1142 | | +---^----+ | 1143 | | | | 1144 | | API | 1145 | | | | 1146 | +-------+--------V----+ | 1147 | | NAT Function | | 1148 | +-------+-------------+ | 1149 | | | 1150 +---------+---------------+ 1151 | 1152 | inside interface 1153 | 1154 | 1155 The host on the 'inside' interface of the NAT sends packets to the 1156 NAT's public interface, where the STUN server is listening. This 1157 STUN server returns the same public IP address (XOR-MAPPED-ADDRESS) 1158 as a STUN server that resides on a separate server on the 'outside' 1159 interface. In order to query and to control the NAT binding 1160 lifetimes, the STUN server uses an API with the NAT function. 1162 Figure 14: Block Diagram of Internal NAT Operation 1164 B.2. Linux specifics 1166 The Linux NAT implementation maintains a separate connection table 1167 entry for every binding. When STUN Control is used to control the 1168 binding lifetime (e.g., extend the lifetime), the binding lifetime 1169 for each of those connection table entries is modified to the new 1170 value. 1172 For example, with the following message flow: 1173 STUN Client NAT STUN Server 1174 | | | 1175 1. |-----Binding Request (UDP)--------------->| 1176 2. |<----Binding Response (UDP)---------------| 1177 | | | 1178 3. |--Binding Request (UDP)------->| | 1179 4. |<-Binding Response (UDP)-------| | 1180 | | | 1182 the following two connection table entries are created: 1183 udp 17 24 src=10.7.2.4 dst=10.7.1.2 sport=1024 1184 dport=3478 packets=1 bytes=64 src=10.7.1.2 1185 dst=10.7.1.3 sport=3478 dport=1024 packets=1 1186 bytes=84 mark=0 use=1 1187 udp 17 25 src=10.7.2.4 dst=10.7.1.3 sport=1024 1188 dport=3478 packets=2 bytes=64 src=10.7.1.3 1189 dst=10.7.2.4 sport=3478 dport=1024 packets=2 1190 bytes=208 mark=0 use=1 1191 the first src/dst/sport/dport combination is the internal and the 1192 second one is the external version. Both are equal in the second 1193 connection, as the NAT function wasn't active for the "internal" 1194 message. 1196 s 1198 Authors' Addresses 1200 Dan Wing 1201 Cisco Systems, Inc. 1202 170 West Tasman Drive 1203 San Jose, CA 95134 1204 USA 1206 Email: dwing@cisco.com 1208 Jonathan Rosenberg 1209 Cisco Systems, Inc. 1210 Edison, NJ 07054 1211 USA 1213 Email: jdrosen@cisco.com 1214 Hannes Tschofenig 1215 Nokia Siemens Networks 1216 Otto-Hahn-Ring 6 1217 Munich, Bavaria 81739 1218 Germany 1220 Email: Hannes.Tschofenig@nsn.com 1221 URI: http://www.tschofenig.com 1223 Full Copyright Statement 1225 Copyright (C) The IETF Trust (2007). 1227 This document is subject to the rights, licenses and restrictions 1228 contained in BCP 78, and except as set forth therein, the authors 1229 retain all their rights. 1231 This document and the information contained herein are provided on an 1232 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1233 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1234 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1235 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1236 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1237 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1239 Intellectual Property 1241 The IETF takes no position regarding the validity or scope of any 1242 Intellectual Property Rights or other rights that might be claimed to 1243 pertain to the implementation or use of the technology described in 1244 this document or the extent to which any license under such rights 1245 might or might not be available; nor does it represent that it has 1246 made any independent effort to identify any such rights. Information 1247 on the procedures with respect to rights in RFC documents can be 1248 found in BCP 78 and BCP 79. 1250 Copies of IPR disclosures made to the IETF Secretariat and any 1251 assurances of licenses to be made available, or the result of an 1252 attempt made to obtain a general license or permission for the use of 1253 such proprietary rights by implementers or users of this 1254 specification can be obtained from the IETF on-line IPR repository at 1255 http://www.ietf.org/ipr. 1257 The IETF invites any interested party to bring to its attention any 1258 copyrights, patents or patent applications, or other proprietary 1259 rights that may cover technology that may be required to implement 1260 this standard. Please address the information to the IETF at 1261 ietf-ipr@ietf.org. 1263 Acknowledgment 1265 Funding for the RFC Editor function is provided by the IETF 1266 Administrative Support Activity (IASA).