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]