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

Versions: 00

HIP Research Group                                                Z. Cao
Internet-Draft                                                    F. Cao
Intended status: Informational                                   H. Deng
Expires: September 7, 2011                                  China Mobile
                                                           March 6, 2011


       Communication between a HIP-enabled Host and a Legacy Host
                     draft-cao-hiprg-legacy-host-00

Abstract

   This document describes a way to support a HIP-enabled host to have
   the ability to communicate with legacy hosts.  By leveraging a proxy
   to bridge the communication between HIP host and non-HIP hosts, this
   document does not need the extensions to the HIP protocol.

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 September 7, 2011.

Copyright Notice

   Copyright (c) 2011 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.



Cao, et al.             Expires September 7, 2011               [Page 1]


Internet-Draft               HIP Legacy Host                  March 2011


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Proposed Mechanism  . . . . . . . . . . . . . . . . . . . . . . 4
     2.1.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . 4
     2.2.  Proposal Walkaround . . . . . . . . . . . . . . . . . . . . 4
     2.3.  Host Identity Management  . . . . . . . . . . . . . . . . . 5
   3.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
   5.  Normative References  . . . . . . . . . . . . . . . . . . . . . 8
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9








































Cao, et al.             Expires September 7, 2011               [Page 2]


Internet-Draft               HIP Legacy Host                  March 2011


1.  Introduction

   HIP protocol [RFC5201] establishes an IP-layer communications context
   (called HIP association) between two hosts prior to communications.
   It also defines a packet format and procedures for updating an active
   HIP association.  HIP offers many well-defined features to end hosts
   such as security, integrity protection, mobility and multi-homing.

   HIP was designed to work with unmodified applications[RFC5338].  To
   ease incremental deployment, it is important to support the
   transition of legacy hosts towards HIP-enabled host.  In the first
   phrase of this transition, some legacy hosts are turning on their
   abilities to support HIP, but most of them, especially internet
   servers have not been HIP-aware.  There should be a mechanism that
   supports a HIP-enable host to communicate with non-HIP enabled legacy
   hosts.

   [I-D.melen-hip-proxy] defines HIP protocol extensions that allow a
   non-HIP host to use the services of a HIP-aware proxy node and have
   capabilities to communicate with a HIP host.
   [I-D.irtf-hiprg-proxies] investigates the HIP proxies for both
   directions.  The scenario introduced in this document is slightly
   different in that the proxy is located in the local network when
   serving the HIP host to communicate with the non-HIP host.

   This document describes a way to support a HIP-enabled host to have
   the ability to communicate with legacy hosts.  By leveraging a proxy
   to bridge the communication between HIP host and non-HIP hosts, this
   document does not need the extensions to the HIP protocol.






















Cao, et al.             Expires September 7, 2011               [Page 3]


Internet-Draft               HIP Legacy Host                  March 2011


2.  Proposed Mechanism

2.1.  Overview

   In [I-D.melen-hip-proxy], HIP-proxy generates a Host Identity for
   each legacy host it will represent in the network.  Instead of
   creating a static identity for each legacy host, this document
   specifies a mechanism of proxy dynamically assigning a host identity
   for each non-HIP host.  The proxy will serve as the end point of the
   HIP base exchange.  After the HIP association is established, the
   proxy will be in charge of translation between the HIP packet and
   legacy IP packets.  The proxy will encapsulates the HIP packet
   payload into the IP header, so that the non-HIP host will participate
   into the communicate as usual.  [I-D.irtf-hiprg-proxies]

   This solution does not introduce any HIP protocol extention.  The
   proxy that intercepts the communication will take the responsibility
   of holding the communication.  Both the HIP aware initiator and non-
   HIP responder will be kept transparent about the proxy.

2.2.  Proposal Walkaround

 +----------+                  +---------+               +-------------+
 | HIP Host |                  |  Proxy  |               | non-HIP host|
 +----------+                  +---------+               +-------------+
      | 1.DNS Query QTYPE=HIP       |                           |
      |---------------------------->|                           |
      | 2.DNS Response HIT&HI       |                           |
      |<----------------------------|                           |
      | 3.DNS Query QTYPE=A         |                           |
      |---------------------------->|                           |
      | 4.DNS Response IP-A         |                           |
      |<----------------------------|                           |
      | 5-8.                        |                           |
      | BASE EXCHANGE(I1,R1,I2,R2)  |                           |
      |<--------------------------->|                           |
      |                             |                           |
      |9.HIP PACKET FORMAT          | 10.  LEGACY IP PACKET     |
      |---------------------------->|-------------------------->|
      |                             |                           |
      |11.HIP PACKET FORMAT         | 12.  LEGACY IP PACKET     |
      |<----------------------------|<--------------------------|
      |                             |                           |
      |                             |                           |


                       Figure 1: Proposed Mechanism




