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, . [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]