Internet DRAFT - draft-cao-hiprg-legacy-host
draft-cao-hiprg-legacy-host
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]