Cao, et al.             Expires September 7, 2011               [Page 4]


Internet-Draft               HIP Legacy Host                  March 2011


   Most applications translate the domain name into one of more IP
   addresses before data plane communication.  HIP is no exception.  The
   HIP-enabled host first launches the DNS query to retrieve the remote
   host's HI/HIT or RVS address.  Without knowing if the remote host
   supports HIP-based exchange, the HIP host is expecting to receiving
   the remote host HIP based Identities.

   The proxy, which intercepts the DNS query, will iteratively forward
   the query to the global DNS to find an answer.  If the responder is
   HIP enabled, it will have its HI or HIT registered in the DNS and the
   proxy will get an answer.  However, if the responder is not HIP
   aware, and only have type A or AAAA records in the DNS system, the
   query for QTYPE=HIP will fail.  On detecting that the responder is
   not HIP aware, the DNS proxy will use a temporary HI/HIT (T-ID)
   generated locally and reply this temporary HI/HIT to the initiator.
   The proxy will associate the T-ID with the IP address of the
   responder.  After the HIP RR query reponse, the Type-A query response
   is followed, via which the initiator get the the IP address of the
   proxy node.

   The HIP base exchange will proceed between the initiator and the
   proxy (step.5-8).  Then, the HIP association is established between
   the initiator and the proxy, i.e., between the host's HI and the
   temporary HI assigned to the reponder by the proxy.  If the initiator
   starts data communication towards the responder, the proxy on the
   data path will be responsible for the tranlation between HIP packets
   and IP packets.  First, the proxy will de-capsulate the packet and
   decrypte the packet to get the original IP packet inside.  By
   inspecting the HIP header after the IP header, the proxy is aware of
   the destination's HIT/LSI.  If the HIT and LSI is mapped to one of
   the responder's IP address, the proxy will translate the packet with
   the destination address as the responder's IP address, and source
   address as the proxy IP address.  The destination port is kept
   unchanged, but the source port can be dynamically assigned.

2.3.  Host Identity Management

   TBD.













Cao, et al.             Expires September 7, 2011               [Page 5]


Internet-Draft               HIP Legacy Host                  March 2011


3.  Security Considerations

   TBD.
















































Cao, et al.             Expires September 7, 2011               [Page 6]


Internet-Draft               HIP Legacy Host                  March 2011


4.  IANA Considerations

   This document does not require any IANA actions.
















































Cao, et al.             Expires September 7, 2011               [Page 7]


Internet-Draft               HIP Legacy Host                  March 2011


5.  Normative References

   [I-D.irtf-hiprg-proxies]
              Zhang, D., Xu, X., and S. Shen, "Investigation in HIP
              Proxies", draft-irtf-hiprg-proxies-01 (work in progress),
              October 2010.

   [I-D.melen-hip-proxy]
              Melen, J., Ylitalo, J., and P. Salmela, "Host Identity
              Protocol-based Mobile Proxy", August 2009,
              <draft-melen-hip-proxy-02.txt (work in progress)>.

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

   [RFC5205]  Nikander, P. and J. Laganier, "Host Identity Protocol
              (HIP) Domain Name System (DNS) Extensions", RFC 5205,
              April 2008.

   [RFC5338]  Henderson, T., Nikander, P., and M. Komu, "Using the Host
              Identity Protocol with Legacy Applications", RFC 5338,
              September 2008.





























Cao, et al.             Expires September 7, 2011               [Page 8]


Internet-Draft               HIP Legacy Host                  March 2011


Authors' Addresses

   Zhen Cao
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: zehn.cao@gmail.com


   Feng Cao
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: fengcao@chinamobile.com


   Hui Deng
   China Mobile
   28 Xuanwumenxi Ave,Xuanwu District
   Beijing 100053
   China

   Email: denghui@chinamobile.com
























Cao, et al.             Expires September 7, 2011               [Page 9]


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