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

Versions: 00 01

hiprg                                                     Jun. Wang, Ed.
Internet-Draft                                               Jiong. Shen
Intended status: Informational                           ZTE Corporation
Expires: March 4, 2011                                   August 31, 2010


                       HIP Service Overlay Study
                draft-wang-hiprg-service-overlay-01.txt

Abstract

   This draft is a HIP service overlay study document, it presents
   several disadvantages of current HIP protocol and then takes a brief
   introduction of two existing alternative solutions.  Finally, the
   authors propose a HIP service overlay architecture.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on March 4, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




Wang & Shen               Expires March 4, 2011                 [Page 1]


Internet-Draft          HIP Service Overlay study            August 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Alternative solutions  . . . . . . . . . . . . . . . . . . . .  4
     3.1.  i3 . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     3.2.  Hi3  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  HIP service overlay  . . . . . . . . . . . . . . . . . . . . .  6
     4.1.  Architecture . . . . . . . . . . . . . . . . . . . . . . .  6
     4.2.  Registration procedure . . . . . . . . . . . . . . . . . .  7
     4.3.  Initiating a communication . . . . . . . . . . . . . . . .  7
     4.4.  Updating location  . . . . . . . . . . . . . . . . . . . .  8
     4.5.  Scalability and performance  . . . . . . . . . . . . . . .  8
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     8.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Appendix A.  Additional Stuff  . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10





























Wang & Shen               Expires March 4, 2011                 [Page 2]


Internet-Draft          HIP Service Overlay study            August 2010


1.  Introduction

   HIP protocol employed an end-to-end communication model, which makes
   the deployment very simple - it's not necessary to deploy additional
   expensive infrastructure.  But this kind of design incurs some
   weaknesses mentioned as following.

   #1.  Before one host can communicate with another host, it MUST
   initiate a HIP 4-way handshake, and then initiate a TCP handshake and
   other transport or application connections.  If the two hosts have
   big RTT, it leads to a long connection delay and downgrades the user
   experience.

   #2.  When all the underlying links of one host get broken, the
   initiator doesn't know the link had broken until it has gotten O(n^2)
   fail attempts for each host it connected, in which the n is the
   number of one multihoming host's locators.

   #3.  Existing widely deployed telecomm network employs pre-shared key
   security mechanism rather than PKI.  So if HIP can support pre-shared
   key authentication, the existing infrastructure can be reused.

   #4.  Since HIP mobility mechanism uses end to end connection, if a
   HIP host's IP address changed, it must sends an update message to its
   connected peer.  Such design makes the mobility possible even if
   infrastructure does not involved, but it also causes two weaknesses:
   1)If the connected two hosts have big RTT or if the HIP host has too
   many connections, the update may be time-consuming and leads to very
   high handover delay. 2)If two hosts of one connection change their IP
   addresses simultaneously, the update could never been successful only
   after using some anchor mechanism such as RVS, but as RVS only
   forwarding HIP signaling message, some data packages may missing.

1.1.  Requirements Language

   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 RFC 2119 [RFC2119].


2.  Terminology

   HAP: Host identity protocol(HIP) access peer, the attachment point
   for HIP host provided by the HIP service overlay.

   HSN: HIP service overlay super node, the actual HIP service node.
   They provide the rendezvous services and route the HIP packets
   originally from any authorized HIP host.  At most cases, the HAPs are



Wang & Shen               Expires March 4, 2011                 [Page 3]


Internet-Draft          HIP Service Overlay study            August 2010


   also HSNs.


3.  Alternative solutions

3.1.  i3

   i3(Internet Indirection Infrastructure) offers a rendezvous-based
   communication abstraction; applications can easily implement a
   variety of communication services, such as multicast, anycast, and
   mobility, on top of this communication abstraction.  Sources send
   packets to a logical identifier, and receivers express interest in
   packets sent to an identifier.  Delivery is best-efforts like in
   today's Internet, with no guarantees about packet delivery and
   packets are not stored in i3, they are only forwarded.

   i3 is an overlay network which consists of a set of servers that
   store triggers(the identifier and the address binding) and forward
   packets between i3 nodes and to end-hosts.  Identifiers and triggers
   have meaning only in this i3 overlay. i3 uses Chord lookup protocol,
   also in principle, i3 can use any of the proposed P2P lookup systems
   such as CAN, Pastry and Tapestry etc.





























Wang & Shen               Expires March 4, 2011                 [Page 4]


