idnits 2.17.1 draft-wing-behave-nat-control-stun-usage-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1121. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1145. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 8 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 31, 2007) is 6175 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-06 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-15 == Outdated reference: A later version (-20) exists of draft-ietf-sip-outbound-08 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-14 == Outdated reference: A later version (-06) exists of draft-shore-nls-tl-04 Summary: 2 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE D. Wing 3 Internet-Draft J. Rosenberg 4 Intended status: Standards Track Cisco Systems 5 Expires: December 2, 2007 May 31, 2007 7 Discovering, Querying, and Controlling Firewalls and NATs using STUN 8 draft-wing-behave-nat-control-stun-usage-02 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on December 2, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 Simple Traversal Underneath NAT (STUN) is a mechanism for traversing 42 NATs. STUN requests are transmitted through a NAT to external STUN 43 servers. While this works very well, its two primary drawbacks are 44 the inability to modify the properties of a NAT binding and the need 45 to query a public STUN server for every new NAT binding (e.g., every 46 phone call). These drawbacks require frequent messages which present 47 a load on servers (like SIP servers and STUN servers) and are bad for 48 low speed access networks, such as cellular access. 50 This document describes several mechanisms to discover NATs and 51 firewalls and a method to query and control them. With these 52 changes, binding discovery and keepalive traffic can be reduced to 53 involve only the necessary NATs or firewalls. At the same time, 54 backwards compatibility with NATs and firewalls that do not support 55 this document is retrained. 57 This document is discussed on the BEHAVE mailing list, 58 , in anticipation of a 59 BoF at IETF69 in Chicago. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Conventions Used in this Document . . . . . . . . . . . . . . 5 66 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 67 5. Discovery of Middleboxes . . . . . . . . . . . . . . . . . . . 6 68 5.1. Outside-In . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.1.1. Nested NATs . . . . . . . . . . . . . . . . . . . . . 11 70 5.1.2. XOR-INTERNAL-ADDRESS Attribute . . . . . . . . . . . . 12 71 5.1.3. Interacting with Legacy NATs . . . . . . . . . . . . . 13 72 5.2. Inside-Out . . . . . . . . . . . . . . . . . . . . . . . . 13 73 5.2.1. DEFAULT-ROUTE Attribute . . . . . . . . . . . . . . . 14 74 5.3. Tagging . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.3.1. PLEASE-TAG Attribute . . . . . . . . . . . . . . . . . 15 76 5.3.2. TAG Attribute . . . . . . . . . . . . . . . . . . . . 16 77 6. Query and Control . . . . . . . . . . . . . . . . . . . . . . 17 78 6.1. REFRESH-INTERVAL Attribute . . . . . . . . . . . . . . . . 17 79 6.2. Client Procedures . . . . . . . . . . . . . . . . . . . . 17 80 6.3. Server Procedures . . . . . . . . . . . . . . . . . . . . 18 81 7. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 82 7.1. Simple Security Model . . . . . . . . . . . . . . . . . . 19 83 7.2. Incremental Deployment . . . . . . . . . . . . . . . . . . 19 84 7.3. Optimize SIP-Outbound . . . . . . . . . . . . . . . . . . 19 85 7.4. Optimize ICE . . . . . . . . . . . . . . . . . . . . . . . 19 86 7.4.1. Candidate Gathering . . . . . . . . . . . . . . . . . 20 87 7.4.2. Keepalive . . . . . . . . . . . . . . . . . . . . . . 20 88 7.4.3. Learning STUN Servers without Configuration . . . . . 20 89 8. Limitations . . . . . . . . . . . . . . . . . . . . . . . . . 21 90 8.1. Overlapping IP Addresses with Nested NATs . . . . . . . . 21 91 8.2. Address Dependent NAT on Path . . . . . . . . . . . . . . 21 92 8.3. Address Dependent Filtering . . . . . . . . . . . . . . . 22 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 94 9.1. Authorization and Resource Exhaustion . . . . . . . . . . 23 95 9.2. Comparison to Other NAT Control Techniques . . . . . . . . 23 96 9.3. Rogue STUN Server . . . . . . . . . . . . . . . . . . . . 23 97 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 98 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 99 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 100 12.1. Normative References . . . . . . . . . . . . . . . . . . . 24 101 12.2. Informational References . . . . . . . . . . . . . . . . . 25 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 103 Intellectual Property and Copyright Statements . . . . . . . . . . 27 105 1. Introduction 107 Two common usages of STUN ([I-D.ietf-behave-rfc3489bis],[RFC3489]) 108 are Binding Discovery and NAT Keepalive. The Binding Discovery usage 109 allows a STUN client to learn its public IP address (from the 110 perspective of the STUN server it contacted) and the NAT keepalive 111 usage allows a STUN client to keep an active NAT binding alive. 112 Unlike some other techniques (e.g., UPnP [UPnP], MIDCOM [RFC3303], 113 Bonjour [Bonjour]), STUN does not interact directly with the NAT. 114 Because STUN doesn't interact directly with the NAT, STUN cannot 115 request additional services from the NAT such as longer lifetimes 116 (which would reduce keepalive messages), and each new NAT binding 117 (e.g., each phone call) requires communicating with the STUN server 118 on the Internet. 120 This paper describes three mechanisms for the STUN client to discover 121 NATs and firewalls that are on path with its STUN server. After 122 discovering the NATs and firewalls, the STUN client can query and 123 control those devices using STUN. The STUN client needs to only ask 124 those STUN servers (embedded in the NATs and firewalls) for public IP 125 addresses and UDP ports, thereby offloading that traffic from the 126 STUN server on the Internet. Additionally, the STUN client can ask 127 the NAT's embedded STUN server to extend the NAT binding for the 128 flow, and the STUN client can learn the IP address of the next- 129 outermost NAT. By repeating this procedure with the next-outermost 130 NAT, all of the NATs along that path can have their bindings 131 extended. By learning all of the STUN servers on the path between 132 the public Internet and itself, an endpoint can optimize the path of 133 peer-to-peer communications. 135 2. Motivation 137 There are a number of problems with existing NAT traversal techniques 138 such as STUN [RFC3489], [UPnP], and [Bonjour]): 140 nested NATs: 141 Today, many ISPs provide their subscribers with modems that have 142 embedded NATs, often with only one physical Ethernet port. These 143 subscribers then install NATs behind those devices to provide 144 additional features, such as wireless access. Another example is 145 a NAT in the basement of an apartment building or a campus 146 dormitory, which combined with a NAT within the home or dormitory 147 room also result in nested NATs. In both of these situations, 148 UPnP and Bonjour no longer function at all, as those protocols can 149 only control the first NAT closest to the host. STUN continues to 150 function, but is unable to optimize network traffic behind those 151 nested NATs (e.g., traffic that stays within the same house or 152 within the same apartment building). 154 One technique to avoid nested NATs is to disable one of the NATs 155 if it obtains an RFC1918 address on its WAN interface. This 156 merely sidesteps the problem. This technique is also ineffective 157 if the ISP is NATting its subscribers and the ISP restricts each 158 subscriber to one IP address. 160 The technique described in this paper allows optimization of the 161 traffic behind those NATs so that the traffic can traverse the 162 fewest NATs possible. 164 chattiness: 165 To perform its binding discovery, a STUN client communicates to a 166 server on the Internet. This consumes bandwidth across the user's 167 access network which in some cases is bandwidth constrained (e.g., 168 wireless, satellite). STUN's chattiness is often cited as a 169 reason to use other NAT traversal techniques such as UPnP or 170 Bonjour. 172 The technique described in this paper provides a significant 173 reduction in STUN's chattiness, to the point that the only time a 174 STUN client needs to communicate with the STUN server on the 175 public Internet is when the STUN client is initialized. 177 incremental deployment: 178 Many other NAT traversal techniques require the endpoint and its 179 NAT to both support the new feature or else NAT traversal isn't 180 possible at all. 182 The technique described in this paper allows incremental 183 deployment of local endpoints and their NATs that support STUN 184 Control. If the local endpoint, or its NATs, don't support the 185 STUN Control functionality, normal STUN and ICE 186 [I-D.ietf-mmusic-ice] procedures are used to traverse the NATs 187 without the optimizations described in this paper. 189 3. Conventions Used in this Document 191 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 192 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 193 document are to be interpreted as described in [RFC2119]. 195 4. Overview of Operation 197 This document describes three functions, which are all implemented 198 using the STUN protocol: 200 Discovery of Middleboxes (NATs and Firewalls): 201 This document describes three techniques to find NATs or 202 firewalls. The first technique uses STUN to find the outer-most 203 NAT and works itself towards the host. The second technique 204 requests on-path firewalls or NATs to append their IP address to a 205 STUN packet. The third technique sends a STUN packet to the 206 default router (which, in a small network, is often your NAT). 207 This is described in Section 5. 209 Querying Discovered Middleboxes: 210 After discovering a NAT or a firewall, it's useful to determine 211 characteristics of the NAT binding or the firewall pinhole. Two 212 of the most useful things to learn is the duration the NAT binding 213 or firewall pinhole will remain open if there is no traffic, and 214 the filtering applied to that binding or pinhole. This is 215 described in Section 6. 217 Discussion Point: After discovering NATs and firewalls, 218 querying those devices might also be done with a middlebox 219 control protocol (e.g., by using standard or slightly modified 220 versions of SIMCO [RFC4540], UPnP, MIDCOM, or Bonjour). This 221 is open for discussion as this document is scoped within the 222 IETF. 224 Controlling Discovered Middleboxes 225 A NAT or firewall might default to a more restrictive behavior 226 than desired by an application (e.g., aggressive timeout, 227 filtering). Requesting the NAT or firewall to change its default 228 behavior is useful for traffic optimization (e.g., reduce 229 keepalive traffic) and network optimization (e.g., adjust filters 230 to eliminate the need for a media relay 231 device[I-D.ietf-behave-turn]). This is described in Section 6. 233 Discussion Point: After discovering NATs and firewalls, 234 controlling those devices might also be done with a middlebox 235 control protocol (e.g., by using standard or slightly modified 236 versions of SIMCO, UPnP, MIDCOM, or Bonjour). This is open for 237 discussion as this document is scoped within the IETF. 239 5. Discovery of Middleboxes 241 There are three techniques to discover a middlebox (a NAT or a 242 firewall): outside-in, inside-out (useful when the outer-most NAT 243 device doesn't support STUN Control), or by tagging (useful for 244 firewalls). 246 These techniques can be combined in useful ways. For example, if 247 your inner-most NAT supports STUN Control, and your public STUN 248 server returns the same IP address and port as your inner-most NAT, 249 you know you don't have a NAT between your inner-most NAT and the 250 STUN server. Otherwise, you know there is a NAT between your inner- 251 most NAT and the STUN server (e.g., an ISP-supplied device or whoever 252 is providing your Internet service). Knowing this allows optimizing 253 NAT keepalives. 255 5.1. Outside-In 257 When a STUN client sends a STUN Request to a STUN server, it receives 258 a STUN Response which indicates the IP address and UDP port seen by 259 the STUN server. If the IP address and UDP port differs from the IP 260 address and UDP port of the socket used to send the request, the STUN 261 client knows there is at least one NAT between itself and the STUN 262 server, and knows the 'public' IP address of that NAT. For example, 263 in the following diagram, the STUN client learns the public IP 264 address of its NAT is 192.0.2.1: 266 +--------+ +---------------+ 267 | STUN | | 192.0.2.1 +--------+ 268 | Client +-------------+ +------+ STUN | 269 | 10.1.1.2/4193 10.1.1.1 | | Server | 270 +--------+ | | +--------+ 271 | NAT with | 272 | Embedded STUN | 273 | Server | 274 +---------------+ 276 Figure 1: One NAT with embedded STUN server 278 Internally, the NAT can be diagrammed to function like this, where 279 the NAT operation occurs before the STUN server: 281 | 282 | outside interface 283 | 284 +---------+---------------+ 285 | | | 286 | | +--------+ | 287 | |----+ STUN | | 288 | | | Server | | 289 | | +--------+ | 290 | | | 291 | +-------+-------------+ | 292 | | NAT Function | | 293 | +-------+-------------+ | 294 | | | 295 +---------+---------------+ 296 | 297 | inside interface 298 | 299 | 301 Figure 2: Block Diagram of Internal NAT Operation 303 After learning the public IP address of its outer-most NAT, the STUN 304 client attempts to communicate with the STUN server embedded in that 305 outer-most NAT. The STUN client does this by first obtaining a 306 shared secret, over a TLS connection, to the NAT's public IP address 307 (192.0.2.1 in the figure above). After obtaining a shared secret, it 308 sends a STUN Binding Request to the NAT's public IP address. The NAT 309 will return a STUN Binding Response message including the XOR- 310 INTERNAL-ADDRESS attribute, which will indicate the IP address and 311 UDP port seen on the *internal* side of the NAT for that translation. 312 In the example above, the IP address and UDP port indicated in XOR- 313 INTERNAL-ADDRESS are the same as that used by the STUN client 314 (10.1.1.2/4193), which indicates there are no other NATs between the 315 STUN client and that outer-most NAT. 317 STUN Client NAT STUN Server 318 | | | 319 1. |-----TLS/TCP----------------------------->| } 320 2. |-----Shared Secret Request (TLS)--------->| } 321 3. |<----Shared Secret Response (TLS)---------| } normal STUN 322 4. |-----TCP connection closed--------------->| } behavior 323 5. |-----Binding Request (UDP)--------------->| } 324 6. |<----Binding Response (UDP)---------------| } 325 | | | 326 7. |-----TLS/TCP------------------>| | } 327 8. |--Shared Secret Request (TLS)->| | } 328 9. |<-Shared Secret Response (TLS)-| | } NAT Control 329 10. |--TCP connection closed------->| | } STUN Usage 330 11. |--Binding Request (UDP)------->| | } 331 12. |<-Binding Response (UDP)-------| | } 332 | | | 334 Figure 3: Communication Flow 336 In the call flow above, steps 1-6 are normal STUN behavior 337 [I-D.ietf-behave-rfc3489bis]: 339 1: STUN client initiates a TLS-over-TCP connection to its STUN 340 server on the Internet. 342 2: Using that connection, the STUN client sends Shared Secret 343 Request to that STUN server. 345 3: Using that connection, the STUN server sends Shared Secret 346 Response. This contains the STUN username the client should use 347 for subsequent queries to this STUN server, and the STUN password 348 that will be used to integrity-protect subsequent STUN messages 349 with this STUN server. 351 4: TCP connection is closed. 353 5: STUN client sends UDP Binding Request to its STUN server on the 354 Internet, using the STUN username obtained from that STUN server 355 (from step 3). 357 6: STUN server responds with UDP Binding Response, integrity 358 protected with the STUN password (from step 3). The STUN client 359 now knows the public IP address of its outer-most NAT. This is 360 used in the next step. 362 The next steps are the additional steps performed by a STUN client 363 that has implemented the NAT Control STUN Usage: 365 7: STUN client initiates a TLS-over-TCP connection to the STUN 366 server embedded in its outer-most NAT. 368 8: Using that connection, the STUN client sends Shared Secret 369 Request to that STUN server. 371 9: Using that connection, the STUN server sends Shared Secret 372 Response. This contains the STUN username the client should use 373 for subsequent queries to this STUN server, and the STUN 374 password that will be used to integrity-protect subsequent STUN 375 messages with this STUN server. 377 10: TCP connection is closed. 379 11: STUN client sends UDP Binding Request to the STUN server 380 embedded in its outer-most NAT, using the STUN username obtained 381 from that STUN server (from step 10). 383 12: STUN server responds with UDP Binding Response, integrity 384 protected with the STUN password (from step 10). 386 The response obtained in the message 12 contains the XOR-MAPPED- 387 ADDRESS attribute which will have the same value as when the STUN 388 server on the Internet responded (in step 6). The STUN client can 389 perform steps 11-12 for any new UDP communication (e.g., for every 390 new phone call), without needing to repeat steps 1-10. This meets 391 the desire to reduce chattiness. 393 The response obtained in message 12 will also contain the XOR- 394 INTERNAL-ADDRESS, which allows the STUN client to repeat steps 7-12 395 in order to query or control those on-path NATs between itself and 396 its STUN server on the Internet. This is described in detail in 397 section Section 5.1.1. This functionality meets the need to optimize 398 traffic between nested NATs, without requiring configuration of 399 intermediate STUN servers. 401 The STUN client can request each NAT to increase the binding 402 lifetime, as described in Section 6.1. The STUN client receives 403 positive confirmation that the binding lifetime has been extended, 404 allowing the STUN client to significantly reduces its NAT keepalive 405 traffic. Additionally, as long as the NAT complies with [RFC4787], 406 the STUN client's keepalive traffic need only be sent to the outer- 407 most NAT's IP address. This functionality meets the need to reduce 408 STUN's chattiness. 410 5.1.1. Nested NATs 412 Nested NATs are controlled individually. The nested NATs are 413 discovered, from outer-most NAT to the inner-most NAT, using the XOR- 414 INTERNAL-ADDRESS attribute. 416 The following diagram shows how a STUN client iterates over the NATs 417 to communicate with all of the NATs in the path. First, the STUN 418 client would learn the outer-most NAT's IP address by performing the 419 steps above. In the case below, however, the IP address and UDP port 420 indicated by the XOR-INTERNAL-ADDRESS will not be the STUN client's 421 own IP address and UDP port -- rather, it's the IP address and UDP 422 port on the *outer* side of the NAT-B -- 10.1.1.2. 424 Because of this, the STUN client repeats the procedure and sends 425 another STUN Binding Request to that newly-learned address (the 426 *outer* side of NAT-B). NAT-B will respond with a STUN Binding 427 Response containing the XOR-INTERNAL-ADDRESS attribute, which will 428 match the STUN client's IP address and UDP port. The STUN client 429 knows there are no other NATs between itself and NAT-B, and finishes. 431 The following figure shows two nested NATs: 433 +------+ +--------+ +--------+ 434 | 192.168.1.2 | 10.1.1.2 | 192.0.2.1 +-----------+ 435 | STUN +------+ NAT-B +-----+ NAT-A +------+STUN Server| 436 |Client| 192.168.1.1 | 10.1.1.1 | +-----------+ 437 +------+ +--------+ +--------+ 439 Figure 4: Two nested NATs with embedded STUN servers 441 The message flow with two nested NATs is shown below: 443 STUN Client NAT-B NAT-A STUN Server 444 | | | | 445 1. |-----TLS/TCP----------------------------->| } 446 2. |-----Shared Secret Request (TLS)--------->| } 447 3. |<----Shared Secret Response (TLS)---------| } normal STUN 448 4. |-----TCP connection closed--------------->| } behavior 449 5. |-----Binding Request (UDP)--------------->| } 450 6. |<----Binding Response (UDP)---------------| } 451 | | | | 452 7. |-----TLS/TCP------------------>| | } 453 8. |--Shared Secret Request (TLS)->| | } 454 9. |<-Shared Secret Response (TLS)-| | } 455 10. |--TCP connection closed------->| | } 456 11. |--Binding Request (UDP)------->| | } 457 12. |<-Binding Response (UDP)-------| | } NAT Control 458 | | | | } STUN Usage 459 13. |-----TLS/TCP--------->| | | } 460 14. |--Sh. Sec. Req (TLS)->| | | } 461 15. |<-Sh. Sec. Resp (TLS)-| | | } 462 16. |-TCP conn. closed---->| | | } 463 17. |--Binding Req (UDP)-->| | | } 464 18. |<-Binding Resp (UDP)--| | | } 465 | | | | 467 Figure 5: Message Flow for Outside-In with Two NATs 469 Once a shared secret has been obtained with each of the on-path NATs, 470 the STUN client no longer needs the TLS/TCP connection -- all 471 subsequent bindings for individual UDP streams (that is, for each 472 subsequent call) are obtained by just sending a Binding Request to 473 each of the NATs. By sending a Binding Request to both NAT-A and 474 NAT-B, the STUN client has the opportunity to optimize the packet 475 flow if their UDP peer is also behind the same NAT. 477 5.1.2. XOR-INTERNAL-ADDRESS Attribute 479 This attribute MUST be present in a Binding Response and may be used 480 in other responses as well. This attribute is necessary to allow a 481 STUN client to 'walk backwards' and communicate directly with all of 482 the STUN-aware NATs along the path. 484 The format of the XOR-INTERNAL-ADDRESS attribute is: 486 0 1 2 3 487 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 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 |x x x x x x x x| Family | X-Port | 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 | X-Address (32 bits or 128 bits) | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 6: XOR-INTERNAL-ADDRESS Attribute 496 The meaning of Family, X-Port, and X-Address are exactly as in 497 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 498 address family (IPv4 or IPv6). 500 5.1.3. Interacting with Legacy NATs 502 There will be cases where the STUN client attempts to communicate 503 with an on-path NAT which does not support the outside-in usage 504 described in Section 5.1. There are two cases: 506 o the NAT does not run a STUN server on its public interface (this 507 will be the most common) 509 o the NAT does run a STUN server on its public interface, but 510 doesn't return the XOR-INTERNAL-ADDRESS attribute defined in this 511 document 513 In both cases the optimizations described in this section won't be 514 available to the STUN client. This is no worse than the condition 515 today. This allows incremental upgrades of applications and NATs 516 that implement the technique described in this document. In such a 517 situation, the STUN client might implement the inside-out technique, 518 described in Section 5.2. 520 5.2. Inside-Out 522 [[Discussion Point: This is being included as a discussion item. 523 Traditional traceroute provides similar functionality, and in many 524 cases traceroute survives traversing over a NAT that doesn't support 525 STUN Control. However, traceroute has significant disadvantages 526 (induces a load on intermediate devices to return ICMP error 527 messages, and those ICMP messages are routinely or inadvertently 528 filtered). Unlike the Inside-Out technique described below, 529 traceroute doesn't rely on the default route.]] 531 The STUN client sends a STUN request to UDP/3478 of the IP address of 532 its default router. If there is a STUN server listening there, it 533 will respond, and will indicate its default route via the new 534 DEFAULT-ROUTE attribute. With that information, the STUN client can 535 discover the next-outermost NAT by repeating the procedure. 537 5.2.1. DEFAULT-ROUTE Attribute 539 The DEFAULT-ROUTE attribute contains the XOR'd default route, which 540 is useful for finding the next-outer device. 542 The format of the DEFAULT-ROUTE attribute is: 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | X-Address (32 bits) | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 Figure 7: DEFAULT-ROUTE Attribute 552 The meaning of X-Address is exactly as in 553 [I-D.ietf-behave-rfc3489bis]. 555 5.3. Tagging 557 The Outside-In discovery technique (Section 5.1) uses the public IP 558 address of the NAT to find the outer-most NAT that supports STUN 559 Control. Firewalls do not normally put their IP address into 560 packets, so a different technique is needed to identify firewalls. 562 To discover an on-path firewall, the PLEASE-TAG attribute is used 563 with a normal STUN Binding Request usage. A firewall sees the normal 564 Binding Request usage (a STUN packet sent to UDP/3478) with the 565 PLEASE-TAG attribute. When the firewall sees the associated Binding 566 Response, the firewall appends a TAG attribute as the last attribute 567 of the Binding Response. This TAG attribute contains the firewall's 568 management IP address and UDP port. Each on-path firewall would be 569 able to insert its own TAG attribute. In this way, the STUN Response 570 would contain pointer to each of the on-path firewalls between the 571 client and that STUN server. 573 Note: Tagging is similar to how NSIS [I-D.ietf-nsis-nslp-natfw], 574 TIST [I-D.shore-tist-prot], and NLS [I-D.shore-nls-tl] function. 576 Discussion Point: Tagging would also be useful for the 577 Connectivity Check usage (which is used by ICE), especially 578 considering that a different firewall may be traversed for media 579 than for the initial Binding Discovery usage. In such a 580 situation, the new on-path firewall's policy might not allow a 581 binding request to leave the network or allow a binding response 582 to return. In this case, the firewall would need to indicate its 583 presence to the STUN client in another way. An ICMP error message 584 may be appropriate, and an ICMP extension [RFC4884] could indicate 585 the firewall is controllable. 587 This figure shows how tagging functions. 589 STUN Client firewall STUN Server 590 | | | 591 1. |--Binding Request->|------------------>| 592 2. | |<-Binding Response-| 593 3. | [inserts tag] | 594 4. |<-Binding Response-| | 595 5. [firewall discovered] | | 597 Figure 8: Tagging Message Flow 599 1. Binding Request, containing PLEASE-TAG attribute, is sent to the 600 IP address of the STUN server. This is seen by the firewall, and 601 the firewall remembers the STUN transaction id, and permits the 602 STUN Binding Request packet. 604 2. The STUN Binding Response packet is seen by the firewall. 606 3. The firewall inserts the TAG attribute, which contains the 607 firewall's management address. 609 4. The firewall sends the (modified) STUN Binding Response towards 610 the STUN client. 612 5. The STUN client has now discovered the firewall, and can query it 613 or control it. 615 5.3.1. PLEASE-TAG Attribute 617 If a STUN client wants to discover on-path firewalls, it MUST include 618 this attribute in its Binding Response when performing the Binding 619 Discovery usage. 621 STUN servers are not expected to understand this attribute; if they 622 return this attribute as an unknown attribute, it does not affect the 623 operation described in this document. 625 The format of the PLEASE-TAG attribute is: 627 0 1 2 3 628 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 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 |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| 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 Figure 9: PLEASE-TAG Attribute 635 The 3-bit Mechanism field indicates the control mechanism desired. 636 Currently, the only defined mechanism is STUN Control, and is 637 indicated with all zeros. The intent of this field is to allow 638 additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM). 640 5.3.2. TAG Attribute 642 The TAG attribute contains the XOR'd management transport address of 643 the middlebox (typically a firewall, although a NAT may find this 644 technique useful as well). 646 A middlebox MUST append this attribute as the last attribute of a 647 STUN response, and only if the associated STUN request (with the same 648 transaction-id) contained the PLEASE-TAG attribute. 650 The format of the TAG attribute is: 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 |Mech.|x x x x x| Family | X-Port | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | X-Address (32 bits or 128 bit) | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 Figure 10: TAG Attribute 662 The 3-bit Mechanism field indicates the control mechanism supported 663 on the described port. Currently, the only defined mechanism is STUN 664 Control, and is indicated with 0x0. The intent of this field is to 665 allow additional control mechanisms (e.g., UPnP, Bonjour, MIDCOM). 667 The meaning of Family, X-Port, and X-Address are exactly as in 668 [I-D.ietf-behave-rfc3489bis]. The length of X-Address depends on the 669 address family (IPv4 or IPv6). 671 6. Query and Control 673 This section describes how to use STUN to query and control a NAT 674 that was discovered using the technique described in Section 5. 676 6.1. REFRESH-INTERVAL Attribute 678 In a STUN request, the REFRESH-INTERVAL attribute indicates the 679 number of milliseconds that the client wants the NAT binding (or 680 firewall pinhole) to be opened. In a STUN response, the same 681 attribute indicates the length of time of that NAT binding (or 682 firewall pinhole). 684 REFRESH-INTERVAL is specified as an unsigned 32 bit integer, and 685 represents an interval measured in milliseconds (thus the maximum 686 value is approximately 50 days). This attribute can be present in 687 Binding Requests and in Binding Responses. In a request, the value 688 0xFFFF means it's a query and the refresh interval isn't actually 689 changed. 691 6.2. Client Procedures 693 After discovering on-path NATs and firewalls, the STUN client begins 694 querying and controlling those devices. The STUN client first 695 performs the Shared Secret Usage (as described in 696 [I-D.ietf-behave-rfc3489bis]) with the NAT or firewall it discovered. 697 After performing that usage, the STUN client now has a STUN USERNAME 698 and PASSWORD. The username and password are used, thereafter, for 699 all subsequent messages between the STUN client and this NAT's STUN 700 server. This procedure might be done, for example, when the STUN 701 client first initializes such as upon bootup or initialization of the 702 application. 704 If subsequent messages from that STUN server fail authentication, the 705 STUN client MUST re-obtain its IP address from a public STUN server, 706 not from its outer-most NAT (see section Section 9.3). 708 To modify an existing NAT mapping's attributes, or to request a new 709 NAT mapping for a new UDP port, the STUN client can now send a STUN 710 Binding Request to the IP address of address in its outer-most NAT's 711 STUN UDP port (3478). The NAT's STUN server will respond with a STUN 712 Binding Response containing an XOR-MAPPED-ADDRESS attribute (which 713 points at the NAT's public IP address and port -- just as if the STUN 714 Binding Request had been sent to a STUN server on the public 715 Internet) and an XOR-INTERNAL-ADDRESS attribute (which points to the 716 source IP address and UDP port the packet STUN Binding Request packet 717 had prior to being NATted). 719 6.3. Server Procedures 721 The server should listen for STUN Shared Secret Requests and STUN 722 Binding Requests on the STUN UDP and TCP ports (UDP/3478, TCP/3478) 723 on its public IP address(es) and its private IP address(es), and 724 accept such STUN packets from hosts connected to its private 725 interface(s). STUN Binding Requests which arrived from its public 726 interface(s) MAY be handled as if the server isn't listening on that 727 port (e.g., return an ICMP error) -- this specification does not need 728 them. 730 After receiving a STUN Shared Secret Request, the NAT follows the 731 procedures described in the Short-Term Usage section of 732 [I-D.ietf-behave-rfc3489bis]. The embedded STUN server MUST store 733 that username and password so long as any NAT bindings, created or 734 adjusted with that same STUN username, have active mappings on the 735 NAT, and for 60 seconds thereafter (to allow the STUN client to 736 obtain a new binding). 738 After receiving a STUN Binding Request containing the REFRESH- 739 INTERVAL attribute, the server SHOULD authenticate the request using 740 the USERNAME attribute and the previously-shared STUN password (this 741 is to defend against resource starvation attacks, see Section 9.1). 742 If authenticated, the new binding's lifetime can be maximized against 743 the NAT's configured sanity check and the lifetime indicated in the 744 REFRESH-INTERVAL attribute of the STUN Binding Response. 746 In addition to its other attributes, the Binding Response MUST 747 contain the XOR-MAPPED-ADDRESS and XOR-INTERNAL-ADDRESS attributes. 748 The XOR-MAPPED-ADDRESS contains the public IP address and UDP port 749 for this binding, which is shared with the intended peer. The XOR- 750 INTERNAL-ADDRESS contains the IP address and UDP port of the STUN 751 Binding Request prior to the NAT translation, which is used by the 752 STUN client to walk backwards through nested NATs (Section 5.1) 754 For example, looking at Figure 1, the XOR-INTERNAL-ADDRESS is the 755 IP address and UDP port prior to the NAPT operation. If there is 756 only one NAT, as shown in Figure 1, XOR-INTERNAL-ADDRESS would 757 contain the STUN client's own IP address and UDP port. If there 758 are multiple NATs, XOR-INTERNAL-ADDRESS would indicate the IP 759 address of the next NAT (that is, the next NAT closer to the STUN 760 client). Iterating over this procedure allows the STUN client to 761 find all of the NATs along the path. 763 7. Benefits 765 7.1. Simple Security Model 767 Unlike other middlebox control techniques which have relatively 768 complex security models because a separate control channel is used, 769 STUN Control's is simple. It's simple because only the flow being 770 used can be controlled (e.g., have its NAT timeout queried or 771 extended). Other flows cannot be created, queried, or controlled via 772 STUN Control. 774 7.2. Incremental Deployment 776 NAT Control can be incrementally deployed. If the outer-most NAT 777 does not support it, the STUN client behaves as normal. In this 778 case, the STUN client might benefit from attempting inside-out 779 procedure described in Section 5.2, and still gain some 780 optimizations. Where the outer-most STUN NAT does support it, the 781 STUN client can gain some significant optimizations as described in 782 the following sections. 784 Likewise, there is no change required to applications if NATs are 785 deployed which support NAT Control: such applications will be 786 unaware of the additional functionality in the NAT, and will not be 787 subject to any worse security risks due to the additional 788 functionality in the NAT. 790 7.3. Optimize SIP-Outbound 792 In sip-outbound [I-D.ietf-sip-outbound], the SIP proxy is also the 793 STUN server. STUN Control as described in this document enables two 794 optimizations of SIP-Outbound's keepalive mechanism: 796 1. STUN keepalive messages need only be sent to the outer-most NAT, 797 rather than across the access link to the SIP proxy, which vastly 798 reduces the traffic to the SIP proxy, and; 800 2. all of the on-path NATs can explicitly indicate their timeouts, 801 reducing the frequency of keepalive messages. 803 7.4. Optimize ICE 805 The NAT Control usage provides several opportunities to optimize ICE 806 [I-D.ietf-mmusic-ice], as described in this section. 808 7.4.1. Candidate Gathering 810 During its candidate gathering phase, an ICE endpoint normally 811 contacts a STUN server on the Internet. If an ICE endpoint discovers 812 that its outer-most NAT runs a STUN server, the ICE endpoint can use 813 the outer-most NAT's STUN server rather than using the STUN server on 814 the Internet. This saves access bandwidth and reduces the reliance 815 on the STUN server on the Internet -- the STUN server on the Internet 816 need only be contacted once -- when the ICE endpoint first 817 initializes. 819 7.4.2. Keepalive 821 ICE uses STUN Indications as its primary media stream keepalive 822 mechanism. This document enables two optimizations of ICE's 823 keepalive technique: 825 1. STUN keepalive messages need only be sent to the outer-most NAT, 826 rather than across the access link to the remote peer, and; 828 2. all of the on-path NATs can explicitly indicate their timeouts, 829 which allows reducing the keepalive frequency. 831 7.4.3. Learning STUN Servers without Configuration 833 ICE allows endpoints to have multiple STUN servers, but it is 834 difficult to configure all of the STUN servers in the ICE endpoint -- 835 it requires some awareness of network topology. By using the 'walk 836 backward' technique described in this document, all the on-path NATs 837 and their embedded STUN servers can be learned without additional 838 configuration. By knowing the STUN servers at each address domain, 839 ICE endpoints can optimize the network path between two peers. 841 For example, if endpoint-1 is only configured with the IP address of 842 the STUN server on the left, endpoint-1 can learn about NAT-B and 843 NAT-A. Utilizing the STUN server in NAT-A, endpoint-1 and endpoint-2 844 can optimize their media path so they make the optimal path from 845 endpoint-1 to NAT-A to endpoint-2: 847 +-------+ +-------+ +-------------+ 848 endpoint-1---| NAT-A +--+--+ NAT-B +-------| STUN Server | 849 +-------+ | +-------+ +-------------+ 850 | 851 endpoint-2 853 8. Limitations 855 8.1. Overlapping IP Addresses with Nested NATs 857 If nested NATs have overlapping IP address space, there will be 858 undetected NATs on the path. When this occurs, the STUN client will 859 be unable to detect the presence of NAT-A if NAT-A assigns the same 860 UDP port. For example, in the following figure, NAT-A and NAT-B are 861 both using 10.1.1.x as their 'private' network. 863 +------+ +--------+ +--------+ 864 | 10.1.1.2 | 10.1.1.2 | 192.0.2.1 865 | STUN +-------+ NAT-A +-----+ NAT-B +------ 866 |client| 10.1.1.1 | 10.1.1.1 | 867 +------+ +--------+ +--------+ 869 Figure 12: Overlapping Addresses with Nested NATs 871 When this situation occurs, the STUN client can only learn the outer- 872 most address. This isn't a problem -- the STUN client is still able 873 to communicate with the outer-most NAT and is still able to avoid 874 consuming access network bandwidth and avoid communicating with the 875 public STUN server. All that is lost is the ability to optimize 876 paths within the private network that has overlapped addresses. 878 Of course when such an overlap occurs the end host (STUN client) 879 cannot successfully establish bi-directional communication with hosts 880 in the overlapped network, anyway. 882 8.2. Address Dependent NAT on Path 884 In order to utilize the mechanisms described in this document, a STUN 885 Request is sent from the same source IP address and source port as 886 the original STUN Binding Discovery message, but is sent to a 887 different destination IP address -- it is sent to the IP address of 888 an on-path NAT. If there is an on-path NAT, between the STUN client 889 and the STUN server, with 'address dependent' or 'address and port- 890 dependent' mapping behavior (as described in section 4.1 of 891 [RFC4787]), that NAT will prevent a STUN client from taking advantage 892 of the technique described in this document. When this occurs, the 893 ports indicated by XOR-MAPPED-ADDRESS from the public STUN server and 894 the NAT's embedded STUN server will differ. 896 An example of such a topology is shown in the following figure: 898 +------+ +--------+ +--------+ 899 | STUN | | 10.1.1.2 | 192.0.2.1 900 |client+-----+ NAT-A +---+ NAT-B +------ 901 | | 10.1.1.1 | 10.1.1.1 | 902 +------+ +--------+ +--------+ 904 In this figure, NAT-A is a NAT that has address dependent mapping. 905 Thus, when the STUN client sends a STUN Binding Request to 192.0.2.1 906 on UDP/3478, NAT-A will choose a new public UDP port for that 907 communication. NAT-B will function normally, returning a different 908 port in its XOR-MAPPED-ADDRESS, which indicates to the STUN client 909 that a symmetric NAT exists between the STUN client and the STUN 910 server it just queried (NAT-B, in this example). 912 Figure 13: Address Dependant NAT on Path 914 Open issue: We could resolve this problem by introducing a new 915 STUN attribute which indicates the UDP port the STUN client wants 916 to control. However, this changes the security properties of NAT 917 Control, so this seems undesirable. 919 Open issue: When the STUN client detects this situation, should 920 we recommend it abandon the NAT Control usage, and revert to 921 operation as if it doesn't support the NAT Control usage? 923 8.3. Address Dependent Filtering 925 If there is an NAT along the path that has address dependent 926 filtering (as described in section 5 of [RFC4787]), and the STUN 927 client sends a STUN packet directly to any of the on-path NATs public 928 addresses, the address-dependent filtering NAT will filter packets 929 from the remote peer. Thus, after communicating with all of the on- 930 path NATs the STUN client MUST send a UDP packet to the remote peer, 931 if the remote peer is known. 933 Discussion: How many filter entries are in address dependent 934 filtering NATs? If only one, this does become a real limitation 935 if NATs are nested; if they're not nested, the outer-most NAT can 936 avoid overwriting its own address in its address dependent filter. 938 9. Security Considerations 940 This security considerations section will be expanded in a subsequent 941 version of this document. So far, the authors have identified the 942 following considerations: 944 9.1. Authorization and Resource Exhaustion 946 Only hosts that are 'inside' a NAT, which a NAT is already providing 947 services for, can query or adjust the timeout of a NAT mapping. 949 A malicious STUN client could ask for absurdly long NAT bindings 950 (days) for many UDP sessions, which would exhaust the resources in 951 the NAT. The same attack is possible (without considering this 952 document and without considering STUN or other UNSAF [RFC3424] NAT 953 traversal techniques) -- a malicious TCP client can open many TCP 954 connections, and keep them open, causing resource exhaustion in the 955 NAT. One way to thwart such an attack is to challenge the STUN 956 client with a nonce, which is already part of the STUN specification. 957 By doing this, a NAT can provide DoS protection similar to what it 958 could do for TCP today. 960 9.2. Comparison to Other NAT Control Techniques 962 Like UPnP, Bonjour, and host-initiated MIDCOM, the STUN usage 963 described in this document allows a host to learn its public IP 964 address and UDP port mapping, and to request a specific lifetime for 965 that mapping. 967 However, unlike those technologies, the NAT Control usage described 968 in this document only allows each UDP port on the host to create and 969 adjust the mapping timeout of its own NAT mappings. Specifically, an 970 application on a host can only adjust the duration of a NAT bindings 971 for itself, and not for another application on that same host, and 972 not for other hosts. This provides security advantages over other 973 NAT control mechanisms where malicious software on a host can 974 surreptitiously create NAT mappings to another application or to 975 another host. 977 9.3. Rogue STUN Server 979 As described in Section 7, a STUN client can learn its outer-most NAT 980 runs an embedded STUN server. However, without the STUN client's 981 knowledge, the outer-most NAT may acquire a new IP address. This 982 could occur when the NAT moves to a new mobile network or its DHCP 983 lease expires. When the NAT acquires a new IP address, the STUN 984 client will send a STUN Binding Request to the NAT's prior public IP 985 address, which will be routed to the NAT's previous address. 987 If an attacker runs a rogue STUN server on that address, the attacker 988 has effectively compromised the STUN server (the attacked described 989 in section 12.2.1 of [RFC3489]). The attacker will send STUN Binding 990 Responses indicating his IP address, which will be indistinguishable, 991 to the STUN client, from the behavior of the legitimate STUN server. 993 To defend against this attack, the STUN client and STUN server obtain 994 a short-term password as described in section Section 6.2. 996 10. IANA Considerations 998 This section registers one new STUN attribute per the procedures in 999 [I-D.ietf-behave-rfc3489bis]: 1001 Mandatory range: 1002 0x0028 XOR-INTERNAL-ADDRESS 1004 Optional range: 1005 0x80.. PLEASE-TAG 1006 0x80.. TAG 1008 11. Acknowledgements 1010 Thanks to Remi Denis-Courmont, Markus Isomaki, Cullen Jennings, and 1011 Philip Matthews for their suggestions which have improved this 1012 document. 1014 12. References 1016 12.1. Normative References 1018 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1019 Requirement Levels", BCP 14, RFC 2119, March 1997. 1021 [I-D.ietf-behave-rfc3489bis] 1022 Rosenberg, J., "Session Traversal Utilities for (NAT) 1023 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 1024 progress), March 2007. 1026 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1027 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1028 RFC 4787, January 2007. 1030 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1031 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1032 Through Network Address Translators (NATs)", RFC 3489, 1033 March 2003. 1035 12.2. Informational References 1037 [I-D.ietf-behave-turn] 1038 Rosenberg, J., "Obtaining Relay Addresses from Simple 1039 Traversal Underneath NAT (STUN)", 1040 draft-ietf-behave-turn-03 (work in progress), March 2007. 1042 [UPnP] UPnP Forum, "Universal Plug and Play", 2000, 1043 . 1045 [Bonjour] Apple Computer, "Bonjour", 2005, 1046 . 1048 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1049 A. Rayhan, "Middlebox communication architecture and 1050 framework", RFC 3303, August 2002. 1052 [I-D.ietf-mmusic-ice] 1053 Rosenberg, J., "Interactive Connectivity Establishment 1054 (ICE): A Methodology for Network Address Translator (NAT) 1055 Traversal for Offer/Answer Protocols", 1056 draft-ietf-mmusic-ice-15 (work in progress), March 2007. 1058 [I-D.ietf-sip-outbound] 1059 Jennings, C. and R. Mahy, "Managing Client Initiated 1060 Connections in the Session Initiation Protocol (SIP)", 1061 draft-ietf-sip-outbound-08 (work in progress), March 2007. 1063 [I-D.ietf-nsis-nslp-natfw] 1064 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1065 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in 1066 progress), March 2007. 1068 [RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, 1069 "Extended ICMP to Support Multi-Part Messages", RFC 4884, 1070 April 2007. 1072 [I-D.shore-tist-prot] 1073 Shore, M., "The TIST (Topology-Insensitive Service 1074 Traversal) Protocol", draft-shore-tist-prot-00 (work in 1075 progress), May 2002. 1077 [I-D.shore-nls-tl] 1078 Shore, M., "Network-Layer Signaling: Transport Layer", 1079 draft-shore-nls-tl-04 (work in progress), May 2007. 1081 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1082 Self-Address Fixing (UNSAF) Across Network Address 1083 Translation", RFC 3424, November 2002. 1085 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 1086 Middlebox Configuration (SIMCO) Protocol Version 3.0", 1087 RFC 4540, May 2006. 1089 Authors' Addresses 1091 Dan Wing 1092 Cisco Systems 1093 170 West Tasman Drive 1094 San Jose, CA 95134 1095 USA 1097 Email: dwing@cisco.com 1099 Jonathan Rosenberg 1100 Cisco Systems 1101 600 Lanidex Plaza 1102 Parsippany, NJ 07054 1103 USA 1105 Email: jdrosen@cisco.com 1107 Full Copyright Statement 1109 Copyright (C) The IETF Trust (2007). 1111 This document is subject to the rights, licenses and restrictions 1112 contained in BCP 78, and except as set forth therein, the authors 1113 retain all their rights. 1115 This document and the information contained herein are provided on an 1116 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1117 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1118 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1119 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1120 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1121 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1123 Intellectual Property 1125 The IETF takes no position regarding the validity or scope of any 1126 Intellectual Property Rights or other rights that might be claimed to 1127 pertain to the implementation or use of the technology described in 1128 this document or the extent to which any license under such rights 1129 might or might not be available; nor does it represent that it has 1130 made any independent effort to identify any such rights. Information 1131 on the procedures with respect to rights in RFC documents can be 1132 found in BCP 78 and BCP 79. 1134 Copies of IPR disclosures made to the IETF Secretariat and any 1135 assurances of licenses to be made available, or the result of an 1136 attempt made to obtain a general license or permission for the use of 1137 such proprietary rights by implementers or users of this 1138 specification can be obtained from the IETF on-line IPR repository at 1139 http://www.ietf.org/ipr. 1141 The IETF invites any interested party to bring to its attention any 1142 copyrights, patents or patent applications, or other proprietary 1143 rights that may cover technology that may be required to implement 1144 this standard. Please address the information to the IETF at 1145 ietf-ipr@ietf.org. 1147 Acknowledgment 1149 Funding for the RFC Editor function is provided by the IETF 1150 Administrative Support Activity (IASA).