Internet Draft Melinda Shore draft-shore-nat-reachability-00.txt Cisco Systems March 2004 Expires September 2004 Establishing Reachability Behind NATs Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other docu- ments at any time. It is inappropriate to use Internet-Drafts as Shore [Page 1] Internet Draft Establishing Reachability March 2004 reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract One of the most persistent, difficult problems introduced with NATs is voluntary reachability -- a NATted device making itself avail- able to the public internet. This paper is an overview of the cur- rent status of reachability, a decomposition of the problem and a proposal for going forward. 1. Introduction NAT traversal has been recognized for some time to be a significant problem in environments in which session-oriented protocols, like SIP and H.323, are used, and in which endpoints wish to be reach- able despite being NATted. It should be noted that while unreacha- bility was not an original goal of NAT, NAT is commonly used as a security mechanism specifically for inhibiting reachability. This paper argues that the problem of reachability in the presence of NATs needs to be considered as two distinct problems, and intro- duces an approach for solving the problem. 2. Core problems There are two problems to be solved in order to provide reachabil- ity behind NATs. The first is the problem of obtaining a public presence, and the second is the problem of advertising that pres- ence. 2.1. Obtaining a public presence NAT currently works by implication. A NAT device detects a new outbound stream and creates a mapping between the internal, private address and an external, routable address. That is to say that rather than having an endpoint explicitly ask the NAT for a mapping to a reachable address, the NAT infers when it should act based on somewhat crude policy. Over the past several years there has been growing recognition of a need to make the process of obtaining a Shore [Page 2] Internet Draft Establishing Reachability March 2004 public presence explicit. An endpoint or its proxy should be able to make a direct request for a NAT table mapping and learn the results (i.e. the external port/address/protocol tuple). This would have multiple advantages: 1) no more guesswork, 2) explicit requests would allow for the possibility of "wildcarding," to allow more than one external host to reach the device behind the NAT, and 3) it would be possible to make additional policy requests, includ- ing authorization based on authenticated identity and other policy elements. Several different approaches have been developed, and these are discussed below. 2.1.1. Discovery This approach does not make an explicit request directly to the NAT, but relies on request by implication combined with technology to discover the external address that the NAT assigned (referred to in some quarters as "Unilateral Self-Address Fixing," or UNSAF [RFC3424]). The protocol standardized by the IETF to do self- address discovery is STUN [RFC3489]. While the protocol is very useful for common cases encountered in voice over IP applications, it should be noted that it will not work for TCP or for symmetric NATs. Whether or not it is useful for establishing reachability is completely dependent on the type of NAT the endpoint sits behind, but in the general case it will not be. 2.1.2. Off-path signaling requests This is the most common request model at the moment, and is essen- tially modeled on a client-server relationship. An endpoint or its proxy "knows" the location of a NAT and sends a request for an address mapping directly to the NAT. While it suffers from a lack of robustness in the face of topological complexity, it is probably the best approach to take to establish general reachability. In the general case, when a device makes itself available to be con- tacted by another party (say, in a VoIP call or peer-to-peer appli- cation), it may not know in advance who will be contacting it, or it may want to be reachable by more than one party or, indeed, everybody. The preference for off-path signaling in this scenario is discussed below, in the discussion of on-path signaling. Examples of off-path NAT request protocols include midcom [RFC3303], Universal Plug and Play (UPnP), and RSIP [RFC3103]. It should be mentioned that RSIP is also a relaying protocol (see below). Shore [Page 3] Internet Draft Establishing Reachability March 2004 2.1.3. On-path signaling requests On-path signaling uses an RSVP-like [RFC2205] approach to locating and communicating with network devices. A request is sent into the network, from an endpoint towards another endpoint with which it wishes to establish connectivity, and network devices along the path may intercept the request and act on it (or not). Routing is handled by normal network-layer mechanisms and device location is implicit in the sending of the request. While this approach does not have an established track record there are several projects underway to create new on-path signaling pro- tocols, and at the moment there is considerable momentum behind it. The IETF has chartered the NSIS working group [NSIS], and there are proprietary efforts outside the IETF. While on-path signaling has several considerable advantages over an off-path approach, there is one scenario in which it cannot be used, and that is when the endpoint needs to make a request of a NAT that is not path-oriented. For example, when placing a tele- phone call there is a calling party and a called party. In this case the calling party would send an on-path signaling request towards the called party, and it would be intercepted and acted upon by NATs the request traversed en-route. Obviously, this approach requires a destination address for the request. (If the request were addressed directly to a NAT, it would become an instance of off-path signaling). In situations in which the goal is to establish general reachabil- ity, the endpoint must communicate directly with the NAT and request what is essentially a wildcarded address mapping (traffic from "any" outside address/port pair arriving here would be for- warded to a single "inside" address/port pair). 2.1.4. Relays Relays are probably the most common solution to the problem of pro- viding reachability to NATted devices. There are several products on the market with specialized support for VoIP, such as the ones provided by Ridgeway Systems [Ridgeway] and Jasomi Networks [Jasomi]. These are proprietary technologies. Relays provide a mechanism for creating reachability by placing a device on the outside of the NAT and having it forward traffic to an endhost by encapsulating it or passing it through a pinhole that was created by having the NATted device initiate an outbound Shore [Page 4] Internet Draft Establishing Reachability March 2004 connection to the external relay device. The only standardized relaying technology designed to provide reachability for devices behind NATs is Realm-Specific IP (rsip) [RFC3103]. Unlike the proprietary approaches mentioned above, RSIP puts the "outside" end of the relay on the NAT device itself. Traffic is encapsulated and passed to the internal endpoint. There is also some interest within the IETF in publishing TURN [Rosen- berg], another relaying protocol. Relays can work either through explicit requests, as is the case with RSIP, or through stateful inspection/traffic intercept. The latter is the more common case, since it does not require the replacement of network equipment and because major network equip- ment vendors have been slow to go to this approach. Relays intro- duce performance problems, both in terms of tandeming and queueing delay, and in terms of encapsulation overhead. They also provide the means to skirt network edge security policy, providing only very crude policy parameters (the address/port pair for the relay) for allowing or denying traffic. 2.2. Findability Acquiring a reachable address is not sufficient for becoming reach- able in practice. Peers need to know what that address is. Traditionally, the mechanism for contacting specific applications on specific hosts has relied on the use of static, publicly- routable IP addresses and the use of "well-known" ports. However, in the presence of NATs endpoint addresses are no longer publicly routable, and when NAT workarounds are used to acquire a publicly- routable address/port tuple, it is almost certainly the case that the port will not be at the expected well-known location. That is to say that among the things that NAT breaks is the historic use of static port locations. In VoIP and other session-oriented protocols, the address of the data streams is provided by means of signaling. Endpoints tell each other explicitly what addresses and ports to use for media traffic, after having acquired a routable address using one of the mechanisms described above. The more difficult problem is how to establish the signaling streams, but it is commonly the case with these applications that the signaling streams are mediated by a centralized server, which is already publicly reachable. However, in a peer-to-peer environment in which signaling is not mediated, the problems of acquiring a public presence and then advertising Shore [Page 5] Internet Draft Establishing Reachability March 2004 that public presence remain. The Domain Name System (DNS) [RFC1034] is the location service for the internet. While Dynamic DNS [RFC2136] provides a mechanism for dynamically updating endpoint addresses assigned by DHCP or other non-static address assignment mechanisms, it really is not suitable for per-stream updates, nor is DNS suitable for rapidly-changing configurations. See [RFC3467] for a detailed discussion of the role of DNS in a changing internet. 3. Proposal While DNS is unsuitable as a general-purpose location database, it can be used as a location service for stable internet services, including other lookup services. This is accomplished through the use of SRV records [RFC2782]. For example, a client wishing to locate an LDAP server for the domain "example.com" would submit a DNS query for a resource record of type "SRV" with the contents "_ldap._tcp.example.com". DNS would return a record, if available, providing the IP address and port number of example.com's LDAP server. We are proposing that an endpoint acquire a reachable address for a particular service (say, SIP signaling) using midcom or a midcom- like protocol, then register that address with a domain's LDAP server. An external (to the NAT) peer trying to contact that end- point would use DNS to locate the domain's LDAP server, then query the LDAP server for the address and port at which the endpoint is reachable. This problem requires the use of an off-path signaling protocol, since it is not path-oriented. The availability of routable source and destination addresses is inherent in the notion of a path, and, by definition of this problem, we do not have one in this case. This is true even in cases where we wish to be reachable by only one peer. While we propose the use of midcom as the off-path signaling proto- col, it is not the only protocol available. Even a relaying proto- col could be used to establish an address, although this is not recommended for security and policy reasons. Also, we should note that while LDAP is the de facto standard local directory service for the internet, a database or another local directory service would serve instead. We are using LDAP for illustrative purposes. Shore [Page 6] Internet Draft Establishing Reachability March 2004 3.1. Reachability information elements The directory entry consists of o Address o Port o Transport protocol (TCP, UDP, SCTP, etc.) o "Application" protocol (FTP, SIP, H.323, etc.) o Name as follows: Address: the reachable, or public address provided by the NAT Port: the reachable, or public port provided by the NAT Transport protocol: self-evident Application protocol: self-evident Name: the name being used as the basis for providing reachability, or as the directory index. The value will depend on the application. For example, in the case of an FTP or web server, it may be a hostname. For a VoIP application, it may be the name or a user, or another identifying string such as a telephone number. It could also be a HIP host identifier [Moskowitz]. 4. Use scenarios Shore [Page 7] Internet Draft Establishing Reachability March 2004 (1) +-------+ ------------------>| | | | NAT | | --------------| | | | (2) | | | V +-------+ +----------+ | Server | +----------+ | +---------------+ |------------->| LDAP Server | (3) +---------------+ Figure 1 Figure 1 shows a server behind a NAT acquiring an address from the NAT and registering it with the LDAP directory server. Message 1 is a request to the NAT for an address mapping. Message 2 is the reply, and message 3 is a directory update containing the reachable {address,port,protocol} tuple. (1) ------------------------------ | | V | +------------+ (2) | | DNS Server |----------- | +------------+ | +----------+ ----->| | | Client | -------| | +-------------+ | (3) +----------+ | LDAP Server |<------ | +-------------+ | ^ | | | ----------------------------- (4) Figure 2 Figure 2 shows a client finding the address for a server behind a NAT. It first makes a DNS request for a SRV record for the domain of interest (message 1) and receives a response in message 2. In Shore [Page 8] Internet Draft Establishing Reachability March 2004 message 3 it then contacts the LDAP server at the address returned by DNS with a query for the address and port information for the server it is looking for, receiving a request in message 4. It can then use that information to contact the server. 5. Security considerations This mechanism introduces several new security exposures that would not exist if the NATted devices were not, in fact, NATted. First, the mechanism for acquiring an address may be vulnerable to a vari- ety of attacks depending on the technology used. Those vulnerabil- ities are addressed in documents describing those mechanisms and are out of scope for this document. There are two processes that are of interest to this document: 1) registering a reachable address/port tuple with a directory, and 2) querying the directory to find a reachable address. There are two clear risks in the registration process. The first is false regis- tration, or registering an illegitimate address. This attack allows miscreants to redirect network communication so that, for example, someone wishing to place a SIP call would receive not the address of the party they are trying to call, but instead the address of an attacker, who could then eavesdrop on or even mas- querade as the called party. The second risk lies in unauthenti- cated deregistration, which could be used to commit a denial-of- service attack against a NATted device. In both cases the regis- tration process requires that the registration/deregistration request packets be authenticated and integrity protected. The query process introduces the possibility of an attacker inject- ing a spoofed response to a query, allowing the same sorts of attacks as false registration (although it should be noted that DNS responses are almost never authenticated in actual practice). To protect against this attack, the responses from the directory must be authenticated and integrity protected. 6. Infrastructure requirements and transition As with all NAT workarounds, this proposal introduces additional network elements, increasing network complexity and operating costs. In this particular case the new elements are: o A publicly-accessible LDAP server o A midcom- (or similar) capable NAT Shore [Page 9] Internet Draft Establishing Reachability March 2004 o Appropriate authentication technology The domain's DNS server will need to provide an SRV RR for the domain. Additionally, clients and peers wishing to contact devices behind NATs will need to know to request addressing information from a domain's LDAP server, and hosts behind a NAT wishing to be reach- able will need to be able to acquire a routable address from a NAT (by supporting midcom, for example) and then register that address with an LDAP server. That's a lot to ask, and it's not currently possible to do the sort of forklift upgrade of the internet, or even of an enterprise or local service provider network, to make this all work at once. What can be said about transitioning, however, is that as these facilities are added incrementally to existing software and exist- ing operational networks, NATted hosts would be no less reachable than they are today. 7. Operational issues and reliability Introducing additional network elements always introduces the like- lihood of increased instability, and there is a tradeoff against the gains from increased functionality. While there is great demand for a mechanism to allow NATted devices to establish reacha- bility and there is at this time no generalized mechanism (other than what is being proposed here) for doing so, we think it is worthwhile to discuss some of the sources of instability being introduced. The most obvious problem is that of maintaining consistent state. The NATted device can crash, the LDAP server can crash, or the NAT can crash, and any of these events might cause the shared state to desynchronize. Of these three events the possibility of the LDAP server crashing is the least difficult to resynchronize. It may be down when a client wishes to register its address, or it may be down when a client wishes to deregister its address. If it is down and unavailable for registration, the NATted device is effectively unavailable. If it is down and unavailable for deregistration, the reachable address may still be found even if the NATted device is offline or unreachable. Both of these cases may be mitigated through request retransmission (although the problem remains if the LDAP server crashes and then the client crashes before a Shore [Page 10] Internet Draft Establishing Reachability March 2004 deregistration request is accepted and acted upon; we recommend timeouts on directory entries for this reason). If the NATted device crashes it may lose state. In particular, it may lose information about what addresses it has acquired from the NAT. There are two possibilities for resynchronizing -- contact the NAT, or contact the LDAP server. It may be the case that both are required. The NAT should be contacted to find out what map- pings are installed, assuming that the address acquisition protocol permits it. The LDAP server should be contacted to find out what directory entries have been installed, either to confirm that they are there or to delete any that are installed if the NAT query reveals that some or all of them are gone (note that a timeout on directory entries may be sufficient to take care of this latter issue). If the NAT itself crashes it is almost certainly the case that the requested NAT entries will be lost on reboot. In order to recover, the device behind the NAT first needs to be able to detect that the NAT crashed. It then needs to delete the existing directory entry on the LDAP server, request a new reachable address from the NAT, and install a new directory entry. 8. Conclusion One of the most serious problems introduced by NATs is that it ren- ders NATted devices essentially unreachable, breaking some of the semantics of IP addressing. There have been several proposals and work-arounds, but for the most part these have been specialized to particular applications, unsound from a policy enforcement perspec- tive, or just generally slap-dash. Steve Deering once said that the answer to crud in the network is not more crud in the network. It's hard to argue against that, but it assumes the possibility of solving the problems introduced by crud simply removing some of it. In practice, that may not be an option. Several different proposals for solving different aspects of NAT- introduced problems have been put forward. Most of these have been oriented towards one specific application, voice over IP. That is not the only application having difficulty with NATs, however, or with the more general problem of establishing reachability. We feel that by breaking down the problem into its two component parts and solving each of those parts using existing technology (say, midcom and LDAP) we can provide a cleaner and more general approach Shore [Page 11] Internet Draft Establishing Reachability March 2004 to solving the reachability problem. 9. References [Jasomi] "Jasomi Networks Peering Point Solutions" http://www.jasomi.com/solutions.html [Jennings] Jennings, Cullen. "NAT Classification Results using STUN," work in progress, February 2004. draft-jennings-midcom-stun- results-00. [Moskowitz] Moskowitz, R. et al. "Host Identity Protocol," work in progress, February 2004. draft-moskowitz-hip-09. [NSIS] "Next Steps in Signaling (nsis)" http://www.ietf.org/html.char- ters/nsis-charter.html [RFC1034] Mockapetris, P. "Domain Names -- Concepts and Facilities," RFC 1034, November 1987. [RFC2136] Vixie, P. et al. "Dynamic Updates in the Domain Name System (DNS UPDATE)," RFC 2136, April 1997. [RFC2205] Braden, R. et al. "Resource ReSerVation Protocol (RSVP) Ð Version 1 Functional Specification," RFC 2205, September 1997. [RFC2782] Gulbrandsen, A., Vixie, P. and L. Esibov. "A DNS RR for spec- ifying the location of services (DNS SRV)," RFC 2782, February 2000. [RFC3103] Borella, M. et al. "Realm Specific IP: Protocol Specifica- tion," RFC 3103, October 2001. [RFC3303] Srisuresh, P, et al. "Middlebox communication architecture and framework," RFC 3303, August 2002. [RFC3424] Daigle, L., ed. "IAB Considerations for UNilateral Self- Address Fixing (UNSAF) Across Network Address Translation," RFC 3424, November 2002. [RFC3467] Klensin, J. "Role of the Domain Name System (DNS)," RFC 3467, February 2003. [RFC3489] Rosenberg, J. et al. "STUN - Simple Traversal of User Data- gram Protocol (UDP) Through Network Address Translators (NATs)," RFC 3489, March 2003. Shore [Page 12] Internet Draft Establishing Reachability March 2004 [Ridgeway] "IPFreedom" http://www.ridgewaysystems.com/products.aspx [Rosenberg] Rosenberg, Jonathan, Mahy, Rohan, and Christian Huitema. "Traversal Using Relay NAT (TURN)," work in progress, October 2003. draft-rosenberg- midcom-turn-03. 10. Full copyright statement Copyright (C) The Internet Society (2004). This document is sub- ject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REP- RESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 11. Intellectual property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC docu- ments can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this speci- fication can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org. Shore [Page 13] Internet Draft Establishing Reachability March 2004 Author's address Melinda Shore Cisco Systems 809 Hayts Road Ithaca, NY 14850 USA mshore@cisco.com Shore [Page 14]