idnits 2.17.1 draft-saito-sip-rendezvous-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 352. 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 : ---------------------------------------------------------------------------- No issues found here. 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 (January 29, 2008) is 5932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Saito 3 Internet-Draft NTT Communications 4 Intended status: Informational D. Wing 5 Expires: August 1, 2008 Cisco Systems 6 January 29, 2008 8 Analysis of Rendezvous Mechanism for Home Access Using SIP 9 draft-saito-sip-rendezvous-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 1, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 Home servers are becoming more common and people expect to still 43 access them even when they are outside their home. However, there 44 are several requirements to realize remote access to the home such as 45 name resolution, NAT/Firewall traversal, and authentication/ 46 authorization. This document describes what technologies can be used 47 to solve these issues and analyzes the utility of SIP as a rendezvous 48 mechanism for this use case. 50 Conventions used in this document 52 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 53 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 54 document are to be interpreted as described in [RFC2119]. 56 Table of Contents 58 1. Introduction and Problem Statement . . . . . . . . . . . . . . 4 59 2. Approaches to the Solution . . . . . . . . . . . . . . . . . . 6 60 2.1. Name Resolution . . . . . . . . . . . . . . . . . . . . . 6 61 2.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal . . . 6 62 2.3. Authentication and Authorization of Clients . . . . . . . 6 63 3. Analysis of Approaches . . . . . . . . . . . . . . . . . . . . 8 64 3.1. Name Resolution . . . . . . . . . . . . . . . . . . . . . 8 65 3.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal . . . 8 66 3.3. Authentication and Authorization of Clients . . . . . . . 8 67 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 68 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 6.1. Normative References . . . . . . . . . . . . . . . . . . . 12 71 6.2. Informative References . . . . . . . . . . . . . . . . . . 12 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 73 Intellectual Property and Copyright Statements . . . . . . . . . . 14 75 1. Introduction and Problem Statement 77 In this section, the background of the problem in accessing home 78 network which this document tries to solve is described. 80 Home servers are becoming more common with multiple terabyte home 81 NAS, media servers and storage, multiple computers at home, security 82 cameras, and home automation. People expect to still access these 83 home devices when they are outside their home -- at an Internet cafe, 84 friend's house, or relative's house. However, several functions are 85 required to realize the remote access to the home. 87 When a device outside the home network connects to another device 88 inside the home network, it often becomes a problem to resolve the 89 name of device. Because the device's IP address is not always fixed 90 depending on provider's services, it is necessary to make use of a 91 dynamic name resolution mechanism. 93 In addition, it is also necessary to traverse a NAT (Network Address 94 Translation) or Firewall device between them. One of the effective 95 solutions for this problem is VPN remote access to the NAT/Firewall 96 device, usually a home router. With this approach, once the external 97 device participates in the home network securely, it will be easy to 98 establish connections with all the devices inside the home. On the 99 other hand, there are more difficult cases that a home router itself 100 is located inside the NAT/Firewall. In such cases, it is also 101 necessary to consider NAT/Firewall traversal of the remote access to 102 the home router. Anyway, NAT/Firewall traversal technologies which 103 are valid in any environments are needed. 105 Furthermore, there is a problem how a remote client and a home server 106 authenticate each other. It wouldn't be always possible that both 107 parties exchange a pre-shared key (or password) securely in advance. 108 It would be also impractical to distribute authentication 109 certificates signed by well-known root certification authority (CA) 110 to all the devices because of their cost and administrative overhead, 111 and after all, it is inefficient to publish a temporary certificate 112 to the device which does not have a fixed IP address or hostname. 113 One more concerning thing is that bogus pollings may frequently come 114 from the Internet to the home. In that situation, even their 115 authentication process will be serious for the home servers. Because 116 some networked home appliances do not have sufficient CPU 117 performance, that process may reduce the performance of user 118 applications. In addition, it will also waste the access bandwidth. 119 Therefore, an effective authentication and authorization system which 120 saves these kinds of home network operation is needed. 122 To summarize, we can break down the required functions into the 123 following items. 125 1. name resolution -- a mechanism for the client to learn the home 126 server's transport address (IP address, protocol, and port). 128 2. home IPv4 NAT and home IPv4/IPv6 firewall traversal -- a 129 mechanism for the home server to make itself accessible to the 130 Internet. 132 3. authentication and authorization of clients -- a mechanism for 133 the home server to determine if a client is legitimate without 134 serious network operational costs. 136 2. Approaches to the Solution 138 Today, we have several element technologies to provide the above 139 functions. 141 2.1. Name Resolution 143 As for the name resolution, there are following potential solutions. 145 o SIP: SIP [RFC3261] is a flexible and widely-deployed name 146 resolution mechanism and it can be used in this use case. The 147 disadvantages of using SIP are that the client needs to support 148 SIP and the name would be SIP-URI based. 150 o Dynamic DNS: Dynamic DNS [DDNS] is also qualified for this 151 purpose. A home server can use hostname, but it would often be an 152 awkward one because of general dynamic DNS services. 154 o HTTP Redirect Server: The name resolution is realized by making 155 use of HTTP redirect mechanism if the home server can upload its 156 IP address to the redirect server. Hostnames can be used, but 157 this technique is limited to HTTP. 159 2.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal 161 As for IPv4 NAT traversal and IPv4 Firewall traversal, there are 162 following potential solutions. 164 o SIP & ICE [I-D.ietf-mmusic-ice]: This approach is the best 165 solution today. It enables any kinds of remote access in almost 166 all the environments. 168 o UPnP IGD [UPnP-IGD]: This is widely-used effective approach in the 169 home network. However it doesn't work with nested NAT, and also 170 doesn't work with IPv6. 172 o Relay (UDP/TCP): Using relay is the best and stable approach. It 173 enables any kinds of remote access in almost all the environments. 174 However, it requires operation of a relay server on the Internet, 175 with associated operational costs. 177 As for IPv6 Firewall traversal, two individual proposals have been 178 submitted and are now under discussion. 180 2.3. Authentication and Authorization of Clients 182 For this purpose, the following solutions are considered. 184 o In Protocol: As a traditional approach, authentication and 185 authorization can be solved in the protocol between the client and 186 server. HTTP BASIC authentication [RFC2617] and IKE [RFC4306] are 187 the examples of this. 189 o Rendezvous Mechanism: Authentication and authorization can be 190 conducted by the rendezvous mechanism such as trusted SIP proxy. 191 By this approach, the home servers become free from the network 192 operational costs related to authentication and authorization. 194 3. Analysis of Approaches 196 In this section, we analyzes the above solutions. 198 3.1. Name Resolution 200 Just considering the function of name resolution, dynamic DNS or HTTP 201 redirect server (or potentially combination of them) would be better 202 than SIP because of simplicity. However we need to consider it 203 integratedly with the other requirements. Of course, it is also 204 possible to combine more than one method listed above. 206 3.2. Home IPv4 NAT and Home IPv4/IPv6 Firewall Traversal 208 Because we need to assure the connectivity of remote access in any 209 environments, SIP & ICE and Relay approaches would be the candidates. 210 And considering the use case, the mechanism SHOULD be scalable. 211 Therefore, SIP & ICE is more expected one. On the other hand, the 212 drawback of ICE approach is that it always requires a rendezvous 213 mechanism (SIP). 215 As for the SIP & ICE approach, we can point another advantage. By 216 using ICE, the client and the server can exchange both IPv4 and IPv6 217 addresses simultaneously, which facilitates the session between IPv4 218 device and IPv6 device. This property fits the IPv6 transition 219 [I-D.ietf-sipping-v6-transition] case well. 221 3.3. Authentication and Authorization of Clients 223 The traditional "In Protocol" approaches are well-deployed, but also 224 have drawbacks of user operation (management of pre-shared key, 225 password, signed certificate) and possible performance vulnerability 226 (e.g., bogus pollings from the Internet) during the authentication 227 process. 229 On the other hand, taking advantage of trusted rendezvous mechanisms 230 (SIP proxies), unauthenticated or unauthorized access is terminated 231 by them and never gets to the home servers. Therefore, if it is 232 possible to utilize the trusted rendezvous mechanism for 233 authentication and authorization, that will be one of the effective 234 solutions. 236 Considering all the characteristics described above, we can say SIP & 237 ICE is the most suitable rendezvous mechanism for the remote access 238 to the home. It has a flexible and widely-deployed name resolution 239 mechanism and solves the almost all the NAT/Firewall traversal 240 problems. Furthermore, SIP proxy will save the home network 241 operational costs as the trusted intermediary. In fact, SIP is 242 applied to not only VoIP but also various applications and recognized 243 as a general protocol for session initiation today. 245 4. IANA Considerations 247 None; this document is informational. 249 5. Security Considerations 251 This document describes the possible rendezvous mechanisms for remote 252 access to the home and analyzes them. It also describes the problems 253 in the authentication and authorization process in that case. 254 Applied technologies need to be correctly implemented to assure their 255 security. 257 6. References 259 6.1. Normative References 261 [DDNS] http://en.wikipedia.org/wiki/Dynamic_DNS 263 [I-D.ietf-mmusic-ice] 264 Rosenberg, J., "Interactive Connectivity Establishment 265 (ICE): A Protocol for Network Address Translator (NAT) 266 Traversal for Offer/Answer Protocols", 267 draft-ietf-mmusic-ice-19 (work in progress), October 2007. 269 [I-D.ietf-sipping-v6-transition] 270 Camarillo, G., "IPv6 Transition in the Session Initiation 271 Protocol (SIP)", draft-ietf-sipping-v6-transition-07 (work 272 in progress), August 2007. 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 278 A., Peterson, J., Sparks, R., Handley, M., and E. 279 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 280 June 2002. 282 [UPnP-IGD] 283 UPnP Forum, "Internet Gateway Device (IGD) Standardized 284 Device Control Protocol V1.0", November 2001. 286 6.2. Informative References 288 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 289 Leach, P., Luotonen, A., and L. Stewart, "HTTP 290 Authentication: Basic and Digest Access Authentication", 291 RFC 2617, June 1999. 293 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 294 RFC 4306, December 2005. 296 Authors' Addresses 298 Makoto Saito 299 NTT Communications 300 3-20-2 Nishi-Shinjuku, Shinjuku-ku 301 Tokyo 163-1421 302 Japan 304 Email: ma.saito@nttv6.jp 306 Dan Wing 307 Cisco Systems 308 170 West Tasman Drive 309 San Jose, CA 95134 310 United States 312 Email: dwing@cisco.com 314 Full Copyright Statement 316 Copyright (C) The IETF Trust (2008). 318 This document is subject to the rights, licenses and restrictions 319 contained in BCP 78, and except as set forth therein, the authors 320 retain all their rights. 322 This document and the information contained herein are provided on an 323 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 324 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 325 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 326 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 330 Intellectual Property 332 The IETF takes no position regarding the validity or scope of any 333 Intellectual Property Rights or other rights that might be claimed to 334 pertain to the implementation or use of the technology described in 335 this document or the extent to which any license under such rights 336 might or might not be available; nor does it represent that it has 337 made any independent effort to identify any such rights. Information 338 on the procedures with respect to rights in RFC documents can be 339 found in BCP 78 and BCP 79. 341 Copies of IPR disclosures made to the IETF Secretariat and any 342 assurances of licenses to be made available, or the result of an 343 attempt made to obtain a general license or permission for the use of 344 such proprietary rights by implementers or users of this 345 specification can be obtained from the IETF on-line IPR repository at 346 http://www.ietf.org/ipr. 348 The IETF invites any interested party to bring to its attention any 349 copyrights, patents or patent applications, or other proprietary 350 rights that may cover technology that may be required to implement 351 this standard. Please address the information to the IETF at 352 ietf-ipr@ietf.org. 354 Acknowledgment 356 Funding for the RFC Editor function is provided by the IETF 357 Administrative Support Activity (IASA).