idnits 2.17.1 draft-shore-nat-reachability-00.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 3979, Section 5, paragraph 3 on line 585. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 8) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 14 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (September 2004) is 7161 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) -- Looks like a reference, but probably isn't: '1' on line 36 == Unused Reference: 'Jennings' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'Rosenberg' is defined on line 544, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Jasomi' == Outdated reference: A later version (-02) exists of draft-jennings-midcom-stun-results-00 -- Possible downref: Normative reference to a draft: ref. 'Jennings' -- Possible downref: Normative reference to a draft: ref. 'Moskowitz' -- Possible downref: Non-RFC (?) normative reference: ref. 'NSIS' ** Downref: Normative reference to an Experimental RFC: RFC 3103 ** Downref: Normative reference to an Informational RFC: RFC 3303 ** Downref: Normative reference to an Informational RFC: RFC 3424 ** Downref: Normative reference to an Informational RFC: RFC 3467 ** Obsolete normative reference: RFC 3489 (Obsoleted by RFC 5389) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ridgeway' -- No information found for draft-rosenberg- - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'Rosenberg' Summary: 16 errors (**), 0 flaws (~~), 8 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Melinda Shore 3 draft-shore-nat-reachability-00.txt Cisco Systems 4 March 2004 5 Expires September 2004 7 Establishing Reachability Behind NATs 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other docu- 22 ments at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Status of this Memo 34 This document is an Internet-Draft and is in full conformance with 35 all provisions of Section 10 of RFC2026 [1]. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 42 Internet-Drafts are draft documents valid for a maximum of six 43 months and may be updated, replaced, or obsoleted by other docu- 44 ments at any time. It is inappropriate to use Internet-Drafts as 45 reference material or to cite them other than as "work in 46 progress." 48 The list of current Internet-Drafts can be accessed at 49 http://www.ietf.org/ietf/1id-abstracts.txt 51 The list of Internet-Draft Shadow Directories can be accessed at 52 http://www.ietf.org/shadow.html. 54 Abstract 56 One of the most persistent, difficult problems introduced with NATs 57 is voluntary reachability -- a NATted device making itself avail- 58 able to the public internet. This paper is an overview of the cur- 59 rent status of reachability, a decomposition of the problem and a 60 proposal for going forward. 62 1. Introduction 64 NAT traversal has been recognized for some time to be a significant 65 problem in environments in which session-oriented protocols, like 66 SIP and H.323, are used, and in which endpoints wish to be reach- 67 able despite being NATted. It should be noted that while unreacha- 68 bility was not an original goal of NAT, NAT is commonly used as a 69 security mechanism specifically for inhibiting reachability. 71 This paper argues that the problem of reachability in the presence 72 of NATs needs to be considered as two distinct problems, and intro- 73 duces an approach for solving the problem. 75 2. Core problems 77 There are two problems to be solved in order to provide reachabil- 78 ity behind NATs. The first is the problem of obtaining a public 79 presence, and the second is the problem of advertising that pres- 80 ence. 82 2.1. Obtaining a public presence 84 NAT currently works by implication. A NAT device detects a new 85 outbound stream and creates a mapping between the internal, private 86 address and an external, routable address. That is to say that 87 rather than having an endpoint explicitly ask the NAT for a mapping 88 to a reachable address, the NAT infers when it should act based on 89 somewhat crude policy. Over the past several years there has been 90 growing recognition of a need to make the process of obtaining a 91 public presence explicit. An endpoint or its proxy should be able 92 to make a direct request for a NAT table mapping and learn the 93 results (i.e. the external port/address/protocol tuple). This 94 would have multiple advantages: 1) no more guesswork, 2) explicit 95 requests would allow for the possibility of "wildcarding," to allow 96 more than one external host to reach the device behind the NAT, and 97 3) it would be possible to make additional policy requests, includ- 98 ing authorization based on authenticated identity and other policy 99 elements. Several different approaches have been developed, and 100 these are discussed below. 102 2.1.1. Discovery 104 This approach does not make an explicit request directly to the 105 NAT, but relies on request by implication combined with technology 106 to discover the external address that the NAT assigned (referred to 107 in some quarters as "Unilateral Self-Address Fixing," or UNSAF 108 [RFC3424]). The protocol standardized by the IETF to do self- 109 address discovery is STUN [RFC3489]. While the protocol is very 110 useful for common cases encountered in voice over IP applications, 111 it should be noted that it will not work for TCP or for symmetric 112 NATs. Whether or not it is useful for establishing reachability is 113 completely dependent on the type of NAT the endpoint sits behind, 114 but in the general case it will not be. 116 2.1.2. Off-path signaling requests 118 This is the most common request model at the moment, and is essen- 119 tially modeled on a client-server relationship. An endpoint or its 120 proxy "knows" the location of a NAT and sends a request for an 121 address mapping directly to the NAT. While it suffers from a lack 122 of robustness in the face of topological complexity, it is probably 123 the best approach to take to establish general reachability. In 124 the general case, when a device makes itself available to be con- 125 tacted by another party (say, in a VoIP call or peer-to-peer appli- 126 cation), it may not know in advance who will be contacting it, or 127 it may want to be reachable by more than one party or, indeed, 128 everybody. The preference for off-path signaling in this scenario 129 is discussed below, in the discussion of on-path signaling. 131 Examples of off-path NAT request protocols include midcom 132 [RFC3303], Universal Plug and Play (UPnP), and RSIP [RFC3103]. It 133 should be mentioned that RSIP is also a relaying protocol (see 134 below). 136 2.1.3. On-path signaling requests 138 On-path signaling uses an RSVP-like [RFC2205] approach to locating 139 and communicating with network devices. A request is sent into the 140 network, from an endpoint towards another endpoint with which it 141 wishes to establish connectivity, and network devices along the 142 path may intercept the request and act on it (or not). Routing is 143 handled by normal network-layer mechanisms and device location is 144 implicit in the sending of the request. 146 While this approach does not have an established track record there 147 are several projects underway to create new on-path signaling pro- 148 tocols, and at the moment there is considerable momentum behind it. 149 The IETF has chartered the NSIS working group [NSIS], and there are 150 proprietary efforts outside the IETF. 152 While on-path signaling has several considerable advantages over an 153 off-path approach, there is one scenario in which it cannot be 154 used, and that is when the endpoint needs to make a request of a 155 NAT that is not path-oriented. For example, when placing a tele- 156 phone call there is a calling party and a called party. In this 157 case the calling party would send an on-path signaling request 158 towards the called party, and it would be intercepted and acted 159 upon by NATs the request traversed en-route. Obviously, this 160 approach requires a destination address for the request. (If the 161 request were addressed directly to a NAT, it would become an 162 instance of off-path signaling). 164 In situations in which the goal is to establish general reachabil- 165 ity, the endpoint must communicate directly with the NAT and 166 request what is essentially a wildcarded address mapping (traffic 167 from "any" outside address/port pair arriving here would be for- 168 warded to a single "inside" address/port pair). 170 2.1.4. Relays 172 Relays are probably the most common solution to the problem of pro- 173 viding reachability to NATted devices. There are several products 174 on the market with specialized support for VoIP, such as the ones 175 provided by Ridgeway Systems [Ridgeway] and Jasomi Networks 176 [Jasomi]. These are proprietary technologies. 178 Relays provide a mechanism for creating reachability by placing a 179 device on the outside of the NAT and having it forward traffic to 180 an endhost by encapsulating it or passing it through a pinhole that 181 was created by having the NATted device initiate an outbound 182 connection to the external relay device. 184 The only standardized relaying technology designed to provide 185 reachability for devices behind NATs is Realm-Specific IP (rsip) 186 [RFC3103]. Unlike the proprietary approaches mentioned above, RSIP 187 puts the "outside" end of the relay on the NAT device itself. 188 Traffic is encapsulated and passed to the internal endpoint. There 189 is also some interest within the IETF in publishing TURN [Rosen- 190 berg], another relaying protocol. 192 Relays can work either through explicit requests, as is the case 193 with RSIP, or through stateful inspection/traffic intercept. The 194 latter is the more common case, since it does not require the 195 replacement of network equipment and because major network equip- 196 ment vendors have been slow to go to this approach. Relays intro- 197 duce performance problems, both in terms of tandeming and queueing 198 delay, and in terms of encapsulation overhead. They also provide 199 the means to skirt network edge security policy, providing only 200 very crude policy parameters (the address/port pair for the relay) 201 for allowing or denying traffic. 203 2.2. Findability 205 Acquiring a reachable address is not sufficient for becoming reach- 206 able in practice. Peers need to know what that address is. 208 Traditionally, the mechanism for contacting specific applications 209 on specific hosts has relied on the use of static, publicly- 210 routable IP addresses and the use of "well-known" ports. However, 211 in the presence of NATs endpoint addresses are no longer publicly 212 routable, and when NAT workarounds are used to acquire a publicly- 213 routable address/port tuple, it is almost certainly the case that 214 the port will not be at the expected well-known location. That is 215 to say that among the things that NAT breaks is the historic use of 216 static port locations. 218 In VoIP and other session-oriented protocols, the address of the 219 data streams is provided by means of signaling. Endpoints tell 220 each other explicitly what addresses and ports to use for media 221 traffic, after having acquired a routable address using one of the 222 mechanisms described above. The more difficult problem is how to 223 establish the signaling streams, but it is commonly the case with 224 these applications that the signaling streams are mediated by a 225 centralized server, which is already publicly reachable. However, 226 in a peer-to-peer environment in which signaling is not mediated, 227 the problems of acquiring a public presence and then advertising 228 that public presence remain. 230 The Domain Name System (DNS) [RFC1034] is the location service for 231 the internet. While Dynamic DNS [RFC2136] provides a mechanism for 232 dynamically updating endpoint addresses assigned by DHCP or other 233 non-static address assignment mechanisms, it really is not suitable 234 for per-stream updates, nor is DNS suitable for rapidly-changing 235 configurations. See [RFC3467] for a detailed discussion of the 236 role of DNS in a changing internet. 238 3. Proposal 240 While DNS is unsuitable as a general-purpose location database, it 241 can be used as a location service for stable internet services, 242 including other lookup services. This is accomplished through the 243 use of SRV records [RFC2782]. For example, a client wishing to 244 locate an LDAP server for the domain "example.com" would submit a 245 DNS query for a resource record of type "SRV" with the contents 246 "_ldap._tcp.example.com". DNS would return a record, if available, 247 providing the IP address and port number of example.com's LDAP 248 server. 250 We are proposing that an endpoint acquire a reachable address for a 251 particular service (say, SIP signaling) using midcom or a midcom- 252 like protocol, then register that address with a domain's LDAP 253 server. An external (to the NAT) peer trying to contact that end- 254 point would use DNS to locate the domain's LDAP server, then query 255 the LDAP server for the address and port at which the endpoint is 256 reachable. 258 This problem requires the use of an off-path signaling protocol, 259 since it is not path-oriented. The availability of routable source 260 and destination addresses is inherent in the notion of a path, and, 261 by definition of this problem, we do not have one in this case. 262 This is true even in cases where we wish to be reachable by only 263 one peer. 265 While we propose the use of midcom as the off-path signaling proto- 266 col, it is not the only protocol available. Even a relaying proto- 267 col could be used to establish an address, although this is not 268 recommended for security and policy reasons. 270 Also, we should note that while LDAP is the de facto standard local 271 directory service for the internet, a database or another local 272 directory service would serve instead. We are using LDAP for 273 illustrative purposes. 275 3.1. Reachability information elements 277 The directory entry consists of 279 o Address 281 o Port 283 o Transport protocol (TCP, UDP, SCTP, etc.) 285 o "Application" protocol (FTP, SIP, H.323, etc.) 287 o Name 289 as follows: 291 Address: 292 the reachable, or public address provided by the NAT 294 Port: 295 the reachable, or public port provided by the NAT 297 Transport protocol: 298 self-evident 300 Application protocol: 301 self-evident 303 Name: 304 the name being used as the basis for providing reachability, 305 or as the directory index. The value will depend on the 306 application. For example, in the case of an FTP or web 307 server, it may be a hostname. For a VoIP application, it may 308 be the name or a user, or another identifying string such as a 309 telephone number. It could also be a HIP host identifier 310 [Moskowitz]. 312 4. Use scenarios 313 (1) +-------+ 314 ------------------>| | 315 | | NAT | 316 | --------------| | 317 | | (2) | | 318 | V +-------+ 319 +----------+ 320 | Server | 321 +----------+ 322 | +---------------+ 323 |------------->| LDAP Server | 324 (3) +---------------+ 326 Figure 1 328 Figure 1 shows a server behind a NAT acquiring an address from the 329 NAT and registering it with the LDAP directory server. Message 1 330 is a request to the NAT for an address mapping. Message 2 is the 331 reply, and message 3 is a directory update containing the reachable 332 {address,port,protocol} tuple. 334 (1) 336 ------------------------------ 337 | | 338 V | 339 +------------+ (2) | 340 | DNS Server |----------- | 341 +------------+ | +----------+ 342 ----->| | 343 | Client | 344 -------| | 345 +-------------+ | (3) +----------+ 346 | LDAP Server |<------ | 347 +-------------+ | 348 ^ | 349 | | 350 ----------------------------- 351 (4) 353 Figure 2 355 Figure 2 shows a client finding the address for a server behind a 356 NAT. It first makes a DNS request for a SRV record for the domain 357 of interest (message 1) and receives a response in message 2. In 358 message 3 it then contacts the LDAP server at the address returned 359 by DNS with a query for the address and port information for the 360 server it is looking for, receiving a request in message 4. It can 361 then use that information to contact the server. 363 5. Security considerations 365 This mechanism introduces several new security exposures that would 366 not exist if the NATted devices were not, in fact, NATted. First, 367 the mechanism for acquiring an address may be vulnerable to a vari- 368 ety of attacks depending on the technology used. Those vulnerabil- 369 ities are addressed in documents describing those mechanisms and 370 are out of scope for this document. 372 There are two processes that are of interest to this document: 1) 373 registering a reachable address/port tuple with a directory, and 2) 374 querying the directory to find a reachable address. There are two 375 clear risks in the registration process. The first is false regis- 376 tration, or registering an illegitimate address. This attack 377 allows miscreants to redirect network communication so that, for 378 example, someone wishing to place a SIP call would receive not the 379 address of the party they are trying to call, but instead the 380 address of an attacker, who could then eavesdrop on or even mas- 381 querade as the called party. The second risk lies in unauthenti- 382 cated deregistration, which could be used to commit a denial-of- 383 service attack against a NATted device. In both cases the regis- 384 tration process requires that the registration/deregistration 385 request packets be authenticated and integrity protected. 387 The query process introduces the possibility of an attacker inject- 388 ing a spoofed response to a query, allowing the same sorts of 389 attacks as false registration (although it should be noted that DNS 390 responses are almost never authenticated in actual practice). To 391 protect against this attack, the responses from the directory must 392 be authenticated and integrity protected. 394 6. Infrastructure requirements and transition 396 As with all NAT workarounds, this proposal introduces additional 397 network elements, increasing network complexity and operating 398 costs. In this particular case the new elements are: 400 o A publicly-accessible LDAP server 402 o A midcom- (or similar) capable NAT 403 o Appropriate authentication technology 405 The domain's DNS server will need to provide an SRV RR for the 406 domain. 408 Additionally, clients and peers wishing to contact devices behind 409 NATs will need to know to request addressing information from a 410 domain's LDAP server, and hosts behind a NAT wishing to be reach- 411 able will need to be able to acquire a routable address from a NAT 412 (by supporting midcom, for example) and then register that address 413 with an LDAP server. 415 That's a lot to ask, and it's not currently possible to do the sort 416 of forklift upgrade of the internet, or even of an enterprise or 417 local service provider network, to make this all work at once. 418 What can be said about transitioning, however, is that as these 419 facilities are added incrementally to existing software and exist- 420 ing operational networks, NATted hosts would be no less reachable 421 than they are today. 423 7. Operational issues and reliability 425 Introducing additional network elements always introduces the like- 426 lihood of increased instability, and there is a tradeoff against 427 the gains from increased functionality. While there is great 428 demand for a mechanism to allow NATted devices to establish reacha- 429 bility and there is at this time no generalized mechanism (other 430 than what is being proposed here) for doing so, we think it is 431 worthwhile to discuss some of the sources of instability being 432 introduced. 434 The most obvious problem is that of maintaining consistent state. 435 The NATted device can crash, the LDAP server can crash, or the NAT 436 can crash, and any of these events might cause the shared state to 437 desynchronize. 439 Of these three events the possibility of the LDAP server crashing 440 is the least difficult to resynchronize. It may be down when a 441 client wishes to register its address, or it may be down when a 442 client wishes to deregister its address. If it is down and 443 unavailable for registration, the NATted device is effectively 444 unavailable. If it is down and unavailable for deregistration, the 445 reachable address may still be found even if the NATted device is 446 offline or unreachable. Both of these cases may be mitigated 447 through request retransmission (although the problem remains if the 448 LDAP server crashes and then the client crashes before a 449 deregistration request is accepted and acted upon; we recommend 450 timeouts on directory entries for this reason). 452 If the NATted device crashes it may lose state. In particular, it 453 may lose information about what addresses it has acquired from the 454 NAT. There are two possibilities for resynchronizing -- contact 455 the NAT, or contact the LDAP server. It may be the case that both 456 are required. The NAT should be contacted to find out what map- 457 pings are installed, assuming that the address acquisition protocol 458 permits it. The LDAP server should be contacted to find out what 459 directory entries have been installed, either to confirm that they 460 are there or to delete any that are installed if the NAT query 461 reveals that some or all of them are gone (note that a timeout on 462 directory entries may be sufficient to take care of this latter 463 issue). 465 If the NAT itself crashes it is almost certainly the case that the 466 requested NAT entries will be lost on reboot. In order to recover, 467 the device behind the NAT first needs to be able to detect that the 468 NAT crashed. It then needs to delete the existing directory entry 469 on the LDAP server, request a new reachable address from the NAT, 470 and install a new directory entry. 472 8. Conclusion 474 One of the most serious problems introduced by NATs is that it ren- 475 ders NATted devices essentially unreachable, breaking some of the 476 semantics of IP addressing. There have been several proposals and 477 work-arounds, but for the most part these have been specialized to 478 particular applications, unsound from a policy enforcement perspec- 479 tive, or just generally slap-dash. 481 Steve Deering once said that the answer to crud in the network is 482 not more crud in the network. It's hard to argue against that, but 483 it assumes the possibility of solving the problems introduced by 484 crud simply removing some of it. In practice, that may not be an 485 option. 487 Several different proposals for solving different aspects of NAT- 488 introduced problems have been put forward. Most of these have been 489 oriented towards one specific application, voice over IP. That is 490 not the only application having difficulty with NATs, however, or 491 with the more general problem of establishing reachability. We 492 feel that by breaking down the problem into its two component parts 493 and solving each of those parts using existing technology (say, 494 midcom and LDAP) we can provide a cleaner and more general approach 495 to solving the reachability problem. 497 9. References 499 [Jasomi] "Jasomi Networks Peering Point Solutions" 500 http://www.jasomi.com/solutions.html 502 [Jennings] Jennings, Cullen. "NAT Classification Results using STUN," 503 work in progress, February 2004. draft-jennings-midcom-stun- 504 results-00. 506 [Moskowitz] Moskowitz, R. et al. "Host Identity Protocol," work in 507 progress, February 2004. draft-moskowitz-hip-09. 509 [NSIS] "Next Steps in Signaling (nsis)" http://www.ietf.org/html.char- 510 ters/nsis-charter.html 512 [RFC1034] Mockapetris, P. "Domain Names -- Concepts and Facilities," 513 RFC 1034, November 1987. 515 [RFC2136] Vixie, P. et al. "Dynamic Updates in the Domain Name System 516 (DNS UPDATE)," RFC 2136, April 1997. 518 [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) � 519 Version 1 Functional Specification," RFC 2205, September 1997. 521 [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov. "A DNS RR for spec- 522 ifying the location of services (DNS SRV)," RFC 2782, February 523 2000. 525 [RFC3103] Borella, M. et al. "Realm Specific IP: Protocol Specifica- 526 tion," RFC 3103, October 2001. 528 [RFC3303] Srisuresh, P, et al. "Middlebox communication architecture 529 and framework," RFC 3303, August 2002. 531 [RFC3424] Daigle, L., ed. "IAB Considerations for UNilateral Self- 532 Address Fixing (UNSAF) Across Network Address Translation," RFC 533 3424, November 2002. 535 [RFC3467] Klensin, J. "Role of the Domain Name System (DNS)," RFC 3467, 536 February 2003. 538 [RFC3489] Rosenberg, J. et al. "STUN - Simple Traversal of User Data- 539 gram Protocol (UDP) Through Network Address Translators (NATs)," 540 RFC 3489, March 2003. 542 [Ridgeway] "IPFreedom" http://www.ridgewaysystems.com/products.aspx 544 [Rosenberg] Rosenberg, Jonathan, Mahy, Rohan, and Christian Huitema. 545 "Traversal Using Relay NAT (TURN)," work in progress, October 2003. 546 draft-rosenberg- midcom-turn-03. 548 10. Full copyright statement 550 Copyright (C) The Internet Society (2004). This document is sub- 551 ject to the rights, licenses and restrictions contained in BCP 78 552 and except as set forth therein, the authors retain all their 553 rights. 555 This document and the information contained herein are provided on 556 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP- 557 RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 558 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 559 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 560 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 561 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 563 11. Intellectual property 565 The IETF takes no position regarding the validity or scope of any 566 Intellectual Property Rights or other rights that might be claimed 567 to pertain to the implementation or use of the technology described 568 in this document or the extent to which any license under such 569 rights might or might not be available; nor does it represent that 570 it has made any independent effort to identify any such rights. 571 Information on the procedures with respect to rights in RFC docu- 572 ments can be found in BCP 78 and BCP 79. 574 Copies of IPR disclosures made to the IETF Secretariat and any 575 assurances of licenses to be made available, or the result of an 576 attempt made to obtain a general license or permission for the use 577 of such proprietary rights by implementers or users of this speci- 578 fication can be obtained from the IETF on-line IPR repository at 579 http://www.ietf.org/ipr. 581 The IETF invites any interested party to bring to its attention any 582 copyrights, patents or patent applications, or other proprietary 583 rights that may cover technology that may be required to implement 584 this standard. Please address the information to the IETF at ietf- 585 ipr@ietf.org. 587 Author's address 589 Melinda Shore 590 Cisco Systems 591 809 Hayts Road 592 Ithaca, NY 14850 593 USA 594 mshore@cisco.com