Network Working Group J. Melen
Internet-Draft J. Ylitalo
Intended status: Experimental P. Salmela
Expires: January 29, 2010 Ericsson Research NomadicLab
July 28, 2009
Host Identity Protocol-based Mobile Proxy
draft-melen-hip-proxy-01
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 January 29, 2010.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Melen, et al. Expires January 29, 2010 [Page 1]
Internet-Draft HIP Mobile Proxy July 2009
Abstract
This drafts defines a HIP proxy node that enables non-HIP host to
communicate with HIP host through a proxy node.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HIP-Proxy Architecture . . . . . . . . . . . . . . . . . . . . 4
2.1. Assigning Host Identity to non-HIP host . . . . . . . . . 4
2.2. Registering Host Identity IP address mapping to RVS . . . 4
2.3. Registering Host Identity to DNS . . . . . . . . . . . . . 4
3. Packet processing . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Opportunistic I1 . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Rendezvous node . . . . . . . . . . . . . . . . . . . 5
3.1.2. HIP-proxy or HIP-node . . . . . . . . . . . . . . . . 5
3.2. I1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3. R1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.4. I2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.5. R2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.6. Data packets . . . . . . . . . . . . . . . . . . . . . . . 6
3.6.1. Sending data over ESP SA . . . . . . . . . . . . . . . 6
3.6.2. Receiving data over ESP SA . . . . . . . . . . . . . . 6
4. Parameters and packet formats . . . . . . . . . . . . . . . . 7
4.1. Proxy information parameter . . . . . . . . . . . . . . . 7
5. Security Considerations . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
8. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Melen, et al. Expires January 29, 2010 [Page 2]
Internet-Draft HIP Mobile Proxy July 2009
1. Introduction
The Host Identity Protocol (HIP) [RFC5201] has been designed to allow
hosts to preserve existing security associations and higher-layer
protocol sessions by defining host mobility and multihoming
mechanisms [RFC5206]. Specifically, a mobile or multihomed host that
changes its IP address, or acquires new addresses, can securely
notify its corresponding peers of the new address(es). Similarly, a
mobile HIP-aware host can update information about its current IP
address(es) by updating records in HIP Rendezvous Servers [RFC5204]
or other name services.
This draft describes HIP protocol extensions that allow a non-HIP
host to use the services of a HIP-aware proxy node and have a
capability to be mobile when moving together with the HIP-proxy node.
The HIP-proxy node functions as a middle node that will encapsulate
and decapsulate the packets that are destined to a HIP host or to a
non-HIP host behind another HIP-proxy.
The HIP proxy node MUST reside on the normal routing path of the
packets. HIP proxy node MAY also be aided by the DNS resolver in
order to resolve the destination host's host identity. While the
HIP-proxy resides on the routing path of the non-HIP host's outgoing
traffic, it MAY also function as a DNS proxy in which case all the
DNS queries will pass through it.
Melen, et al. Expires January 29, 2010 [Page 3]
Internet-Draft HIP Mobile Proxy July 2009
2. HIP-Proxy Architecture
This section describes the extensions for the basic HIP [RFC5201]
that are required to support proxying of the traffic.
2.1. Assigning Host Identity to non-HIP host
The HIP proxy MAY generate a Host Identity for each legacy host it
will represent in the network. In this case, the HI is bound to a
certain IP address. The HIP proxy will create point-to-point tunnel
between the HIP-proxy and HIP end host. The generation of each new
Host identity MAY be triggered by DHCP or it MAY be generated
manually before hand
Alternatively, the HIP Proxy MAY generate a Host Identity for a group
of network hosts. in this case, the HI is bound to a certain network
prefix. The HIP-proxy will create point-to-multi-point tunnel
between the HIP-proxy and HIP end-host.
The difference on whether the to create a single host identity to
represent multiple hosts or whether to create a one identity per IP
address is a trade-off between the whether the HIP-proxy needs to
carry the IP header between the HIP-Proxy and the HIP-node or not.
2.2. Registering Host Identity IP address mapping to RVS
HIP-proxy MAY register the non-HIP aware host's IP address in to
rendezvous server for HIP host's using the same rendezvous system to
reach the non-HIP host through its proxy by using a opportunistic
mode where they embed the address in to the destination HIT field.
The rendezvous system SHOULD verify that the HIP-proxy is authorized
to add the mapping between non HIP IP address and HI before accepting
the registration of the mapping. Rendezvous system SHOULD NOT add
any HI non-HIP IP mappings that it cannot verify to belong to that
HIP-proxy as this might cause unwanted behavior in the routing
system.
2.3. Registering Host Identity to DNS
The HIP-proxy MAY register the Host Identity (HI) resource record in
to the DNS as defined in the [RFC5205]. The HIP-proxy will associate
the HI with the FQDN of the non-HIP host. When the HI is resolved
from the DNS the resolving host will get the HI and address of the
host or HI and address of the rendezvous server of the HIP-proxy
depending on the local configuration policy.
Melen, et al. Expires January 29, 2010 [Page 4]
Internet-Draft HIP Mobile Proxy July 2009
3. Packet processing
3.1. Opportunistic I1
3.1.1. Rendezvous node
The rendezvous node parses the PINFO_RESPONDER parameter and searches
all the registered HIP-proxy client contexts through for an prefix
that was in the received PINFO_RESPONDER parameter.
3.1.2. HIP-proxy or HIP-node
The responder verifies the I1 as specified in the [RFC5201]. As a
additional step the responder MUST verify that the prefix included in
to the PINFO_RESPONDER parameter of I1 packet contains a prefix that
belongs some Host Identity which the host owns
3.2. I1
The responder verifies the I1 as specified in the [RFC5201]. As a
additional step the responder MAY verify that the prefix included in
to the PINFO_RESPONDER parameter of I1 packet contains a prefix that
belongs to the host identity represented by the destination HIT field
in the HIP protocol header.
3.3. R1
The initiator verifies the R1 as specified in the [RFC5201]. As a
additional step the initiator MUST verify that the prefix included in
to the PINFO_RESPONDER parameter of R1 packet contains a prefix that
it sent out in the PINFO of the I1 packet.
After parsing and verification of the R1 packet the initiator will
add mapping between the HI and the prefix provided by the
PINFO_RESPONDER in to the HIP association context.
3.4. I2
The responder verifies the I2 as specified in the [RFC5201]. As a
additional step the responder MUST parse the prefix included in to
the PINFO_INITIATOR parameter of I2 packet and add a mapping between
the HI and prefix in to the HIP association context.
3.5. R2
The intiator verifies the R2 as specified in the [RFC5201]. No
additional information is included in to the R2 message.
Melen, et al. Expires January 29, 2010 [Page 5]
Internet-Draft HIP Mobile Proxy July 2009
3.6. Data packets
3.6.1. Sending data over ESP SA
When receiving data packets from non-HIP node that are destined to a
host that is either HIP or another HIP-proxy node the HIP-proxy will
capture the packet and remove the IP header and send it through the
ESP SA.
3.6.2. Receiving data over ESP SA
When receiving data packets from ESP SA the HIP or HIP-proxy node
will reconstruct the original IP header and send it back to IP stack
for further processing.
Melen, et al. Expires January 29, 2010 [Page 6]
Internet-Draft HIP Mobile Proxy July 2009
4. Parameters and packet formats
In this section we define the additional HIP parameters needed to
carry the non-HIP host information between the two proxies or proxy
or HIP node.
4.1. Proxy information parameter
The Proxy Information (PINFO) parameter is used to carry the IPv4 or
IPv6 address the non-HIP node is using. Thus, the parameter will
have different type value depending on whether the parameter is
carrying the information of the initiator proxy's network or
information of the responder proxy's network.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Prefix length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Prefix |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA:
PINFO_INITIATOR: 989 =
(2^9 + ... + 2^6 + 2^4 + ... + 2^2 + 2^0)
PINFO_RESPONDER: 991 =
(2^9 + ... + 2^6 + 2^4 + ... + 2^0)
]
Length 20
Prefix Length Length of the prefix or length of netmask
Prefix an IPv6 prefix or an IPv4 address in "IPv4-Mapped
IPv6 address" format
Melen, et al. Expires January 29, 2010 [Page 7]
Internet-Draft HIP Mobile Proxy July 2009
5. Security Considerations
Address theft by registering a invalid non-HIP IP address HI mapping.
The Rendezvous node should verify that the IP address claimed by the
proxy is really residing behind HIP-proxy.
Melen, et al. Expires January 29, 2010 [Page 8]
Internet-Draft HIP Mobile Proxy July 2009
6. IANA Considerations
Melen, et al. Expires January 29, 2010 [Page 9]
Internet-Draft HIP Mobile Proxy July 2009
7. Acknowledgments
A number of people have contributed to the text and ideas. The list
of these people include Pekka Nikander, Petri Jokela, Raimo
Vuopionpera, and Jari Arkko. Our apologies to anyone whose name is
missing.
Melen, et al. Expires January 29, 2010 [Page 10]
Internet-Draft HIP Mobile Proxy July 2009
8. Normative References
[RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson,
"Host Identity Protocol", RFC 5201, April 2008.
[RFC5204] Laganier, J. and L. Eggert, "Host Identity Protocol (HIP)
Rendezvous Extension", RFC 5204, April 2008.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
[RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-
Host Mobility and Multihoming with the Host Identity
Protocol", RFC 5206, April 2008.
Melen, et al. Expires January 29, 2010 [Page 11]
Internet-Draft HIP Mobile Proxy July 2009
Authors' Addresses
Jan Melen
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: jan.melen@nomadiclab.com
Jukka Ylitalo
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: jukka.ylitalo@nomadiclab.com
Patrik Salmela
Ericsson Research NomadicLab
JORVAS FIN-02420
FINLAND
Phone: +358 9 299 1
Email: patrik.salmela@nomadiclab.com
Melen, et al. Expires January 29, 2010 [Page 12]