Internet-Draft          HIP Service Overlay study            August 2010


               ________________________________________________
              |Overlay           _____________                 |
              |                 |             |                |
              |        +--------|  i3 server  |-------+        |
              |        |        |             |       |        |
              |        |        '-------------'       |        |
              |  ______|______                  ______|______  |
              | |             |                |             | |
          +---| |  i3 server  |                |  i3 server  | |---+
          |   | |             |                |             | |   |
          |   | '-------------'                '-------------' |   |
          |   |        |         _____________        |        |   |
          |   |        |        |             |       |        |   |
          |   |        +--------|  i3 server  |-------+        |   |
          |   |                 |             |                |   |
          |   |                 '-------------'                |   |
          |   |             (ID, Address) binding              |   |
          |   |________________________________________________|   |
          |                                                        |
          |(ID,Data)                                          Data |
      ____|________                                       _________|___
     |             |                                     |             |
     |   host 1    |                                     |    host 2   |
     |             |                                     |             |
     '-------------'                                     '-------------'


                         Figure 1: i3 Architecture

   i3 uses i3 header to carry the identifier information on top of IP.
   But as i3 is not a layer 3.5 protocol, the i3 header is implemented
   on top of TCP or UDP.  (Source from i3 implementation of Berkeley
   University. http://i3.cs.berkeley.edu/).  For the four issues listed
   in introduction part, as i3 does not need HIP handshake, the issue #1
   goes away; and as hosts always send packages to i3 infrastructure,
   and update i3 infrastructure about it's IP address changes, so issue
   #2, #3 and #4 also can be resolved.  But as i3 is not a 3.5 layer
   protocol, it's not transparent support layer four and uplayer
   applications, and difficult to standardization.

3.2.  Hi3

   Hi3(Host Identity Indirection Infrastructure) recommends using the
   Internet Indirection Infrastructure(i3) to relay Host Identity
   Protocol(HIP) handshake packets, thereby serving as a control plane.
   Using i3 as a control plane for HIP in Hi3 improves protection from
   DoS attacks and provides an initial rendezvous service.  Hi3 still
   uses end to end HIP connection as data plane after HIP handshake.



Wang & Shen               Expires March 4, 2011                 [Page 5]


Internet-Draft          HIP Service Overlay study            August 2010


               ________________________________________________
              |Overlay           _____________                 |
              |                 |             |                |
              |        +--------|  i3 server  |-------+        |
              |        |        |             |       |        |
              |        |        '-------------'       |        |
              |  ______|______                  ______|______  |
              | |             |                |             | |
          +---| |  i3 server  |                |  i3 server  | |---+
          |   | |             |                |             | |   |
          |   | '-------------'                '-------------' |   |
          |   |        |         _____________        |        |   |
          |   |        |        |             |       |        |   |
          |   |        +--------|  i3 server  |-------+        |   |
          |   |                 |             |                |   |
          |   |                 '-------------'                |   |
          |   |             Control plane                      |   |
          |   |________________________________________________|   |
          |                                                        |
          |I1,I2                                             R1,R2 |
      ____|________                                       _________|___
     |             |        Data Plane                   |             |
     |   host 1    |-------------------------------------|    host 2   |
     |             |                                     |             |
     '-------------'                                     '-------------'


                        Figure 2: Hi3 Architecture

   Hi3 uses i3 as control plane for forwarding HIP handshake packages
   I1, I2, R1 and R2, but still uses end to end PKI infrastructure and
   end to end HIP connection as data plane, so the issues #1, #2, #3 and
   #4(1) listed in introduction part still exist.


4.  HIP service overlay

4.1.  Architecture

   The HIP service overlay provides HIP service to the HIP hosts, it
   also acts as a rendezvous server.  If the hosts want to access the
   HIP service provided by the HIP service overlay, they MUST register
   in the HIP service overlay.  HIP service overlay stores the
   registration information including locator and identifier bindings
   according to its own distributed algorithm.






Wang & Shen               Expires March 4, 2011                 [Page 6]


Internet-Draft          HIP Service Overlay study            August 2010


                                  +-----+
                       +----------| HSN |----------+
                       |          +-----+          |
       +-----+         |                           |         +-----+
       |Host1|---+   +-+--+                     +--+-+   +---|Host2|
       +-----+   +---|HAP | HIP Service Overlay |HAP |---+   +-----+
                     +-+--+                     +--+-+
                       |                           |
                       |                           |
                       +---------------------------+


                Figure 3: HIP Service Overlay Architecture

   After the host registered to the HIP service overlay successfully, it
   established HIP connections with one or more HAPs, then the host can
   choose arbitrary one HAP to initiate a communication to another host,
   no further HIP handshakes are required.

   The HAPs and HSNs comprise a HIP service overlay, where the HIP
   identifier/locator bindings are stored according to the DHT
   algorithm.  HIP identifiers are treated as DHT resource keys and
   hashed into a fixed length bit sequence to formulate resource IDs.
   In most cases, the classical DHT algorithms with the O(LogN) search
   complexity have poor performance, we must choose some other
   algorithms with better performance.  The one hop DHT can meet the
   rigid performance requirement, but it has the scalability issues.
   We'll take further discussion in later section.

4.2.  Registration procedure

   When the HIP host wants to register to a HIP service overlay, it can
   inquire DNS for the HIP proxy(HAP) addresse or by inquire some static
   configured server.  The server may reture several HAP addresses,
   which are expected to be used in upcoming connection.  HIP host then
   formulates a HIP I1 packet as a normal registration request.  Then
   the HAP informs the HIP host expected authentication method and nonce
   in R1 packet.  If the HIP host succeeds in authentication, HAP
   returns a positive response in R2 packet.  And the HIP connection is
   established between host and HAP.

4.3.  Initiating a communication

   When a HIP host initiates a connection to a new host, e.g. sends a
   TCP SYN packet in the HIP data packet to a new host, the host's HIP
   stack inserts a proxy address, which is gotten from registration
   procedure, into the HIP packet and routing the packet to the HAP
   which has the proxy address.  After the HIP service overlay received



Wang & Shen               Expires March 4, 2011                 [Page 7]


Internet-Draft          HIP Service Overlay study            August 2010


   an initial HIP packet, it searches whether the destination identifier
   has been attached, if found, HIP service overlay directs the packet
   to the HAP where destination host attached, then the HAP forwards
   packet to the final destination.

   In this specification, the HIP host does not need to initiate a HIP
   4-way handshake before establishing a transport connection, thus
   reducing the extra connection delay.

4.4.  Updating location

   When the location of a HIP host is changed, the HIP host MUST notify
   the HAP it attached for this change by HIP update, and then all the
   packages to this host will be forwarded to this new location.

   In this specification, the HIP host does not need to notify the
   location change to the communicating hosts directly, thus reducing
   the extra connection delay.

4.5.  Scalability and performance

   Theoretically, the HIP service overlay can be deployed in any static
   or dynamic topology.  For example, we can adopt a hierarchical
   topology, where the routing path is decided by the HIP prefix just
   like the PSTN network, but end to end connections in hierarchical
   network often traverse too many intermediate nodes, as a result, the
   connection gets high delay.  So we recommend more flat topology, such
   as some advanced DHT networks.  One hop DHT has the best performance,
   but it only supports very limited number of nodes, shouldn't be used
   to build a global HIP service overlay.  The constant hops DHT
   algorithms trade off between the scalability and performance, they
   can accommodate enough number of hosts and have relatively low search
   delay, Kelips is an eligible algorithm.

   Another scalability issue is caused by the truth that the HIP service
   overlay forwards all of the traffic either the control plane or the
   data plane.  Despite one $1000 pc server can handle several Gbps IP
   traffic, but the bandwidth consumption of client PCs or other
   terminal equipments increases fast than before, so all the traffic
   pass through the HIP service overlay may be costly.  We suggest that
   only the selected services can be deployed on the top of HIP service
   overlay, the HIP host can download the valid HIP prefix of the HIP
   service overlay, then if the protocol stack receive a socket send
   request, it can check if the destination address match an existing
   HIP service overlay prefix and sends the packet to a proper next hop.

   We are doing prototype for the performance measure.




Wang & Shen               Expires March 4, 2011                 [Page 8]


Internet-Draft          HIP Service Overlay study            August 2010


5.  Acknowledgements

   This HIP service overlay is based on ideas coming from conversations
   and discussions with a number of people in the HIP and HIPRG
   communities.


6.  IANA Considerations

   This memo includes no request to IANA.

   All drafts are required to have an IANA considerations section (see
   the update of RFC 2434 [I-D.narten-iana-considerations-rfc2434bis]
   for a guide).  If the draft does not require IANA to do anything, the
   section contains an explicit statement that this is the case (as
   above).  If there are no requirements for IANA, the section will be
   removed during conversion into an RFC by the RFC Editor.


7.  Security Considerations

   TBD.


8.  References

8.1.  Normative References

   [Hi3]      Nikander, P., Arkko, J., and B. Ohlman, "Host Identity
              Indirection Infrastructure (Hi3)", 2004.

   [KELIPS]   Gupta, Indranil., Birman, Ken., Linga, Prakash., Demers,
              Al., and Robbert. Renesse, "Building an Efficient and
              Stable P2P DHT Through Increased Memory and Background
              Overhead", 2003.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC4423]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
              (HIP) Architecture", RFC 4423, May 2006.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
              "Host Identity Protocol", RFC 5201, April 2008.

   [i3]       Stoica, Ion., Adkins, Daniel., Zhuang, Shelley., and
              Scott. Shenker, "Internet Indirection Infrastructure",
              2002.



Wang & Shen               Expires March 4, 2011                 [Page 9]


Internet-Draft          HIP Service Overlay study            August 2010


8.2.  Informative References

   [I-D.narten-iana-considerations-rfc2434bis]
              Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs",
              draft-narten-iana-considerations-rfc2434bis-09 (work in
              progress), March 2008.

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

   [RFC3552]  Rescorla, E. and B. Korver, "Guidelines for Writing RFC
              Text on Security Considerations", BCP 72, RFC 3552,
              July 2003.


Appendix A.  Additional Stuff


Authors' Addresses

   Jun Wang (editor)
   ZTE Corporation
   Nanjing,   210012
   China

   Phone: +86 25 52877648
   Email: wang.jun17@zte.com.cn


   Jiong Shen
   ZTE Corporation
   Nanjing,   210012
   China

   Phone: +86 25 52877648
   Email: shen.jiong@zte.com.cn














Wang & Shen               Expires March 4, 2011                [Page 10]


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