draft-ietf-hip-rvs-03.txt   draft-ietf-hip-rvs-04.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Internet-Draft DoCoMo Euro-Labs
Expires: January 12, 2006 L. Eggert Expires: April 13, 2006 L. Eggert
NEC NEC
July 11, 2005 October 10, 2005
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rvs-03 draft-ietf-hip-rvs-04
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware 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 becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2006. This Internet-Draft will expire on April 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document defines a rendezvous extension for the Host Identity This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes registration extension for initiating communication between HIP nodes
skipping to change at page 2, line 31 skipping to change at page 2, line 31
4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10 4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10
4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10 4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10
4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10 4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1 Normative References . . . . . . . . . . . . . . . . . . . 12 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
8.2 Informative References . . . . . . . . . . . . . . . . . . 12 8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Document Revision History . . . . . . . . . . . . . . . . . . 14 Intellectual Property and Copyright Statements . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 15
1. Introduction 1. Introduction
The Host Identity Protocol architecture [I-D.ietf-hip-arch] The Host Identity Protocol architecture [I-D.ietf-hip-arch]
introduces the rendezvous mechanism to help a HIP node to contact a introduces the rendezvous mechanism to help a HIP node to contact a
frequently moving HIP node. The rendezvous mechanism involves a frequently moving HIP node. The rendezvous mechanism involves a
third party, the rendezvous server (RVS), which serves as an initial third party, the rendezvous server (RVS), which serves as an initial
contact point ("rendezvous point") for its clients. The clients of contact point ("rendezvous point") for its clients. The clients of
an RVS are HIP nodes that use the HIP Registration Protocol an RVS are HIP nodes that use the HIP Registration Protocol
[I-D.koponen-hip-registration] to register their HIT->IP address [I-D.ietf-hip-registration] to register their HIT->IP address
mappings with the RVS. After this registration, other HIP nodes can mappings with the RVS. After this registration, other HIP nodes can
initiate a base exchange using the IP address of the RVS instead of initiate a base exchange using the IP address of the RVS instead of
the current IP address of the node they attempt to contact. the current IP address of the node they attempt to contact.
Essentially, the clients of an RVS become reachable at the RVS' IP Essentially, the clients of an RVS become reachable at the RVS' IP
addresses. Peers can initiate a HIP base exchange with the IP addresses. Peers can initiate a HIP base exchange with the IP
address of the RVS, which will relay this initial communication such address of the RVS, which will relay this initial communication such
that the base exchange may successfully complete. that the base exchange may successfully complete.
2. Terminology 2. Terminology
This section defines terms used throughout the remainder of this This section defines terms used throughout the remainder of this
specification. specification.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition to the terminology defined in [I-D.koponen-hip- In addition to the terminology defined in [I-D.ietf-hip-
registration], this document defines and uses the following terms: registration], this document defines and uses the following terms:
Rendezvous Service Rendezvous Service
A HIP service provided by a rendezvous server to its rendezvous A HIP service provided by a rendezvous server to its rendezvous
clients. The rendezvous server offers to relay some of the clients. The rendezvous server offers to relay some of the
arriving base exchange packets between the initiator and arriving base exchange packets between the initiator and
responder. responder.
Rendezvous Server (RVS) Rendezvous Server (RVS)
A HIP registrar providing rendezvous service. A HIP registrar providing rendezvous service.
skipping to change at page 4, line 51 skipping to change at page 4, line 51
| |<------R1-------| | | |<------R1-------| |
| I |-------I2------>| R | | I |-------I2------>| R |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 2: HIP base exchange with a rendezvous server. Figure 2: HIP base exchange with a rendezvous server.
Figure 2 shows a HIP base exchange involving a rendezvous server. It Figure 2 shows a HIP base exchange involving a rendezvous server. It
is assumed that HIP node R previously registered its HITs and current is assumed that HIP node R previously registered its HITs and current
IP addresses with the RVS, using the HIP registration protocol IP addresses with the RVS, using the HIP registration protocol
[I-D.koponen-hip-registration]. When the initiator I tries to [I-D.ietf-hip-registration]. When the initiator I tries to establish
establish contact with the responder R, it must send the I1 of the contact with the responder R, it must send the I1 of the base
base exchange either to one of R's IP addresses (if known via DNS or exchange either to one of R's IP addresses (if known via DNS or other
other means) or to one of R's rendezvous servers instead. Here, I means) or to one of R's rendezvous servers instead. Here, I obtains
obtains the IP address of R's rendezvous server from R's DNS record the IP address of R's rendezvous server from R's DNS record and then
and then sends the I1 packet of the HIP base exchange to RVS. RVS, sends the I1 packet of the HIP base exchange to RVS. RVS, noticing
noticing that the HIT contained in the arriving I1 packet is not one that the HIT contained in the arriving I1 packet is not one of its
of its own, MUST check its current registrations to determine if if own, MUST check its current registrations to determine if if needs to
needs to relay the packets. Here, it determines that the HIT belongs relay the packets. Here, it determines that the HIT belongs to R and
to R and then relays the I1 packet to the registered IP address. R then relays the I1 packet to the registered IP address. R then
then completes the base exchange without further assistance from RVS completes the base exchange without further assistance from RVS by
by sending an R1 directly to the I's IP address, as obtained from the sending an R1 directly to the I's IP address, as obtained from the I1
I1 packet. In this specification the client of the RVS is always the packet. In this specification the client of the RVS is always the
responder. However, there might be reasons to allow a client to responder. However, there might be reasons to allow a client to
initiate a base exchange through its own RVS, like NAT and firewall initiate a base exchange through its own RVS, like NAT and firewall
traversal. This specification does not address such scenarios which traversal. This specification does not address such scenarios which
should be specified in other documents. should be specified in other documents.
3.1 Diagram Notation 3.1 Diagram Notation
Notation Significance Notation Significance
-------- ------------ -------- ------------
skipping to change at page 5, line 50 skipping to change at page 5, line 50
header. header.
VIA:RVS A VIA_RVS parameter containing the IP address RVS of a VIA:RVS A VIA_RVS parameter containing the IP address RVS of a
rendezvous server is present in the HIP header. rendezvous server is present in the HIP header.
3.2 Rendezvous Client Registration 3.2 Rendezvous Client Registration
Before a rendezvous server starts to relay HIP packets to a Before a rendezvous server starts to relay HIP packets to a
rendezvous client, the rendezvous client needs to register with it to rendezvous client, the rendezvous client needs to register with it to
receive rendezvous service by using the HIP registration extension receive rendezvous service by using the HIP registration extension
[I-D.koponen-hip-registration] as illustrated in the following [I-D.ietf-hip-registration] as illustrated in the following schema:
schema:
+-----+ +-----+ +-----+ +-----+
| | I1 | | | | I1 | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| I | R1(REG_INFO) | RVS | | I | R1(REG_INFO) | RVS |
| | I2(REG_REQ) | | | | I2(REG_REQ) | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| | R2(REG_RES) | | | | R2(REG_RES) | |
skipping to change at page 6, line 33 skipping to change at page 6, line 32
IP addresses of the owner of the HIT, i.e., the rendezvous client. IP addresses of the owner of the HIT, i.e., the rendezvous client.
They MUST also recompute the IP checksum accordingly. They MUST also recompute the IP checksum accordingly.
Because of egress filtering on the path from the RVS to the client Because of egress filtering on the path from the RVS to the client
[RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
IP address, i.e., the IP address of I, with one of its own IP IP address, i.e., the IP address of I, with one of its own IP
addresses. The replacement IP address SHOULD be chosen according to addresses. The replacement IP address SHOULD be chosen according to
[RFC1122] and, when IPv6 is used, to [RFC3484]. Because this [RFC1122] and, when IPv6 is used, to [RFC3484]. Because this
replacement conceals the initiator's IP address, the RVS MUST append replacement conceals the initiator's IP address, the RVS MUST append
a FROM parameter containing the original source IP address of the a FROM parameter containing the original source IP address of the
packet. This FROM parameter MUST be integrity protected by a packet. This FROM parameter MUST be integrity protected by an
RVS_HMAC keyed with the corresponding rendezvous registration RVS_HMAC keyed with the corresponding rendezvous registration
integrity key [I-D.koponen-hip-registration]. integrity key [I-D.ietf-hip-registration].
I1(RVS, R, HIT-I, HIT-R I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC) I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+ +----------------------->| |--------------------+
| | RVS | | | | RVS | |
| | | | | | | |
| +---------+ | | +---------+ |
| V | V
+-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+ +-----+ R1(R, I, HIT-R, HIT-I, VIA:RVS) +-----+
| |<---------------------------------------------| | | |<---------------------------------------------| |
skipping to change at page 7, line 21 skipping to change at page 7, line 20
any modifications. After modification, it MUST recompute the any modifications. After modification, it MUST recompute the
checksum field using the updated HIP header, which possibly included checksum field using the updated HIP header, which possibly included
new FROM and RVS_HMAC parameters, and a pseudo-header containing the new FROM and RVS_HMAC parameters, and a pseudo-header containing the
updated source and destination IP addresses. This enables the updated source and destination IP addresses. This enables the
responder to validate the checksum of the I1 packet "as is", without responder to validate the checksum of the I1 packet "as is", without
having to parse any FROM parameters. having to parse any FROM parameters.
4. Rendezvous Server Extensions 4. Rendezvous Server Extensions
The following sections describe extensions to the HIP registration The following sections describe extensions to the HIP registration
protocol [I-D.koponen-hip-registration], allowing a HIP node to protocol [I-D.ietf-hip-registration], allowing a HIP node to register
register with a rendezvous server for rendezvous service and notify with a rendezvous server for rendezvous service and notify the RVS
the RVS aware of changes to its current location. It also describes aware of changes to its current location. It also describes an
an extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing
establishment of HIP associations via one or more HIP rendezvous establishment of HIP associations via one or more HIP rendezvous
server(s). server(s).
4.1 RENDEZVOUS Registration Type 4.1 RENDEZVOUS Registration Type
This specification defines an additional registration for the HIP This specification defines an additional registration for the HIP
registration protocol [I-D.koponen-hip-registration] that allows registration protocol [I-D.ietf-hip-registration] that allows
registering with a rendezvous server for rendezvous service. registering with a rendezvous server for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
4.2 Parameter Formats and Processing 4.2 Parameter Formats and Processing
4.2.1 RVS_HMAC Parameter 4.2.1 RVS_HMAC Parameter
skipping to change at page 12, line 25 skipping to change at page 12, line 25
8.1 Normative References 8.1 Normative References
[I-D.ietf-hip-base] [I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol", Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-03 (work in progress), June 2005. draft-ietf-hip-base-03 (work in progress), June 2005.
[I-D.ietf-hip-dns] [I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", (HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-01 (work in progress), February 2005. draft-ietf-hip-dns-03 (work in progress), October 2005.
[I-D.koponen-hip-registration] [I-D.ietf-hip-registration]
Koponen, T. and L. Eggert, "Host Identity Protocol (HIP) Laganier, J., "Host Identity Protocol (HIP) Registration
Registration Extension", draft-koponen-hip-registration-00 Extension", draft-ietf-hip-registration-00 (work in
(work in progress), February 2005. progress), September 2005.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434, IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998. October 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2 Informative References 8.2 Informative References
[I-D.ietf-hip-arch] [I-D.ietf-hip-arch]
Moskowitz, R., "Host Identity Protocol Architecture", Moskowitz, R. and P. Nikander, "Host Identity Protocol
draft-ietf-hip-arch-02 (work in progress), January 2005. Architecture", draft-ietf-hip-arch-03 (work in progress),
August 2005.
[I-D.ietf-hip-mm] [I-D.ietf-hip-mm]
Nikander, P., "End-Host Mobility and Multi-Homing with Nikander, P., "End-Host Mobility and Multihoming with the
Host Identity Protocol", draft-ietf-hip-mm-01 (work in Host Identity Protocol", draft-ietf-hip-mm-02 (work in
progress), February 2005. progress), July 2005.
[RFC1498] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000. Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3013] Killalea, T., "Recommended Internet Service Provider [RFC3013] Killalea, T., "Recommended Internet Service Provider
Security Services and Procedures", BCP 46, RFC 3013, Security Services and Procedures", BCP 46, RFC 3013,
November 2000. November 2000.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
DoCoMo Communications Laboratories Europe GmbH DoCoMo Communications Laboratories Europe GmbH
Landsberger Strasse 312 Landsberger Strasse 312
Munich 80687 Munich 80687
skipping to change at page 14, line 5 skipping to change at page 14, line 5
NEC Network Laboratories NEC Network Laboratories
Kurfuerstenanlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
Germany Germany
Phone: +49 6221 90511 43 Phone: +49 6221 90511 43
Fax: +49 6221 90511 55 Fax: +49 6221 90511 55
Email: lars.eggert@netlab.nec.de Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Appendix A. Document Revision History
+-----------+-------------------------------------------------------+
| Revision | Comments |
+-----------+-------------------------------------------------------+
| 03 | Removed architectural discussions. Fixed some |
| | requirements keywords. |
| 02 | Removed multiple relaying techniques but simple I1 |
| | header rewriting. Updated new HIP parameters type |
| | numbers (consistent with new layout and assigning |
| | rules from draft-ietf-hip-base.) Updated IANA |
| | Considerations. |
| 01 | Splitted out the registration sub-protocol. Simplify |
| | typology of relaying techniques (keep only TUNNEL, |
| | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
| 00 | Initial version as a HIP WG item. |
+-----------+-------------------------------------------------------+
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 19 change blocks. 
64 lines changed or deleted 39 lines changed or added

This html diff was produced by rfcdiff 1.27, available from http://www.levkowetz.com/ietf/tools/rfcdiff/