Network Working Group M. Saito Internet-Draft NTT Communications Intended status: Informational D. Wing Expires: August 1, 2008 Cisco Systems January 29, 2008 Analysis of Rendezvous Mechanism for Home Access Using SIP draft-saito-sip-rendezvous-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 documents 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. This Internet-Draft will expire on August 1, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Saito & Wing Expires August 1, 2008 [Page 1] Internet-Draft Rendezvous Mechanism for Home Access January 2008 Abstract Home servers are becoming more common and people expect to still access them even when they are outside their home. However, there are several requirements to realize remote access to the home such as name resolution, NAT/Firewall traversal, and authentication/ authorization. This document describes what technologies can be used to solve these issues and analyzes the utility of SIP as a rendezvous mechanism for this use case. Saito & Wing Expires August 1, 2008 [Page 2] Internet-Draft Rendezvous Mechanism for Home Access January 2008 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Table of Contents 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 2. Approaches to the Solution . . . . . . . . . . . . . . . . . . 6 2.1. Name Resolution . . . . . . . . . . . . . . . . . . . . . 6 2.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal . . . 6 2.3. Authentication and Authorization of Clients . . . . . . . 6 3. Analysis of Approaches . . . . . . . . . . . . . . . . . . . . 8 3.1. Name Resolution . . . . . . . . . . . . . . . . . . . . . 8 3.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal . . . 8 3.3. Authentication and Authorization of Clients . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Saito & Wing Expires August 1, 2008 [Page 3] Internet-Draft Rendezvous Mechanism for Home Access January 2008 1. Introduction and Problem Statement In this section, the background of the problem in accessing home network which this document tries to solve is described. Home servers are becoming more common with multiple terabyte home NAS, media servers and storage, multiple computers at home, security cameras, and home automation. People expect to still access these home devices when they are outside their home -- at an Internet cafe, friend's house, or relative's house. However, several functions are required to realize the remote access to the home. When a device outside the home network connects to another device inside the home network, it often becomes a problem to resolve the name of device. Because the device's IP address is not always fixed depending on provider's services, it is necessary to make use of a dynamic name resolution mechanism. In addition, it is also necessary to traverse a NAT (Network Address Translation) or Firewall device between them. One of the effective solutions for this problem is VPN remote access to the NAT/Firewall device, usually a home router. With this approach, once the external device participates in the home network securely, it will be easy to establish connections with all the devices inside the home. On the other hand, there are more difficult cases that a home router itself is located inside the NAT/Firewall. In such cases, it is also necessary to consider NAT/Firewall traversal of the remote access to the home router. Anyway, NAT/Firewall traversal technologies which are valid in any environments are needed. Furthermore, there is a problem how a remote client and a home server authenticate each other. It wouldn't be always possible that both parties exchange a pre-shared key (or password) securely in advance. It would be also impractical to distribute authentication certificates signed by well-known root certification authority (CA) to all the devices because of their cost and administrative overhead, and after all, it is inefficient to publish a temporary certificate to the device which does not have a fixed IP address or hostname. One more concerning thing is that bogus pollings may frequently come from the Internet to the home. In that situation, even their authentication process will be serious for the home servers. Because some networked home appliances do not have sufficient CPU performance, that process may reduce the performance of user applications. In addition, it will also waste the access bandwidth. Therefore, an effective authentication and authorization system which saves these kinds of home network operation is needed. To summarize, we can break down the required functions into the Saito & Wing Expires August 1, 2008 [Page 4] Internet-Draft Rendezvous Mechanism for Home Access January 2008 following items. 1. name resolution -- a mechanism for the client to learn the home server's transport address (IP address, protocol, and port). 2. home IPv4 NAT and home IPv4/IPv6 firewall traversal -- a mechanism for the home server to make itself accessible to the Internet. 3. authentication and authorization of clients -- a mechanism for the home server to determine if a client is legitimate without serious network operational costs. Saito & Wing Expires August 1, 2008 [Page 5] Internet-Draft Rendezvous Mechanism for Home Access January 2008 2. Approaches to the Solution Today, we have several element technologies to provide the above functions. 2.1. Name Resolution As for the name resolution, there are following potential solutions. o SIP: SIP [RFC3261] is a flexible and widely-deployed name resolution mechanism and it can be used in this use case. The disadvantages of using SIP are that the client needs to support SIP and the name would be SIP-URI based. o Dynamic DNS: Dynamic DNS [DDNS] is also qualified for this purpose. A home server can use hostname, but it would often be an awkward one because of general dynamic DNS services. o HTTP Redirect Server: The name resolution is realized by making use of HTTP redirect mechanism if the home server can upload its IP address to the redirect server. Hostnames can be used, but this technique is limited to HTTP. 2.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal As for IPv4 NAT traversal and IPv4 Firewall traversal, there are following potential solutions. o SIP & ICE [I-D.ietf-mmusic-ice]: This approach is the best solution today. It enables any kinds of remote access in almost all the environments. o UPnP IGD [UPnP-IGD]: This is widely-used effective approach in the home network. However it doesn't work with nested NAT, and also doesn't work with IPv6. o Relay (UDP/TCP): Using relay is the best and stable approach. It enables any kinds of remote access in almost all the environments. However, it requires operation of a relay server on the Internet, with associated operational costs. As for IPv6 Firewall traversal, two individual proposals have been submitted and are now under discussion. 2.3. Authentication and Authorization of Clients For this purpose, the following solutions are considered. Saito & Wing Expires August 1, 2008 [Page 6] Internet-Draft Rendezvous Mechanism for Home Access January 2008 o In Protocol: As a traditional approach, authentication and authorization can be solved in the protocol between the client and server. HTTP BASIC authentication [RFC2617] and IKE [RFC4306] are the examples of this. o Rendezvous Mechanism: Authentication and authorization can be conducted by the rendezvous mechanism such as trusted SIP proxy. By this approach, the home servers become free from the network operational costs related to authentication and authorization. Saito & Wing Expires August 1, 2008 [Page 7] Internet-Draft Rendezvous Mechanism for Home Access January 2008 3. Analysis of Approaches In this section, we analyzes the above solutions. 3.1. Name Resolution Just considering the function of name resolution, dynamic DNS or HTTP redirect server (or potentially combination of them) would be better than SIP because of simplicity. However we need to consider it integratedly with the other requirements. Of course, it is also possible to combine more than one method listed above. 3.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal Because we need to assure the connectivity of remote access in any environments, SIP & ICE and Relay approaches would be the candidates. And considering the use case, the mechanism SHOULD be scalable. Therefore, SIP & ICE is more expected one. On the other hand, the drawback of ICE approach is that it always requires a rendezvous mechanism (SIP). As for the SIP & ICE approach, we can point another advantage. By using ICE, the client and the server can exchange both IPv4 and IPv6 addresses simultaneously, which facilitates the session between IPv4 device and IPv6 device. This property fits the IPv6 transition [I-D.ietf-sipping-v6-transition] case well. 3.3. Authentication and Authorization of Clients The traditional "In Protocol" approaches are well-deployed, but also have drawbacks of user operation (management of pre-shared key, password, signed certificate) and possible performance vulnerability (e.g., bogus pollings from the Internet) during the authentication process. On the other hand, taking advantage of trusted rendezvous mechanisms (SIP proxies), unauthenticated or unauthorized access is terminated by them and never gets to the home servers. Therefore, if it is possible to utilize the trusted rendezvous mechanism for authentication and authorization, that will be one of the effective solutions. Considering all the characteristics described above, we can say SIP & ICE is the most suitable rendezvous mechanism for the remote access to the home. It has a flexible and widely-deployed name resolution mechanism and solves the almost all the NAT/Firewall traversal problems. Furthermore, SIP proxy will save the home network operational costs as the trusted intermediary. In fact, SIP is Saito & Wing Expires August 1, 2008 [Page 8] Internet-Draft Rendezvous Mechanism for Home Access January 2008 applied to not only VoIP but also various applications and recognized as a general protocol for session initiation today. Saito & Wing Expires August 1, 2008 [Page 9] Internet-Draft Rendezvous Mechanism for Home Access January 2008 4. IANA Considerations None; this document is informational. Saito & Wing Expires August 1, 2008 [Page 10] Internet-Draft Rendezvous Mechanism for Home Access January 2008 5. Security Considerations This document describes the possible rendezvous mechanisms for remote access to the home and analyzes them. It also describes the problems in the authentication and authorization process in that case. Applied technologies need to be correctly implemented to assure their security. Saito & Wing Expires August 1, 2008 [Page 11] Internet-Draft Rendezvous Mechanism for Home Access January 2008 6. References 6.1. Normative References [DDNS] http://en.wikipedia.org/wiki/Dynamic_DNS [I-D.ietf-mmusic-ice] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", draft-ietf-mmusic-ice-19 (work in progress), October 2007. [I-D.ietf-sipping-v6-transition] Camarillo, G., "IPv6 Transition in the Session Initiation Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work in progress), August 2007. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [UPnP-IGD] UPnP Forum, "Internet Gateway Device (IGD) Standardized Device Control Protocol V1.0", November 2001. 6.2. Informative References [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. Saito & Wing Expires August 1, 2008 [Page 12] Internet-Draft Rendezvous Mechanism for Home Access January 2008 Authors' Addresses Makoto Saito NTT Communications 3-20-2 Nishi-Shinjuku, Shinjuku-ku Tokyo 163-1421 Japan Email: ma.saito@nttv6.jp Dan Wing Cisco Systems 170 West Tasman Drive San Jose, CA 95134 United States Email: dwing@cisco.com Saito & Wing Expires August 1, 2008 [Page 13] Internet-Draft Rendezvous Mechanism for Home Access January 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject 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 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST 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. 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 documents 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 specification 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Saito & Wing Expires August 1, 2008 [Page 14]