[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/