idnits 2.17.1 draft-wing-behave-nat-control-stun-usage-05.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 1304. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1328. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 7 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 16, 2007) is 6036 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: A later version (-18) exists of draft-ietf-behave-rfc3489bis-11 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-04 == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-02 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-18 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-10 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-15 == Outdated reference: A later version (-06) exists of draft-shore-nls-tl-05 -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 9 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 18, 2008 H. Tschofenig 6 Nokia Siemens Networks 7 October 16, 2007 9 Discovering, Querying, and Controlling Firewalls and NATs 10 draft-wing-behave-nat-control-stun-usage-05 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 18, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 A drawback with many NAT UDP hole punching techniques is the 44 keepalive traffic necessary to keep the UDP binding open. It it 45 necessary to send keepalives frequently because it is not possible to 46 determine or modify the NAT's binding lifetime. This keepalive 47 traffic causes server load and additional network traffic, which is 48 especially problematic with battery-operated wireless devices. 50 This document describes two mechanisms to discover NATs and firewalls 51 and a mechanism to query and control their binding lifetime. With 52 these mechanisms, UDP binding discovery and UDP keepalive traffic can 53 be reduced to involve only the necessary NATs or firewalls. This 54 eliminates the keepalive traffic to servers, and vastly reduces 55 keepalive traffic across the network. At the same time, backwards 56 compatibility with NATs and firewalls that do not support this 57 specification is retained, which allows for incremental deployment of 58 this mechanism. 60 This document is discussed on the SAFE mailing list, 61 . 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Notational Conventions . . . . . . . . . . . . . . . . . . . . 4 67 3. Motivation and Benefits . . . . . . . . . . . . . . . . . . . 4 68 3.1. Comparison with other NAT Traversal Techniques . . . . . . 6 69 3.1.1. Simple Security Model . . . . . . . . . . . . . . . . 6 70 3.1.2. Incremental Deployment . . . . . . . . . . . . . . . . 6 71 3.2. Reduce Keepalive Messages . . . . . . . . . . . . . . . . 7 72 3.2.1. SIP Outbound . . . . . . . . . . . . . . . . . . . . . 7 73 3.2.2. IKE/IPsec NAT Traversal . . . . . . . . . . . . . . . 7 74 3.2.3. Teredo . . . . . . . . . . . . . . . . . . . . . . . . 8 75 3.3. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.3.1. Candidate Gathering . . . . . . . . . . . . . . . . . 8 77 3.3.2. Learning STUN Servers without Configuration . . . . . 8 78 3.3.3. Reduce Media Keepalive Messages . . . . . . . . . . . 9 79 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 9 80 5. Discovery of Middleboxes (NATs and Firewalls) . . . . . . . . 10 81 5.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 10 82 5.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 12 83 5.2. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6. Query and Control . . . . . . . . . . . . . . . . . . . . . . 15 85 6.1. Client Procedures . . . . . . . . . . . . . . . . . . . . 15 86 6.2. Server Procedures . . . . . . . . . . . . . . . . . . . . 15 87 7. New Attributes . . . . . . . . . . . . . . . . . . . . . . . . 16 88 7.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 16 89 7.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . . . 16 90 7.3. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . . . 17 91 7.4. TAG Attribute . . . . . . . . . . . . . . . . . . . . . . 17 92 7.5. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 18 93 8. Limitations of STUN Control . . . . . . . . . . . . . . . . . 19 94 8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 19 95 8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 19 96 8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 20 97 8.4. Interacting with Legacy NATs . . . . . . . . . . . . . . . 20 98 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 99 9.1. Authorization . . . . . . . . . . . . . . . . . . . . . . 21 100 9.2. Resource Exhaustion . . . . . . . . . . . . . . . . . . . 21 101 9.3. Comparison to Other NAT Control Techniques . . . . . . . . 21 102 9.4. BOOTNONCE Attribute . . . . . . . . . . . . . . . . . . . 22 103 10. Open Issues and Discussion Points . . . . . . . . . . . . . . 22 104 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 105 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 106 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 107 13.1. Normative References . . . . . . . . . . . . . . . . . . . 24 108 13.2. Informational References . . . . . . . . . . . . . . . . . 25 109 Appendix A. Changes . . . . . . . . . . . . . . . . . . . . . . . 26 110 A.1. Changes in -05 . . . . . . . . . . . . . . . . . . . . . . 26 111 A.2. Changes in -04 . . . . . . . . . . . . . . . . . . . . . . 27 112 A.3. Changes in -03 . . . . . . . . . . . . . . . . . . . . . . 27 113 Appendix B. Implementation Details . . . . . . . . . . . . . . . 27 114 B.1. Internal NAT Operation . . . . . . . . . . . . . . . . . . 27 115 B.2. Linux specifics . . . . . . . . . . . . . . . . . . . . . 28 116 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 117 Intellectual Property and Copyright Statements . . . . . . . . . . 31 119 1. Introduction 121 Two common usages of Simple Traversal Underneath NAT (STUN) 122 ([I-D.ietf-behave-rfc3489bis],[RFC3489]) are Binding Discovery and 123 NAT Keepalive. The Binding Discovery usage allows a STUN client to 124 learn its public IP address (from the perspective of the STUN server 125 it contacted) and the NAT keepalive usage allows a STUN client to 126 keep an active NAT binding alive. Unlike some other techniques 127 (e.g., UPnP IGD [UPnP-IGD], MIDCOM [RFC3303], NAT-PMP 128 [I-D.cheshire-nat-pmp]), NSIS-NSLP [I-D.ietf-nsis-nslp-natfw]), STUN 129 does not interact directly with the NAT. Thus, STUN cannot request 130 additional services from the NAT, such as longer lifetimes which 131 would reduce keepalive messages. Furthermore, allocating new NAT 132 bindings (e.g., each phone call) requires communication with a STUN 133 server located somewhere on the Internet. 135 This document describes three mechanisms for the STUN client to 136 discover NATs and firewalls that are on path with its STUN server. 137 After discovering the NATs and firewalls, the STUN client can query 138 and control those devices using STUN. The STUN client needs to only 139 ask those STUN servers (embedded in the NATs and firewalls) for 140 public IP addresses and UDP ports, thereby offloading that traffic 141 from the STUN server on the Internet. Additionally, the STUN client 142 can ask the NAT's embedded STUN server to extend the NAT binding for 143 the flow, and the STUN client can learn the IP address of the next- 144 outermost NAT. By repeating this procedure with the next-outermost 145 NAT, all of the NATs along that path can have their bindings 146 extended. By learning all of the STUN servers on the path between 147 the public Internet and itself, an endpoint can optimize the path of 148 peer-to-peer communications. 150 2. Notational Conventions 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 3. Motivation and Benefits 158 There are a number of problems with existing NAT traversal 159 techniques, such as STUN, UPnP IGD, MIDCOM, NAT-PMP, and NSIS-NSLP: 161 nested NATs: 162 Today, many ISPs provide their subscribers with modems that have 163 embedded NATs or within the ISP's network. These subscribers then 164 install NATs behind those devices to provide additional features, 165 such as wireless access. In these situations, UPnP IGD and NAT- 166 PMP no longer function, as those protocols can only control the 167 first NAT closest to the host. STUN continues to function, but is 168 unable to optimize network traffic behind those nested NATs (e.g., 169 traffic that stays within the same house or within the same 170 apartment building). 172 One technique to avoid nested NATs is to disable one of the NATs, 173 as recommended by [Vista-cert]. However, this merely sidesteps 174 the problem of nested NATs, as some NATs are installed for a 175 reason (e.g., reduce IP address consumption or provide a modicum 176 of security). Disabling the NAT is also ineffective if the ISP is 177 NATting subscribers within the ISP's network, as ISP NATs do not 178 typically support UPnP. 180 The technique described in this document allows optimization of 181 the traffic behind those NATs so that the traffic can traverse the 182 fewest NATs possible. 184 keepalive chatter: 185 To keep NAT bindings from timing out and to perform its binding 186 discovery, keepalive packets are sent to a server on the Internet. 187 This consumes bandwidth across the user's access network, which in 188 some cases is bandwidth constrained (e.g., wireless, satellite), 189 creates a load on the server, and (for battery-powered devices) 190 consumes battery power. This chattiness can be avoided by using a 191 NAT control mechanism such as UPnP IGD or NAT-PMP. However, 192 relying on such NAT control mechanisms exclusively for NAT 193 traversal is problematic, as they are not universally deployed. 194 Thus, many UDP NAT traversal techniques instead rely on UDP hole 195 punching. 197 The technique described in this document provides a significant 198 reduction of keepalive traffic. The keepalive traffic can be 199 reduced in frequency and can even be sent to just the necessary 200 NAT or firewall (rather than the server). 202 lack of incremental deployment: 203 Many other NAT traversal techniques require the endpoint and its 204 NAT to both support the same NAT traversal technique or else NAT 205 traversal is not possible at all. Examples include NSIS-NSLP, 206 NAT-PMP, UPnP IGD, and MIDCOM. 208 The technique described in this document allows incremental 209 deployment of local endpoints and NATs that support STUN Control. 210 If the local endpoint, or its NATs, does not support the STUN 211 Control functionality, then STUN (see 212 [I-D.ietf-behave-rfc3489bis]), [I-D.ietf-sip-outbound], and ICE 213 [I-D.ietf-mmusic-ice] procedures are used to traverse the NATs 214 without the optimizations described in this document. 216 The protocol described in this document retains the positive features 217 of STUN -- incremental deployment and support of nested NATs -- 218 without introducing drawbacks inherent in other NAT traversal 219 techniques. The protocol optimizes the operation of STUN clients 220 when those STUN clients are behind a NAT that supports the protocol 221 described in this document. STUN clients that are behind a NAT that 222 doesn't support the protocol described in this document continue to 223 function as they do today, without those optimizations. 225 3.1. Comparison with other NAT Traversal Techniques 227 STUN Control offers the following benefits over other NAT traversal 228 and NAT control techniques such as NSIS-NSLP, MIDCOM, NAT-PMP, and 229 UPnP IGD. 231 3.1.1. Simple Security Model 233 Unlike other middlebox control techniques which have relatively 234 complex security models because a separate control channel is used, 235 STUN Control's is simple. It is simple because only flows 236 originating from the same source IP and UDP port can be controlled 237 (i.e., have its NAT timeout queried or extended). Other flows cannot 238 be created, queried, or controlled via STUN Control. 240 3.1.2. Incremental Deployment 242 STUN Control can be incrementally deployed. If the outer-most NAT 243 does not support it, the STUN client behaves as normal -- it merely 244 isn't able to optimize its keepalive (see also Section Section 8.4). 245 If the outer-most NAT does support STUN Control, the STUN client can 246 gain some significant optimizations as described in the following 247 sections. 249 Likewise, there is no change required to applications if NATs are 250 deployed which support STUN Control: such applications will be 251 unaware of the additional functionality in the NAT, and will not be 252 subject to any worse security risks due to the additional 253 functionality in the NAT. 255 3.2. Reduce Keepalive Messages 257 The primary value of the protocol and technique described in this 258 document is the reduction of UDP keepalive messages. This is helpful 259 for several protocols. 261 For each of the protocols below, STUN Control as described in this 262 document enables two optimizations: 264 1. all of the on-path NATs can explicitly indicate their timeouts, 265 reducing the frequency of keepalive messages, and; 267 2. STUN keepalive messages need only be sent to the outer-most NAT, 268 rather than across the access link to the SIP proxy, which vastly 269 reduces the traffic to the SIP proxy. 271 3.2.1. SIP Outbound 273 In SIP outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 274 STUN server. Through the initial STUN request/response exchange with 275 that server, the STUN client learns it is behind a NAT, and learns 276 that NAT's public IP address. Once it has learned the NAT's public 277 IP address, it can query and control that NAT by following the 278 procedures in Section 6. 280 3.2.2. IKE/IPsec NAT Traversal 282 In both the NAT traversal for IKEv1 [RFC3947] and IKEv2 (Section 2.23 283 of [RFC4306]) the IKE endpoints can only learn that a NAT is present, 284 but cannot learn the IP address of that NAT because the IP address is 285 hashed. Thus, IKE itself isn't usable to learn the IP address of the 286 outer-most NAT. STUN can be used to learn the IP address of the 287 outer-most NAT, and STUN Control can then be used to extend the 288 binding lifetime for the UDP port that is being used by IKE. Once 289 this is done, the IPsec NAT keepalive interval can be reduced 290 (Section 4 of [RFC3948]). 292 With IKE/IPsec NAT traversal, there are two ways to use STUN to learn 293 the outer-most NAT: 295 o STUN packets can be sent between the IKE peers on the same port as 296 IKE. IKE, IPsec ESP, and STUN can be demultiplexed. However, 297 this does require changing software in both IKE peers. 299 o STUN packets can be sent to STUN port of the IKE peer's IP 300 address. This does not require changing software on the remote 301 IKE peer, but requires a separate server process running on the 302 remote peer. 304 3.2.3. Teredo 306 Endpoints that implement Teredo [RFC4380] learn their outer-most NATs 307 address as their Teredo Mapped Address. Once learned, the Teredo 308 client can utilize STUN Control to query and control that NAT's (and 309 nested NAT's) UDP keepalive timeout, and thus reduce the refresh 310 interval. 312 In contrast, Teredo's existing s refresh interval determination 313 procedure (Section 5.2.7 of [RFC4380]) allows the Teredo host to 314 learn (but not adjust) the NAT's binding lifetime. There is also a 315 small risk that the NAT will use different refresh intervals for 316 different ports (e.g., due to resource constraints), which 317 contributes to some brittleness. 319 3.3. Optimize ICE 321 The STUN Control usage provides several opportunities to optimize ICE 322 [I-D.ietf-mmusic-ice], as described in this section. 324 3.3.1. Candidate Gathering 326 During its candidate gathering phase, an ICE endpoint normally 327 contacts a STUN server on the Internet. If an ICE endpoint discovers 328 that its outer-most NAT runs a STUN server, the ICE endpoint can use 329 the outer-most NAT's STUN server rather than using the STUN server on 330 the Internet. This saves access bandwidth and reduces the reliance 331 on the STUN server on the Internet -- the STUN server on the Internet 332 need only be contacted once -- when the ICE endpoint first 333 initializes. 335 3.3.2. Learning STUN Servers without Configuration 337 ICE allows endpoints to have multiple STUN servers, but it is 338 difficult to configure all of the STUN servers in the ICE endpoint -- 339 it requires some awareness of network topology. By using the 'walk 340 backward' technique described in this document, all the on-path NATs 341 and their embedded STUN servers can be learned without additional 342 configuration. By knowing the STUN servers at each address domain, 343 ICE endpoints can optimize the network path between two peers. 345 For example, if endpoint-1 is only configured with the IP address of 346 the STUN server on the left, endpoint-1 can learn about NAT-B and 347 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 348 can optimize their media path so they make the optimal path from 349 endpoint-1 to NAT-A to endpoint-2: 351 +-------+ +-------+ +-------------+ 352 endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | 353 +-------+ | +-------+ +-------------+ 354 | 355 endpoint-2 357 3.3.3. Reduce Media Keepalive Messages 359 While very minor, STUN Control makes it possible to optimize media 360 keepalives. This is useful if a video or audio stream is placed on 361 'hold' or 'mute', but is expected to be resumed in the future. ICE 362 uses STUN Indications as its primary media stream keepalive 363 mechanism. This document enables two optimizations of ICE's 364 keepalive technique: 366 1. STUN keepalive messages need only be sent to the outer-most NAT, 367 rather than across the access link to the remote peer, and; 369 2. all of the on-path NATs can explicitly indicate their timeouts, 370 which allows reducing the keepalive frequency. 372 4. Overview of Operation 374 This document describes three functions, which are all implemented 375 using the STUN protocol: 377 Discovery of Middleboxes (NATs and Firewalls): 378 This document describes two techniques for finding NATs or 379 firewalls (see Section 5). These two approaches are: 381 Outside-In: 382 Uses STUN or Teredo to find the outer-most NAT. Then STUN is 383 used to communicate with that NAT and discover the other 384 nested NATs (if any) along that path towards the host by 385 repeated use of STUN with each of those NATs. 387 Tagging: 388 Send a STUN Request packet to your STUN server, and asks for 389 compliant firewalls along the path to indicate their presence 390 by adding an IP address to the STUN Response packet. 392 Querying Discovered Middleboxes: 393 After discovering a NAT or a firewall, it is useful to determine 394 characteristics of the NAT binding or the firewall pinhole. Two 395 of the most useful things to learn is the duration the NAT binding 396 or firewall pinhole will remain open if there is no traffic, and 397 the filtering applied to that binding or pinhole. This is 398 described in Section 6. 400 Controlling Discovered Middleboxes: 401 A NAT or a firewall might default to a more restrictive behavior 402 than desired by an application (e.g., aggressive timeout, 403 filtering). Requesting the NAT or firewall to change its default 404 behavior is useful for traffic optimization (e.g., reduce 405 keepalive traffic) and network optimization (e.g., adjust filters 406 to eliminate the need for a media relay device 407 [I-D.ietf-behave-turn]). A discussion of this functionality can 408 be found in Section 6. 410 5. Discovery of Middleboxes (NATs and Firewalls) 412 This section describes two techniques to discover a NAT and a 413 firewall: outside-in and by tagging. 415 Ideally, a single technique could be selected as an outcome of the 416 standardization process. However, it is possible to combine these 417 two techniques. 419 5.1. Outside-In 421 The endpoint must first discover its outer-most NAT. This can be 422 accomplished using STUN or Teredo. 424 STUN: When a STUN client sends a STUN Request to a STUN server, it 425 receives a STUN Response that indicates the IP address and UDP 426 port seen by the STUN server. If the IP address and UDP port 427 differs from the IP address and UDP port of the socket used to 428 send the request, the STUN client knows there is at least one NAT 429 between itself and the STUN server. The STUN client also learns 430 the 'public' IP address (and port) allocated by the outermost NAT. 432 Teredo: As part of the Teredo qualification procedure, the Teredo 433 client learns the IP address of its outer-most NAT. With that 434 information, the Teredo client can proceed to the next step. 436 After learning the public IP address of its outer-most NAT, the 437 endpoint sends a STUN packet to the STUN port (UDP/3478) of its 438 outer-most NAT's public IP address. The NAT will return a STUN 439 Binding Response message including two important STUN attributes: 441 XOR-MAPPED-ADDRESS, which indicates the public IP address and UDP 442 port for the mapping. As the endpoint just learned this 443 information via STUN or Teredo, this isn't terribly interesting to 444 the endpoint at this time. However, if the endpoint wants to 445 create a new UDP mapping (e.g., for a new UDP flow), the endpoint 446 need only send a STUN request to this outer-most NAT rather than 447 to a host on the Internet. 449 XOR-INTERNAL-ADDRESS, which indicates the IP address and UDP port 450 seen on the *internal* side of the NAT for that translation (see 451 Figure 13). This allows the endpoint to discover, query, and 452 control multiple NATs (nested NATs) along that path. 454 Endpoint NAT STUN Server 455 | | | 456 1. |-----Binding Request (UDP)--------------->| 457 2. |<----Binding Response (UDP)---------------| 458 | | | 459 3. |--Binding Request (UDP)------->| | 460 4. |<-Binding Response (UDP)-------| | 461 | | | 463 Figure 2: Communication Flow 465 In the message flow above, steps 1 and 2 correspond to the STUN 466 behavior described in [I-D.ietf-behave-rfc3489bis]: 468 1: The STUN client sends a UDP Binding Request to its STUN server 469 that is located on the Internet. 471 2: The STUN server on the Internet responds with a UDP Binding 472 Response. 474 After steps 1 and 2, the endpoint has learned the IP address of its 475 outer-most NAT. The endpoint could also have used Teredo to learn 476 that IP address. 478 The next steps are the additional steps performed by the endpoint 479 implementing STUN Control: 481 3: The endpoint sends a STUN Binding Request to the IP address of 482 its outer-most NAT. This will be received by the STUN server 483 embedded in that outer-most NAT. 485 4: The STUN server (embedded in the NAT) responds with a STUN 486 Binding Response. 488 The response obtained in message (4) contains the XOR-MAPPED-ADDRESS 489 attribute, which will have the same value as when the STUN server on 490 the Internet responded (in step 2). Thereafter, so long as the 491 BOOTNONCE value doesn't change, the STUN client can perform steps (3) 492 and (4) for any new UDP communication, without needing to repeat 493 steps (1) and (2). This meets the desire to reduce chattiness. The 494 STUN client also only needs to send keepalives towards the outer-most 495 NAT's IP address, as well (reduces chatter for SIP outbound 496 [I-D.ietf-sip-outbound]). 498 The response obtained in message (4) will also contain the XOR- 499 INTERNAL-ADDRESS, which allows the STUN client to repeat steps (3) 500 and (4) in order to query or control those on-path NATs between 501 itself and its STUN server on the Internet. This is described in 502 detail in Section 5.1.1. This functionality allows ICE to learn more 503 NAT bindings Section 3.3.2 and gives ICE the opportunity to optimize 504 traffic between nested NATs, without requiring configuration of 505 intermediate STUN servers. 507 The STUN client can request each NAT to increase the binding lifetime 508 for that source IP address and source UDP port, as described in 509 Section 7.1. The STUN client receives positive confirmation that the 510 binding lifetime has been extended, allowing the STUN client to 511 significantly reduces its NAT keepalive traffic. Additionally, as 512 long as the NAT complies with [RFC4787] (which is indicated by its 513 support of this document), the STUN client's keepalive traffic need 514 only be sent to the outer-most NAT's IP address. This functionality 515 meets the need to reduce STUN's chattiness. 517 5.1.1. Nested NATs 519 Nested NATs are controlled individually. The nested NATs are 520 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 521 INTERNAL-ADDRESS attribute. 523 If there is only one NAT between an endpoint and the Internet, XOR- 524 INTERNAL-ADDRESS will return the same IP address and UDP port the 525 endpoint is using. If there are multiple NATs between an endpoint 526 and the Internet, XOR-INTERNAL-ADDRESS will return a different IP 527 address than the endpoint is using, which points towards the NAT 528 closer to the endpoint. By repeating this procedure, the endpoint 529 can discover all of the NATs. Note, however, the limitation 530 described in Section 8.1. 532 The following figure shows two nested NATs: 534 +------+ +--------+ +--------+ 535 | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ 536 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 537 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 538 +------+ +--------+ +--------+ 540 Figure 3: Two nested NATs with embedded STUN servers 542 First, the endpoint would learn the outer-most NAT's IP address via 543 STUN or Teredo. The endpoint will then send a STUN binding request 544 to that outer-most NAT. With nested NATs, however, the IP address 545 and UDP port indicated by the XOR-INTERNAL-ADDRESS will not be the 546 STUN client's own IP address and UDP port -- rather, it is the IP 547 address and UDP port on the inside of NAT-A, which are the same as 548 the IP address and UDP port on the outside of the NAT-B -- 10.1.1.2. 550 Because of this, the STUN client repeats the procedure and sends 551 another STUN Binding Request to that newly-learned address (the 552 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 553 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 554 match the STUN client's IP address and UDP port. The STUN client 555 then knows there are no other NATs between itself and NAT-B, and 556 finishes. 558 The message flow with two nested NATs is shown below: 560 STUN Client NAT-B NAT-A STUN Server 561 | | | | 562 1. |-----Binding Request (UDP)--------------->| 563 2. |<----Binding Response (UDP)---------------| 564 | | | | 565 3. |--Binding Request (UDP)------->| | } 566 4. |<-Binding Response (UDP)-------| | } NAT Control 567 | | | | } STUN Usage 568 5. |--Binding Req (UDP)-->| | | } 569 6. |<-Binding Resp (UDP)--| | | } 570 | | | | 572 Figure 4: Message Flow for Outside-In with Two NATs 574 A BOOTNONCE value is obtained from each of these NATs, and is 575 validated whenever a subsequent STUN Binding Request is sent to any 576 of those learned NATs. 578 5.2. Tagging 580 To discover an on-path firewall, the PLEASE-TAG attribute is used 581 with a STUN Binding Request (a STUN packet sent to UDP/3478) message. 582 A firewall would inspect bypassing Binding Request messages and 583 determine whether there is a PLEASE-TAG attribute. When the firewall 584 sees the associated Binding Response, the firewall appends a TAG 585 attribute as the last attribute of the Binding Response. This TAG 586 attribute contains the firewall's management IP address and UDP port. 587 Each on-path firewall would be able to insert its own TAG attribute. 588 In this way, the STUN Response would contain a pointer to each of the 589 on-path firewalls between the client and that STUN server. 591 Motivation for developing the Tagging mechanism: The Outside-In 592 discovery technique (Section 5.1) uses the public IP address of 593 the NAT to find the outer-most NAT that supports STUN Control. 594 Firewalls do not translate packets and hence a different technique 595 is needed to identify firewalls. 597 Note that tagging is similar to how NSIS-NSLP 598 [I-D.ietf-nsis-nslp-natfw], TIST [I-D.shore-tist-prot], and NLS 599 [I-D.shore-nls-tl] function. 601 This figure shows how tagging functions. 603 STUN Client firewall STUN Server 604 | | | 605 1. |--Binding Request->|------------------>| 606 2. | |<-Binding Response-| 607 3. | [inserts tag] | 608 4. |<-Binding Response-| | 609 5. [firewall discovered] | | 611 Figure 5: Tagging Message Flow 613 1. A Binding Request, containing the PLEASE-TAG attribute, is sent 614 to the IP address of the STUN server that is located somewhere on 615 the Internet. This is seen by the firewall, and the firewall 616 remembers the STUN transaction id, and permits the STUN Binding 617 Request packet. 619 2. When the firewall observes a STUN Binding Response packet it 620 checks its cache for the previously stored STUN transaction id. 621 If a previous STUN transaction id was found then the firewall 622 inserts the TAG attribute, which contains the firewall's 623 management address. 625 3. The firewall sends the (modified) STUN Binding Response towards 626 the STUN client. 628 4. The STUN client has now discovered the firewall, and can query it 629 or control it. 631 6. Query and Control 633 This section describes how to use STUN to query and control a NAT 634 that was discovered using the technique described in Section 5. 636 6.1. Client Procedures 638 After discovering on-path NATs and firewalls with the procedure 639 described in Section 5, the STUN client begins querying and 640 controlling those devices. 642 To modify an existing NAT mapping's attributes, or to request a new 643 NAT mapping for a new UDP port, the STUN client can now send a STUN 644 Binding Request to the IP address of address of the respective NAT or 645 firewall (using the STUN UDP port, 3478). 647 Client produces for handling the BOOTNONCE attribute can be found in 648 Section 7.5. 650 6.2. Server Procedures 652 When receiving a STUN Binding Request the STUN controlled NAT will 653 respond with a STUN Binding Response containing an XOR-MAPPED-ADDRESS 654 attribute (which points at the NAT's public IP address and port -- 655 just as if the STUN Binding Request had been sent to a STUN server on 656 the public Internet) and an XOR-INTERNAL-ADDRESS attribute (which 657 points to the source IP address and UDP port the packet STUN Binding 658 Request packet had prior to being NATted). See Figure 13 which 659 depicts how this might be implemented in a NAT. 661 When receiving a STUN Binding Request the STUN controlled firewall 662 will respond with a STUN Binding Response containing an XOR-MAPPED- 663 ADDRESS attribute (which points at the public IP address and port) 664 and an XOR-INTERNAL-ADDRESS attribute (which points to the source IP 665 address of the interface and UDP port where the packet was received, 666 i.e., the internal interface). 668 Server procedures for handling the BOOTNONCE and REFRESH-INTERVAL 669 attributes can be found in Section 7.5 and Section 7.1. 671 STUN Binding Requests, which arrived from its public interface(s), 672 MAY be handled as if the server is not listening on that port (e.g., 673 return an ICMP error). This specification does not need them. 675 7. New Attributes 677 7.1. REFRESH-INTERVAL Attribute 679 In a STUN request, the REFRESH-INTERVAL attribute indicates the 680 number of milliseconds that the client wants the NAT binding (or 681 firewall pinhole) to be opened. This applies to all bindings that 682 exist in that NAT from that same source IP address and same source 683 UDP port (see also Appendix B.2). In a STUN response, the REFRESH- 684 INTERVAL attribute indicates the number of milliseconds the STUN 685 server (embedded in the NAT or firewall) will keep the bindings open. 687 REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and 688 represents an interval measured in milliseconds (thus the maximum 689 value is approximately 50 days). This attribute can be present in 690 Binding Requests and in Binding Responses. 692 7.2. XOR-INTERNAL-ADDRESS Attribute 694 This attribute MUST be present in a Binding Response and is necessary 695 to allow a STUN client to perform the outside-in discovery technique, 696 in order to discover all of the STUN Control-aware NATs along the 697 path. 699 The format of the XOR-INTERNAL-ADDRESS attribute is: 701 0 1 2 3 702 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 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 704 |x x x x x x x x| Family | X-Port | 705 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 | X-Address (32 bits or 128 bits) | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 Figure 6: XOR-INTERNAL-ADDRESS Attribute 711 The meaning of Family, X-Port, and X-Address are exactly as in 712 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 713 address family (IPv4 or IPv6). 715 7.3. PLEASE-TAG Attribute 717 If a STUN client wants to discover on-path firewalls, it MUST include 718 this attribute in its Binding Response when performing the Binding 719 Discovery usage. 721 STUN servers are not expected to understand this attribute; if they 722 return this attribute as an unknown attribute, it does not affect the 723 operation described in this document. 725 The format of the PLEASE-TAG attribute is: 727 0 1 2 3 728 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 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 |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| 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 7: PLEASE-TAG Attribute 735 The 3-bit Mechanism field indicates the control mechanism desired. 736 Currently, the only defined mechanism is STUN Control, and is 737 indicated with all zeros. The intent of this field is to allow 738 additional control mechanisms (e.g., UPnP IGD, NAT-PMP, MIDCOM). 740 7.4. TAG Attribute 742 The TAG attribute contains the XOR'd management transport address of 743 the middlebox. Typically, a firewall as well as a NAT may find this 744 technique useful as well. 746 If the associated STUN Request contained the PLEASE-TAG attribute, a 747 middlebox MUST append this attribute as the last attribute of the 748 STUN Response (with that same transaction-id). After appending this 749 attribute, the STUN length field MUST be also be adjusted. 751 The format of the TAG attribute is: 753 0 1 2 3 754 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 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 |Mech.|M|x x x x| Family | X-Port | 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | X-Address (32 bits or 128 bit) | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 Figure 8: TAG Attribute 763 Mech: The 3-bit Mechanism field indicates the control mechanism 764 supported on the described port. Currently, the only defined 765 mechanism is STUN Control, and is indicated with 0x0. The intent of 766 this field is to allow additional control mechanisms (e.g., UPnP IGD, 767 NAT-PMP, MIDCOM). 769 The one-bit M field indicates if this firewall permits Mobility 770 Header packets to flow through it ([RFC3775]). 772 The meaning of Family, X-Port, and X-Address are exactly as in 773 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 774 address family (IPv4 or IPv6). 776 7.5. BOOTNONCE Attribute 778 The BOOTNONCE attribute protects against the attack described in 779 Section 9.4. 781 Client procedures: The STUN client expects each NAT to return the 782 same BOOTNONCE value each time that NAT is contacted. If a NAT 783 returns a different value, the STUN client MUST NOT use any 784 information returned in the Binding Response and MUST re-run the STUN 785 Control procedures from the beginning (i.e., obtain its public IP 786 address from the STUN server on the Internet). This would only occur 787 if an attack is in progress or if the NAT rebooted. If the NAT 788 rebooted, it is good practice to re-run the STUN Control procedures 789 anyway, as the network topology could be different as well. 791 Server procedures: This attribute's value is a hash of the STUN 792 client's IP address and a value that is randomly-generated each time 793 the NAT is initialized. The STUN client's IP address is included in 794 this hash to thwart an attacker attaching to the NAT's internal 795 network and learning the BOOTNONCE value. 797 The format of the BOOTNONCE attribute is: 799 0 1 2 3 800 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 801 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 802 | Boot Nonce value (32 bits) | 803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 Figure 9: BOOTNONCE Attribute 807 8. Limitations of STUN Control 809 8.1. Overlapping IP Addresses with Nested NATs 811 If nested NATs have overlapping IP address space, there will be 812 undetected NATs on the path. When this occurs, the STUN client will 813 be unable to detect the presence of NAT-A if NAT-A assigns the same 814 UDP port. For example, in the following figure, NAT-A and NAT-B are 815 both using 10.1.1.x as their 'private' network. 817 +------+ +--------+ +--------+ 818 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1 819 | STUN +-------+ NAT-A +-----+ NAT-B +------ 820 |client| 10.1.1.1 | 10.1.1.1 | 821 +------+ +--------+ +--------+ 823 Figure 10: Overlapping Addresses with Nested NATs 825 When this situation occurs, the STUN client can only learn the outer- 826 most address. This is not a problem -- the STUN client is still able 827 to communicate with the outer-most NAT and is still able to avoid 828 consuming access network bandwidth and avoid communicating with the 829 public STUN server. All that is lost is the ability to optimize 830 paths within the private network that has overlapped addresses. 832 Of course when such an overlap occurs the end host (STUN client) 833 cannot successfully establish bi-directional communication with hosts 834 in the overlapped network, anyway. 836 8.2. Address Dependent NAT on Path 838 In order to utilize the mechanisms described in this document, a STUN 839 Request is sent from the same source IP address and source port as 840 the original STUN Binding Discovery message, but is sent to a 841 different destination IP address -- it is sent to the IP address of 842 an on-path NAT. If there is an on-path NAT, between the STUN client 843 and the STUN server, with 'address dependent' or 'address and port- 844 dependent' mapping behavior (as described in Section 4.1 of 845 [RFC4787]), that NAT will prevent a STUN client from taking advantage 846 of the technique described in this document. When this occurs, the 847 ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and 848 the NAT's embedded STUN server will differ. 850 An example of such a topology is shown in the following figure: 852 +------+ +--------+ +--------+ 853 | STUN | | 10.1.1.2 | 192.0.2.1 854 |client+-----+ NAT-A +---+ NAT-B +------ 855 | | 10.1.1.1 | 10.1.1.1 | 856 +------+ +--------+ +--------+ 858 In this figure, NAT-A is a NAT that has address dependent mapping. 859 Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1 860 on UDP/3478, NAT-A will choose a new public UDP port for that 861 communication. NAT-B will function normally, returning a different 862 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 863 that a symmetric NAT exists between the STUN client and the STUN 864 server it just queried (NAT-B, in this example). 866 Figure 11: Address Dependant NAT on Path 868 8.3. Address Dependent Filtering 870 If there is an NAT along the path that has address dependent 871 filtering (as described in section 5 of [RFC4787]), and the STUN 872 client sends a STUN packet directly to any of the on-path NATs public 873 addresses, the address-dependent filtering NAT will filter packets 874 from the remote peer. Thus, after communicating with all of the on- 875 path NATs the STUN client MUST send a UDP packet to the remote peer, 876 if the remote peer is known. 878 8.4. Interacting with Legacy NATs 880 There will be cases where the STUN client attempts to communicate 881 with an on-path NAT, which does not support STUN Control. There are 882 two cases: 884 o the NAT does not run a STUN server on its public interface (this 885 will be the most common) 887 o the NAT does run a STUN server on its public interface, but does 888 not return the XOR-INTERNAL-ADDRESS attribute defined in this 889 document 891 In both cases the optimizations described in this section will not be 892 available to the STUN client. This is no worse than the condition 893 today. This allows incremental upgrades of applications and NATs 894 that implement the technique described in this document. 896 9. Security Considerations 898 This security considerations section will be expanded in a subsequent 899 version of this document. So far, the authors have identified the 900 following considerations: 902 9.1. Authorization 904 Only hosts that are 'inside' a NAT, which a NAT is already providing 905 services for, can query or adjust the timeout of a NAT mapping. 907 A discussion of additional authorization mechanisms that might be 908 needed for firewall traversal can be found at 909 [I-D.wing-session-auth]. 911 9.2. Resource Exhaustion 913 A malicious STUN client could ask for absurdly long NAT bindings 914 (days) for many UDP sessions, which would exhaust the resources in 915 the NAT. The same attack is possible (without considering this 916 document and without considering STUN or other UNSAF [RFC3424] NAT 917 traversal techniques) -- a malicious TCP (or UDP) client can open 918 many TCP (or UDP) connections, and keep them open, causing resource 919 exhaustion in the NAT. 921 9.3. Comparison to Other NAT Control Techniques 923 Like UPnP IGD, NAT-PMP, and host-initiated MIDCOM, the STUN usage 924 described in this document allows a host to learn its public IP 925 address and UDP port mapping, and to request a specific lifetime for 926 mappings from that same source IP address and same source UDP port. 928 However, unlike other NAT traversal technologies, STUN Control 929 described in this document only allows each UDP port on the host to 930 create and adjust the mapping timeout of its own NAT mappings. 931 Specifically, an application on a host can only adjust the duration 932 of a NAT bindings for itself, and not for another application on that 933 same host, and not for other hosts. This provides security 934 advantages over other NAT control mechanisms where malicious software 935 on a host can surreptitiously create NAT mappings to another 936 application or to another host. 938 9.4. BOOTNONCE Attribute 940 Using the mechanisms described in this document, a STUN client learns 941 the public IP addresses of its NAT which supports the mechanisms 942 described in this document. However, without the STUN client's 943 knowledge, that NAT may acquire a new IP address (e.g., due to DHCP 944 lease expiration or network renumbering). When this occurs, the STUN 945 client will send a STUN Binding Request to the NAT's previous public 946 IP address. If an attacker were to run a rogue STUN server on that 947 address, the attacker will have effectively compromised the STUN 948 server, as described in Section 12.2.1 of [RFC3489]. The attacker, 949 upon receiving STUN Binding Requests, will reply with STUN Binding 950 Responses indicating an IP address the attacker controls. The 951 attacker will thus have access to the subsequent flow established by 952 the STUN client (e.g., RTP traffic). This attack is possible because 953 the STUN client is unable to distinguish the attacker's replies from 954 replies from the legitimate NAT. 956 To defend against this attack, the STUN server embedded in the NAT 957 returns a BOOTNONCE value. The STUN client validates that it 958 receives the same BOOTNONCE value in each STUN Binding Response from 959 that NAT. If the STUN client receives a new BOOTNONCE value, the 960 STUN client discards information about NATs it has learned through 961 the procedures in this document, and restarts the procedure described 962 in this document. 964 A weakness of this approach is that an attacker can learn the 965 BOOTNONCE value if the attacker is able to connect to the NAT's 966 internal network prior to initiating the attack. This is plausible 967 if the internal network has no security (e.g., public WiFi network). 968 For this reason, it is RECOMMENDED that the BOOTNONCE value is hashed 969 with the STUN client's IP address. Doing so means that a successful 970 attacker must acquire both the same IP address as the victim from 971 behind the NAT (to learn the BOOTNONCE), and must also acquire the 972 NAT's previous public IP address, or needs to be on-path between the 973 victim and its NAT (in which case the attacker has no incentive to 974 redirect traffic elsewhere to observe such traffic; however, the 975 attacker might be interested in redirecting traffic towards another 976 endpoint on the Internet. To thwart that attack, the STUN client 977 MUST only honor STUN responses that have an X-MAPPED-ADDRESS that 978 matches the public IP address of the NAT-embedded STUN server. 980 10. Open Issues and Discussion Points 982 o Discussion Point: After discovering NATs and firewalls, 983 controlling those devices might also be done with a middlebox 984 control protocol (e.g., by using standard or slightly modified 985 versions of SIMCO, UPnP IGD, MIDCOM, or NAT-PMP). This is open 986 for discussion as this document is scoped within the IETF. 988 o Discussion Point: Tagging would also be useful for the 989 Connectivity Check usage (which is used by ICE), especially 990 considering that a different firewall may be traversed for media 991 than for the initial Binding Discovery usage. In such a 992 situation, the new on-path firewall's policy might not allow a 993 binding request to leave the network or allow a binding response 994 to return. In this case, the firewall would need to indicate its 995 presence to the STUN client in another way. An ICMP error message 996 may be appropriate, and an ICMP extension [RFC4884] could indicate 997 the firewall is controllable. 999 o Open issue: We could resolve the problem of address dependant 1000 NATs along the path by introducing a new STUN attribute which 1001 indicates the UDP port the STUN client wants to control. However, 1002 this changes the security properties of STUN Control, so this 1003 seems undesirable. 1005 Open issue: When the STUN client detects an address dependant 1006 NAT, should we recommend it abandon the STUN Control usage, and 1007 revert to operation as if it doesn't support the STUN Control 1008 usage? 1010 o Open issue: How many filter entries are in address dependent 1011 filtering NATs? If only one, this does become a real limitation 1012 if NATs are nested; if they're not nested, the outer-most NAT can 1013 avoid overwriting its own address in its address dependent filter. 1015 o Discussion: One way to thwart a resource consumption attack is to 1016 challenge the STUN client. This would allow the STUN server to 1017 delay the establishment of resources before a return-routability 1018 test is performed. This functionality is currently not provided 1019 by this specification. The NONCE attribute 1020 [I-D.ietf-behave-rfc3489bis] could be useful to provide this 1021 function. However, the mere sending of a UDP packet across a NAT 1022 creates a binding (for ~2 minutes), and there isn't a return- 1023 routability check for that. 1025 o The inside-out discovery technique was removed with version -03 of 1026 this document. The procedure worked as follows: The STUN client 1027 sends a STUN request to UDP/3478 of the IP address of its default 1028 router. If there is a STUN server listening there, it will 1029 respond, and will indicate its default route via the new DEFAULT- 1030 ROUTE attribute. With that information, the STUN client can 1031 discover the next-outermost NAT by repeating the procedure. More 1032 feedback is needed to determine whether the functionality is 1033 needed. 1035 11. IANA Considerations 1037 This section registers new STUN attributes per the procedures in 1038 [I-D.ietf-behave-rfc3489bis]: 1040 Mandatory range: 1041 0x0029 XOR-INTERNAL-ADDRESS 1042 0x00.. BOOTNONCE 1044 Optional range: 1045 0x8024 REFRESH-INTERVAL 1046 0x80.. PLEASE-TAG 1047 0x80.. TAG 1049 12. Acknowledgements 1051 Thanks to Remi Denis-Courmont, Christian Dickmann, Bajko Gabor, 1052 Markus Isomaki, Cullen Jennings, and Philip Matthews for their 1053 suggestions which have improved this document. 1055 Thanks to Christian Dickmann and Yan Sun for their initial 1056 implementations of STUN Control. 1058 13. References 1060 13.1. Normative References 1062 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1063 Requirement Levels", BCP 14, RFC 2119, March 1997. 1065 [I-D.ietf-behave-rfc3489bis] 1066 Rosenberg, J., Huitema, C., Mahy, R., Matthews, P., and D. 1067 Wing, "Session Traversal Utilities for (NAT) (STUN)", 1068 draft-ietf-behave-rfc3489bis-11 (work in progress), 1069 October 2007. 1071 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1072 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1073 RFC 4787, January 2007. 1075 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1076 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1077 Through Network Address Translators (NATs)", RFC 3489, 1078 March 2003. 1080 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1081 in IPv6", RFC 3775, June 2004. 1083 13.2. Informational References 1085 [I-D.ietf-behave-turn] 1086 Rosenberg, J., "Traversal Using Relays around NAT (TURN): 1087 Relay Extensions to Session Traversal Utilities for NAT 1088 (STUN)", draft-ietf-behave-turn-04 (work in progress), 1089 July 2007. 1091 [UPnP-IGD] 1092 UPnP Forum, "Universal Plug and Play (UPnP) Internet 1093 Gateway Device (IGD)", November 2001, 1094 . 1096 [Vista-cert] 1097 Microsoft, "Windows Logo Program Device Requirements", 1098 2006, . 1102 [I-D.cheshire-nat-pmp] 1103 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 1104 draft-cheshire-nat-pmp-02 (work in progress), 1105 October 2006. 1107 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1108 A. Rayhan, "Middlebox communication architecture and 1109 framework", RFC 3303, August 2002. 1111 [I-D.ietf-mmusic-ice] 1112 Rosenberg, J., "Interactive Connectivity Establishment 1113 (ICE): A Protocol for Network Address Translator (NAT) 1114 Traversal for Offer/Answer Protocols", 1115 draft-ietf-mmusic-ice-18 (work in progress), 1116 September 2007. 1118 [I-D.ietf-sip-outbound] 1119 Jennings, C. and R. Mahy, "Managing Client Initiated 1120 Connections in the Session Initiation Protocol (SIP)", 1121 draft-ietf-sip-outbound-10 (work in progress), July 2007. 1123 [I-D.ietf-nsis-nslp-natfw] 1124 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1125 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-15 (work in 1126 progress), July 2007. 1128 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1129 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1130 April 2007. 1132 [I-D.shore-tist-prot] 1133 Shore, M., "The TIST (Topology-Insensitive Service 1134 Traversal) Protocol", draft-shore-tist-prot-00 (work in 1135 progress), May 2002. 1137 [I-D.shore-nls-tl] 1138 Shore, M., "Network-Layer Signaling: Transport Layer", 1139 draft-shore-nls-tl-05 (work in progress), June 2007. 1141 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1142 Self-Address Fixing (UNSAF) Across Network Address 1143 Translation", RFC 3424, November 2002. 1145 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1146 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1147 RFC 3948, January 2005. 1149 [I-D.wing-session-auth] 1150 Wing, D., "Media Session Authorization", 1151 draft-wing-session-auth-00 (work in progress), 1152 February 2006. 1154 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 1155 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 1156 January 2005. 1158 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1159 RFC 4306, December 2005. 1161 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1162 Network Address Translations (NATs)", RFC 4380, 1163 February 2006. 1165 Appendix A. Changes 1167 A.1. Changes in -05 1169 o Teredo is another mechanism to learn outer-most NAT, and Teredo 1170 also benefits from STUN Control with reduced frequency of 1171 keepalives. 1173 o Provided more detail in how IKE/IPsec-over-UDP would operate with 1174 STUN Control. 1176 A.2. Changes in -04 1178 o Clarified that all existing bindings, for that source IP address 1179 and UDP port, are controlled with STUN Control. 1181 o Introduction now concentrates on the primary purpose of STUN 1182 Control, namely reducing keepalive traffic for SIP-Outbound. 1184 A.3. Changes in -03 1186 o Removed TLS from normal STUN operation (as few use it, and ICE 1187 makes it unnecessary anyway) 1189 o BOOTNONCE attribute replaces STUN Control's previous use of TLS. 1191 o Added "MIP-capable" bit to TAG attribute 1193 o Removed "inside-out" discovery technique. 1195 Appendix B. Implementation Details 1197 B.1. Internal NAT Operation 1198 Internally, the NAT can be diagrammed to function like this, where 1199 the NAT operation occurs before the STUN server: 1201 | 1202 | outside interface 1203 | 1204 +---------+---------------+ 1205 | | | 1206 | | +--------+ | 1207 | |----+ STUN | | 1208 | | | Server | | 1209 | | +---^----+ | 1210 | | | | 1211 | | API | 1212 | | | | 1213 | +-------+--------V----+ | 1214 | | NAT Function | | 1215 | +-------+-------------+ | 1216 | | | 1217 +---------+---------------+ 1218 | 1219 | inside interface 1220 | 1221 | 1222 The host on the 'inside' interface of the NAT sends packets to the 1223 NAT's public interface, where the STUN server is listening. This 1224 STUN server returns the same public IP address (XOR-MAPPED-ADDRESS) 1225 as a STUN server that resides on a separate server on the 'outside' 1226 interface. In order to query and to control the NAT binding 1227 lifetimes, the STUN server uses an API with the NAT function. 1229 Figure 13: Block Diagram of Internal NAT Operation 1231 B.2. Linux specifics 1233 The Linux NAT implementation maintains a separate connection table 1234 entry for every binding. When STUN Control is used to control the 1235 binding lifetime (e.g., extend the lifetime), the binding lifetime 1236 for each of those connection table entries is modified to the new 1237 value. 1239 For example, with the following message flow: 1240 STUN Client NAT STUN Server 1241 | | | 1242 1. |-----Binding Request (UDP)--------------->| 1243 2. |<----Binding Response (UDP)---------------| 1244 | | | 1245 3. |--Binding Request (UDP)------->| | 1246 4. |<-Binding Response (UDP)-------| | 1247 | | | 1249 the following two connection table entries are created: 1250 udp 17 24 src=10.7.2.4 dst=10.7.1.2 sport=1024 1251 dport=3478 packets=1 bytes=64 src=10.7.1.2 1252 dst=10.7.1.3 sport=3478 dport=1024 packets=1 1253 bytes=84 mark=0 use=1 1254 udp 17 25 src=10.7.2.4 dst=10.7.1.3 sport=1024 1255 dport=3478 packets=2 bytes=64 src=10.7.1.3 1256 dst=10.7.2.4 sport=3478 dport=1024 packets=2 1257 bytes=208 mark=0 use=1 1258 the first src/dst/sport/dport combination is the internal and the 1259 second one is the external version. Both are equal in the second 1260 connection, as the NAT function wasn't active for the "internal" 1261 message. 1263 s 1265 Authors' Addresses 1267 Dan Wing 1268 Cisco Systems, Inc. 1269 170 West Tasman Drive 1270 San Jose, CA 95134 1271 USA 1273 Email: dwing@cisco.com 1275 Jonathan Rosenberg 1276 Cisco Systems, Inc. 1277 Edison, NJ 07054 1278 USA 1280 Email: jdrosen@cisco.com 1281 Hannes Tschofenig 1282 Nokia Siemens Networks 1283 Otto-Hahn-Ring 6 1284 Munich, Bavaria 81739 1285 Germany 1287 Email: Hannes.Tschofenig@nsn.com 1288 URI: http://www.tschofenig.com 1290 Full Copyright Statement 1292 Copyright (C) The IETF Trust (2007). 1294 This document is subject to the rights, licenses and restrictions 1295 contained in BCP 78, and except as set forth therein, the authors 1296 retain all their rights. 1298 This document and the information contained herein are provided on an 1299 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1300 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1301 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1302 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1303 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1304 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1306 Intellectual Property 1308 The IETF takes no position regarding the validity or scope of any 1309 Intellectual Property Rights or other rights that might be claimed to 1310 pertain to the implementation or use of the technology described in 1311 this document or the extent to which any license under such rights 1312 might or might not be available; nor does it represent that it has 1313 made any independent effort to identify any such rights. Information 1314 on the procedures with respect to rights in RFC documents can be 1315 found in BCP 78 and BCP 79. 1317 Copies of IPR disclosures made to the IETF Secretariat and any 1318 assurances of licenses to be made available, or the result of an 1319 attempt made to obtain a general license or permission for the use of 1320 such proprietary rights by implementers or users of this 1321 specification can be obtained from the IETF on-line IPR repository at 1322 http://www.ietf.org/ipr. 1324 The IETF invites any interested party to bring to its attention any 1325 copyrights, patents or patent applications, or other proprietary 1326 rights that may cover technology that may be required to implement 1327 this standard. Please address the information to the IETF at 1328 ietf-ipr@ietf.org. 1330 Acknowledgment 1332 Funding for the RFC Editor function is provided by the IETF 1333 Administrative Support Activity (IASA).