Host Identity Protocol (HIP) L. Eggert
Research Group NEC
Internet-Draft J. Laganier
Expires: April 18, 2005 LIP / Sun Microsystems
October 18, 2004
HIP Resolution and Rendezvous Problem Description
draft-eggert-hiprg-rr-prob-desc-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668. This document may not be modified, and derivative works of
it may not be created, except to publish it as an RFC and to
translate it into languages other than English.
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 April 18, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document investigates the design space for resolution and
rendezvous mechanisms for the Host Identity Protocol (HIP.) It
identifies and describes specific issues that HIP resolution and
rendezvous mechanisms should address. These issues include
Eggert & Laganier Expires April 18, 2005 [Page 1]
Internet-Draft HIP R&R Problem Description October 2004
dependencies on the DNS, lack of support for direct communication
based on host identities, lack of a reverse lookup mechanism for host
identities, and DNS and node rendezvous.
This document does not propose specific resolution and rendezvous
mechanisms. Different alternative solutions will be described and
discussed in companion documents. These documents should analyze if
and to what degree the specific proposals they present address the
issues identified here.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. HIP Resolution and Rendezvous . . . . . . . . . . . . . . . . 4
2.1 Issue 1: DNS Dependency . . . . . . . . . . . . . . . . . 5
2.2 Issue 2: Direct Communication . . . . . . . . . . . . . . 6
2.3 Issue 3: Reverse Lookup . . . . . . . . . . . . . . . . . 6
2.4 Issue 4: DNS Rendezvous . . . . . . . . . . . . . . . . . 6
2.5 Issue 5: Node Rendezvous . . . . . . . . . . . . . . . . . 7
2.5.1 Issue 5.1: Middlebox Traversal . . . . . . . . . . . . 7
2.5.2 Issue 5.2: Location Privacy . . . . . . . . . . . . . 7
2.5.3 Issue 5.3: Mobility and Multihoming . . . . . . . . . 8
2.5.4 Issue 5.4: Interoperation with Legacy Nodes . . . . . 8
3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.1 Normative References . . . . . . . . . . . . . . . . . . . 10
6.2 Informative References . . . . . . . . . . . . . . . . . . 10
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Document Revision History . . . . . . . . . . . . . . . . . . 11
Intellectual Property and Copyright Statements . . . . . . . . 12
Eggert & Laganier Expires April 18, 2005 [Page 2]
Internet-Draft HIP R&R Problem Description October 2004
1. Introduction
The current Internet uses two global namespaces: domain names and IP
addresses. The first namespace - domain names - has a single use.
Domain names, usually simply called names, are symbolic identifiers
for sets of numeric IP addresses, chosen for their mnemonic
properties: humans need to interact with them.
IP addresses form the Internet's second global namespace. They have
two uses. First, they are topological locators for network
attachment points, addressing a specific location in the network
topology. Their second use is as identifiers for the network
interfaces - and thus nodes - that attach to the addressed locations.
In this role as identifiers, IP addresses loose their topological
meaning and become simple names. Routing and other network-layer
mechanisms use the locator aspects of IP addresses. Transport-layer
protocols and mechanisms typically use IP addresses in their role as
names for communication endpoints. (Saltzer [6] discusses these
naming concepts in detail.)
This dual use of IP addresses as both names and locators limits the
flexibility of the Internet architecture. For example, the use of
topology-dependent IP addresses as symbolic names for communication
endpoints complicates node mobility. A mobile node changes its
points of network attachment and hence its IP addresses dynamically.
At the transport layer, this causes the logical endpoints of
communication sessions - which are based on IP addresses - to change
dynamically as well. Many of the Internet's transport protocols do
not support changing the logical endpoints of established
communication sessions. Arguably, they should not, because the
identities of the communicating nodes have not changed, simply their
points of network attachment.
The Host Identity Protocol (HIP) architecture defines a third global
namespace [1]. The new host identity namespace decouples the name
and locator roles currently filled by IP addresses. Host identities
take over the naming role, while IP addresses become pure locators.
With HIP, transport-layer mechanisms operate on host identities
instead of using IP addresses as endpoint names. Network-layer
mechanisms continue to use IP addresses as pure locators.
Due to the introduction of a new global namespace, HIP also affects
the Internet's name resolution services. The Domain Name System
(DNS) is currently the Internet's only global resolution service [7].
The DNS provides a two-way lookup service between domain names and
their set of corresponding IP addresses. HIP requires an additional
resolution step. Domain names now map into sets of host identities,
which in turn map into sets of IP addresses.
Eggert & Laganier Expires April 18, 2005 [Page 3]
Internet-Draft HIP R&R Problem Description October 2004
The additional HIP resolution step complicates the rendezvous
procedure by which two nodes establish communication, i.e., the steps
they need to perform until they obtain a peer's IP addresses. In the
current Internet, the DNS maps the domain name of a target remote
node directly into its set of IP addresses, which the local node may
then use to address packets. The address of each node's DNS server
is either manually configured or dynamically discovered (e.g., using
DHCP [8]). When no DNS server is configured or has been discovered,
nodes can still communicate by using IP addresses directly.
With HIP, the rendezvous procedure and resolution mechanisms are
becoming more complex. The various alternatives for performing name
and identity resolutions lead to rendezvous procedures that offer
significantly different characteristics. This document discusses the
limitations of the current HIP architecture and describes the general
design space for alternative resolution and rendezvous mechanisms.
It does not, however, present any specific resolution and rendezvous
mechanisms. Specific alternatives will be described and discussed in
companion documents.
This problem description document and its companion documents that
describe specific resolution and rendezvous approaches obsolete prior
contributions, i.e., [9].
2. HIP Resolution and Rendezvous
As mentioned in Section 1, HIP complicates the Internet's simple
resolution and rendezvous procedures. Currently, nodes use DNS
servers at well-known IP addresses to resolve domain names into IP
addresses, which they can then use to address packets. The top
illustration in Figure 1 shows this DNS resolution procedure. It
also shows the reverse DNS resolution, which resolves an IP address
back into its associated domain name.
With HIP, domain names map into sets of host identities, each of
which maps into sets of IP addresses. This results in a logical
two-step resolution process before a node knows the IP addresses
associated with target domain name. The middle illustration in
Figure 1 shows this two-step process. To maintain application
compatibility, the first mapping - from names into host identities -
should remain in the DNS. For the second mapping - from host
identities into IP addresses - various alternatives are possible.
Logically, this HIP lookup is a completely separate operation from
the initial DNS lookup. A reverse HIP lookup is also useful; it maps
IP addresses back into their associated host identities.
Eggert & Laganier Expires April 18, 2005 [Page 4]
Internet-Draft HIP R&R Problem Description October 2004
+--------+ DNS lookup +---------+
| domain |------------------------------------------->| IP |
| name |<-------------------------------------------| address |
+--------+ reverse DNS lookup +---------+
+--------+ DNS lookup +----------+ HIP lookup +---------+
| domain |--------------->| host |--------------->| IP |
| name |<---------------| identity |<---------------| address |
+--------+ reverse DNS +----------+ reverse HIP +---------+
lookup lookup
+--------+ DNS lookup +--------------------+
| domain |-------------------------------->| host | IP |
| name |<--------------------------+ | identity | address |
+--------+ reverse DNS lookup | +--------------------+
| |
+---------------------+
Figure 1: Domain name resolution without HIP (top), logical lookups
with HIP (middle) and with the current HIP architecture (bottom)
Current HIP prototypes choose to maintain the second mapping between
host identities and IP addresses in the DNS as well. One proposal
simply stores a node's host identities alongside its IP addresses in
the node's DNS record [2]. A DNS resolution of a domain name thus
returns a pair of host identities and IP addresses, as shown in the
bottom illustration of Figure 1. This simplistic approach creates
several problems that the following sections discuss in more detail.
Companion documents to this document that propose specific mechanisms
for resolution and rendezvous should investigate if and to what
degree the individual proposals address these issues. [Comment.1]
2.1 Issue 1: DNS Dependency
One critical problem of storing host identities in a node's DNS
record, as shown in the bottom of Figure 1, is that this approach
creates a dependency between HIP and the DNS. To communicate with
HIP under this approach, DNS resolution of a domain name is required
to obtain a peer's host identities and IP addresses. It is not
possible to communicate with HIP based on host identities alone - no
direct resolution mechanism exists to map host identities into IP
addresses.
This is a drastic change from the current Internet, where the DNS is
an optional component and communication can occur based on IP
addresses alone.
Eggert & Laganier Expires April 18, 2005 [Page 5]
Internet-Draft HIP R&R Problem Description October 2004
2.2 Issue 2: Direct Communication
Storing host identities in a node's DNS record causes a second,
related issue: even if a node already knows the host identity of a
peer, it cannot use this host identity to initiate communication. It
needs to know and resolve the peer's domain name to obtain the peer's
IP addresses.
HIP allows protocols and services above the network layer to use host
identities instead of IP-address-based names. Consequently, with
HIP, host identities should replace many uses of IP addresses above
the network layer. For example, applications and users should be
able to substitute host identities wherever they now use IP
addresses. A direct mechanism to resolve host identities into IP
addresses, i.e., one that does not depend on knowledge of the
corresponding domain name, is required to enable this transparency.
(Communication based on IP addresses alone is still possible with the
simplistic HIP lookup, as shown on the bottom of Figure 1, but
obviously will not incur the benefits of using HIP.)
2.3 Issue 3: Reverse Lookup
A third problem with the simplistic HIP resolution shown in the
bottom of Figure 1 is that the DNS currently provides no mechanism to
perform a reverse HIP lookup, i.e., determine the domain name of a
node based on its host identity. Only the traditional reverse DNS
lookup exists, which operates on IP addresses, not host identities.
A reverse HIP lookup would need to be emulated by performing a
reverse lookup on an IP address, and a forward DNS lookup on the
resulting name to obtain the host identities. This is cumbersome.
Alternatively, reverse lookup capability could be added to the DNS
through a new root, similar to how it provides reverse lookups on IP
addresses. This approach, however, is problematic, because it maps
resolution of a flat namespace into an hierarchical name system and
also creates additional dependencies between HIP and the DNS [2].
2.4 Issue 4: DNS Rendezvous
Rendezvous with the DNS infrastructure is another issue with the
simplistic HIP lookup. It may be useful to communicate with DNS
servers using HIP instead of IP, i.e., access a DNS server through
its well-known host identity instead of its well-known IP address.
This would enable DNS servers to benefit from HIP's mobility,
multihoming and security mechanisms.
The simplistic HIP lookup (bottom of Figure 1) requires a deployed
Eggert & Laganier Expires April 18, 2005 [Page 6]
Internet-Draft HIP R&R Problem Description October 2004
DNS infrastructure.
2.5 Issue 5: Node Rendezvous
Arguably the largest issue with the current HIP approach of using the
DNS to store both the host identities and IP addresses associated
with a name is rendezvous between nodes. As mentioned before, the
rendezvous procedure encompasses all required steps for two nodes to
obtain enough information about the other peer to be able to address
packets to it. In most cases, this involves determining the set of a
peer's IP addresses.
Without HIP, node rendezvous involves a DNS lookup of a peer's domain
name to obtain its IP addresses. If the peer's addresses are known
already, a host may skip the rendezvous procedure and address packets
to it directly.
Consequently, different resolution mechanisms can have significantly
different effects on node rendezvous. The following sections
describe specific issues in detail.
2.5.1 Issue 5.1: Middlebox Traversal
A different document discusses middlebox traversal of HIP traffic
[3], focusing on the current specification of the HIP protocols.
This document discusses two separate problems: middlebox traversal of
the HIP base exchange - i.e., the current rendezvous procedure - and
traversal of HIP data traffic, which is currently carried inside
IPsec.
New resolution and rendezvous solutions, which may consequently
change the current base exchange, must consider how they interact
with various middleboxes [10].
2.5.2 Issue 5.2: Location Privacy
Internet users are becoming more sensitive to privacy concerns. For
example, the introduction of IPv6 already caused concern because of
the possibility to trace users based on the unique EUI48 NIC
identifiers included in their global IPv6 addresses. HIP may
potentially worsen the situation through its use of cryptographic,
semi-permanent identifiers.
One approach to mitigating these concerns is through the periodic
regeneration of host identities. Instead of reusing the same
identity, nodes will generate new identities on the fly, similar to
RFC 3041 [11]. This approach makes it more difficult to correlate a
node's HIP associations and may thus reduce traceability concerns. A
Eggert & Laganier Expires April 18, 2005 [Page 7]
Internet-Draft HIP R&R Problem Description October 2004
second approach to increasing location privacy is concealing the IP
addresses of two communicating nodes from one another. The
SPI-multiplexed NAT (SPINAT) described as part of the BLIND framework
offers this ability [12].
New resolution and rendezvous solutions should consider if and how
they may provide location privacy or integrate with other mechanisms
that do.
2.5.3 Issue 5.3: Mobility and Multihoming
HIP already includes mechanisms that allow a peer to signal its peers
when its IP addresses have changed [4]. These mechanisms, however,
require an already-established HIP association. For establishing new
HIP associations after a move, the regular rendezvous procedure must
complete. Consequently, a node must update its IP addresses after a
move in whatever mechanism provides rendezvous service.
When host identities and IP addresses are stored in the DNS, dynamic
DNS may provide a simple update mechanism [13][14]. However, the
caching mechanisms of the DNS and to a lesser degree implementation
issues with some current DNS servers make frequent dynamic DNS
updates, i.e., support for highly mobile nodes, problematic.
A two-step resolution procedure, as described in Section 2 or
dedicated external rendezvous servers [5] can improve HIP operation
in such cases by offering a range of different update/lookup
operations with different performance trade-offs.
One drawback of rendezvous servers is that they may introduce
triangle routing: packets no longer follow the direct path between
two peers, but instead flow through the rendezvous server. Besides
increasing the end-to-end latency, this may decrease communication
reliability. The two step resolution process, however, may be unable
to support very high-rate mobility due to caching - it is impractical
to translate from host identity to current IP address for every
single packet.
New resolution and rendezvous solutions should discuss the trade-offs
between update and lookup performance and routing inefficiencies
versus move frequency.
2.5.4 Issue 5.4: Interoperation with Legacy Nodes
With HIP, node rendezvous breaks down into two distinct cases:
rendezvous between two HIP nodes and rendezvous between a HIP node
and a legacy non-HIP node. Specific resolution mechanisms for host
identities may affect the two rendezvous cases in different ways.
Eggert & Laganier Expires April 18, 2005 [Page 8]
Internet-Draft HIP R&R Problem Description October 2004
For example, the current rendezvous server extensions to the base HIP
protocol [5] do not support communication with legacy nodes, because
they store the addresses of rendezvous servers in new "RVS" DNS
record types that legacy nodes do not support [2]. For communication
between two HIP nodes, this approach is successful, because they can
use the RVS records to establish communication with the peer. A
legacy node, however, expects to receive A or AAAA records that
contain IP addresses the peer is directly reachable at.
New resolution and rendezvous solutions for HIP nodes should consider
how they may provide rendezvous functionality with legacy non-HIP
nodes. There are two aspects to this question. First, whether
resolution mechanisms allow rendezvous with non-HIP nodes at all, and
second, whether they can offer some of the benefits of HIP
communication to non-HIP nodes as well.
3. Conclusion
This document described the design space of HIP resolution and
rendezvous mechanisms and described a number of issues that the
current architecture fails to support adequately. These issues
include dependencies on the DNS, lack of support for direct
communication based on host identities, lack of a reverse lookup
mechanism for host identities, and DNS and node rendezvous.
This document does not propose specific resolution and rendezvous
solutions; this will occur in future companion documents that should
also describe how the solutions they propose address the issues
identified here.
4. Security Considerations
The security aspects of HIP resolution and rendezvous mechanisms are
currently being investigated and will be included in a future
revision of this document.
5. Acknowledgments
Part of this work is a product of the Ambient Networks project,
partially supported by the European Commission under its Sixth
Framework Programme. It is provided "as is" and without any express
or implied warranties, including, without limitation, the implied
warranties of fitness for a particular purpose. The views and
conclusions contained herein are those of the authors and should not
be interpreted as necessarily representing the official policies or
endorsements, either expressed or implied, of the Ambient Networks
project or the European Commission.
Eggert & Laganier Expires April 18, 2005 [Page 9]
Internet-Draft HIP R&R Problem Description October 2004
6. References
6.1 Normative References
[1] Moskowitz, R., "Host Identity Protocol Architecture",
draft-moskowitz-hip-arch-06 (work in progress), June 2004.
[2] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
Domain Name System (DNS) Extensions", draft-nikander-hip-dns-00
(work in progress), July 2004.
[3] Stiemerling, M., "Problem Statement: HIP operation over Network
Address Translators", draft-stiemerling-hip-nat-01 (work in
progress), July 2004.
[4] Nikander, P., "End-Host Mobility and Multi-Homing with Host
Identity Protocol", draft-nikander-hip-mm-02 (work in progress),
July 2004.
[5] Eggert, L., "Host Identity Protocol (HIP) Rendezvous
Extensions", draft-eggert-hip-rvs-00 (work in progress), July
2004.
6.2 Informative References
[6] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[7] Mockapetris, P., "Domain names - concepts and facilities", STD
13, RFC 1034, November 1987.
[8] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997.
[9] Eggert, L., "Host Identity Protocol (HIP) Rendezvous
Mechanisms", draft-eggert-hip-rendezvous-01 (work in progress),
July 2004.
[10] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues",
RFC 3234, February 2002.
[11] Narten, T. and R. Draves, "Privacy Extensions for Stateless
Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[12] Ylitalo, J. and P. Nikander, "BLIND: A Complete Identity
Protection Framework for End-points", Proc. Twelfth
International Workshop on Security Protocols, Cambridge,
England, April 2004.
Eggert & Laganier Expires April 18, 2005 [Page 10]
Internet-Draft HIP R&R Problem Description October 2004
[13] Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[14] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
Editorial Comments
[] LE: The authors would appreciate feedback on the list of
issues; specifically, whether it is complete and whether
all of the currently identified issues are valid.
Authors' Addresses
Lars Eggert
NEC Network Laboratories
Kurfuerstenanlage 36
Heidelberg 69115
Germany
Phone: +49 6221 90511 43
Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/
Julien Laganier
Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL)
180, Avenue de l'Europe
Saint Ismier CEDEX 38334
France
Phone: +33 476 188 815
EMail: ju@sun.com
URI: http://research.sun.com/
Appendix A. Document Revision History
+-----------+-------------------------------------------------------+
| Revision | Comments |
+-----------+-------------------------------------------------------+
| 00 | Initial version. This document and its future |
| | companion documents that will propose and analyze |
| | specific solutions obsolete prior contributions [9]. |
+-----------+-------------------------------------------------------+
Eggert & Laganier Expires April 18, 2005 [Page 11]
Internet-Draft HIP R&R Problem Description October 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Eggert & Laganier Expires April 18, 2005 [Page 12]