draft-ietf-hip-rvs-05.txt   rfc5204.txt 
Network Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Request for Comments: 5204 DoCoMo Euro-Labs
Expires: December 9, 2006 L. Eggert Category: Experimental L. Eggert
NEC Nokia
June 7, 2006
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rvs-05
Status of this Memo
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 becomes
aware will be disclosed, in accordance with Section 6 of 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 Status of This Memo
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 December 9, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
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
via HIP rendezvous servers. Rendezvous servers improve reachability via HIP rendezvous servers. Rendezvous servers improve reachability
and operation when HIP nodes are multi-homed or mobile. and operation when HIP nodes are multi-homed or mobile.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5 3.1. Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 5 3.2. Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6 3.3. Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7 4.1. RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2. Parameter Formats and Processing . . . . . . . . . . . . . 7 4.2. Parameter Formats and Processing . . . . . . . . . . . . . 8
4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7 4.2.1. RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 8
4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 8 4.2.2. FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9 4.2.3. VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.3. Modified Packets Processing . . . . . . . . . . . . . . . 9 4.3. Modified Packets Processing . . . . . . . . . . . . . . . 10
4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 9 4.3.1. Processing Outgoing I1 Packets . . . . . . . . . . . . 10
4.3.2. Processing Incoming I1 packets . . . . . . . . . . . . 10 4.3.2. Processing Incoming I1 Packets . . . . . . . . . . . . 11
4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 10 4.3.3. Processing Outgoing R1 Packets . . . . . . . . . . . . 11
4.3.4. Processing Incoming R1 packets . . . . . . . . . . . . 10 4.3.4. Processing Incoming R1 Packets . . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13
8.2. Informative References . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . . . 15
1. Introduction 1. Introduction
The Host Identity Protocol architecture [RFC4423] introduces the The Host Identity Protocol (HIP) Architecture [RFC4423] introduces
rendezvous mechanism to help a HIP node to contact a frequently the rendezvous mechanism to help a HIP node to contact a frequently
moving HIP node. The rendezvous mechanism involves a third party, moving HIP node. The rendezvous mechanism involves a third party,
the rendezvous server (RVS), which serves as an initial contact point the rendezvous server (RVS), which serves as an initial contact point
("rendezvous point") for its clients. The clients of an RVS are HIP ("rendezvous point") for its clients. The clients of an RVS are HIP
nodes that use the HIP Registration Protocol [I-D.ietf-hip- nodes that use the HIP Registration Extension [RFC5203] to register
registration] to register their HIT->IP address mappings with the their HIT->IP address mappings with the RVS. After this
RVS. After this registration, other HIP nodes can initiate a base registration, other HIP nodes can initiate a base exchange using the
exchange using the IP address of the RVS instead of the current IP IP address of the RVS instead of the current IP address of the node
address of the node they attempt to contact. Essentially, the they attempt to contact. Essentially, the clients of an RVS become
clients of an RVS become reachable at the RVS' IP addresses. Peers reachable at the RVS's IP address. Peers can initiate a HIP base
can initiate a HIP base exchange with the IP address of the RVS, exchange with the IP address of the RVS, which will relay this
which will relay this initial communication such that the base initial communication such that the base exchange may successfully
exchange may successfully complete. 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.ietf-hip- In addition to the terminology defined in the HIP specification
registration], this document defines and uses the following terms: [RFC5201] and the HIP Registration Extension [RFC5203], 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 10 skipping to change at page 4, line 10
Rendezvous Registration Rendezvous Registration
A HIP registration for rendezvous service, established between a A HIP registration for rendezvous service, established between a
rendezvous server and a rendezvous client. rendezvous server and a rendezvous client.
3. Overview of Rendezvous Server Operation 3. Overview of Rendezvous Server Operation
Figure 1 shows a simple HIP base exchange without a rendezvous Figure 1 shows a simple HIP base exchange without a rendezvous
server, in which the initiator initiates the exchange directly with server, in which the initiator initiates the exchange directly with
the responder by sending an I1 packet to the responder's IP address, the responder by sending an I1 packet to the responder's IP address,
as per the HIP base specification [I-D.ietf-hip-base]. as per the HIP specification [RFC5201].
+-----+ +-----+ +-----+ +-----+
| |-------I1------>| | | |-------I1------>| |
| I |<------R1-------| R | | I |<------R1-------| R |
| |-------I2------>| | | |-------I2------>| |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 1: HIP base exchange without rendezvous server. Figure 1: HIP base exchange without rendezvous server.
Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm] The End-Host Mobility and Multihoming with the Host Identity Protocol
allow a HIP node to notify its peers about changes in its set of IP specification [RFC5206] allows a HIP node to notify its peers about
addresses. These extensions presumes initial reachability of the two changes in its set of IP addresses. This specification presumes
nodes with respect to each other. initial reachability of the two nodes with respect to each other.
However, such a HIP node MAY also want to be reachable to other However, such a HIP node MAY also want to be reachable to other
future correspondent peers that are unaware of its location change. future correspondent peers that are unaware of its location change.
The HIP architecture [RFC4423] introduces rendezvous servers with The HIP Architecture [RFC4423] introduces rendezvous servers with
whom a HIP node MAY register its host identity tags (HITs) and whom a HIP node MAY register its host identity tags (HITs) and
current IP addresses. An RVS relays HIP packets arriving for these current IP addresses. An RVS relays HIP packets arriving for these
HITs to the node's registered IP addresses. When a HIP node has HITs to the node's registered IP addresses. When a HIP node has
registered with an RVS, it SHOULD record the IP address of its RVS in registered with an RVS, it SHOULD record the IP address of its RVS in
its DNS record, using the HIPRVS DNS record type defined in its DNS record, using the HIP DNS resource record type defined in the
[I-D.ietf-hip-dns]. HIP DNS Extension [RFC5205].
+-----+ +-----+
+--I1--->| RVS |---I1--+ +--I1--->| RVS |---I1--+
| +-----+ | | +-----+ |
| v | v
+-----+ +-----+ +-----+ +-----+
| |<------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 Extension
[I-D.ietf-hip-registration]. When the initiator I tries to establish [RFC5203]. When the initiator I tries to establish contact with the
contact with the responder R, it must send the I1 of the base responder R, it must send the I1 of the base exchange either to one
exchange either to one of R's IP addresses (if known via DNS or other of R's IP addresses (if known via DNS or other means) or to one of
means) or to one of R's rendezvous servers instead. Here, I obtains R's rendezvous servers. Here, I obtains the IP address of R's
the IP address of R's rendezvous server from R's DNS record and then rendezvous server from R's DNS record and then sends the I1 packet of
sends the I1 packet of the HIP base exchange to RVS. RVS, noticing the HIP base exchange to RVS. RVS, noticing that the HIT contained
that the HIT contained in the arriving I1 packet is not one of its in the arriving I1 packet is not one of its own, MUST check its
own, MUST check its current registrations to determine if if needs to current registrations to determine if it needs to relay the packets.
relay the packets. Here, it determines that the HIT belongs to R and Here, it determines that the HIT belongs to R and then relays the I1
then relays the I1 packet to the registered IP address. R then packet to the registered IP address. R then completes the base
completes the base exchange without further assistance from RVS by exchange without further assistance from RVS by sending an R1
sending an R1 directly to the I's IP address, as obtained from the I1 directly to the I's IP address, as obtained from the I1 packet. In
packet. In this specification the client of the RVS is always the this specification, the client of the RVS is always the responder.
responder. However, there might be reasons to allow a client to However, there might be reasons to allow a client to initiate a base
initiate a base exchange through its own RVS, like NAT and firewall exchange through its own RVS, like NAT and firewall traversal. This
traversal. This specification does not address such scenarios which specification does not address such scenarios, which should be
should be specified in other documents. specified in other documents.
3.1. Diagram Notation 3.1. Diagram Notation
Notation Significance Notation Significance
-------- ------------ -------- ------------
I, R I and R are the respective source and destination IP I, R I and R are the respective source and destination IP
addresses in the IP header. addresses in the IP header.
HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
responder's HITs in the packet, respectively. responder's HITs in the packet, respectively.
REG_REQ A REG_REQUEST parameter is present in the HIP header. REG_REQ A REG_REQUEST parameter is present in the HIP header.
REG_RES A REG_RESPONSE parameter is present in the HIP header. REG_RES A REG_RESPONSE parameter is present in the HIP header.
FROM:I A FROM parameter containing the IP address I is FROM:I A FROM parameter containing the IP address I is
present in the HIP header. present in the HIP header.
RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the RVS_HMAC An RVS_HMAC parameter containing an HMAC keyed with the
appropriate registration key is present in the HIP appropriate registration key is present in the HIP
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.ietf-hip-registration] as illustrated in the following schema: [RFC5203] as illustrated in the following 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) | |
+-----+ +-----+ +-----+ +-----+
Rendezvous client registering with a rendezvous server.
3.3. Relaying the Base Exchange 3.3. Relaying the Base Exchange
If a HIP node and one of its rendezvous servers have a rendezvous If a HIP node and one of its rendezvous servers have a rendezvous
registration, the rendezvous servers relay inbound I1 packets that registration, the rendezvous servers relay inbound I1 packets (that
contain one of the client's HITs by rewriting the IP header. They contain one of the client's HITs) by rewriting the IP header. They
replace the destination IP address of the I1 packet with one of the replace the destination IP address of the I1 packet with one of the
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 relevant IPv4 and IPv6 specifications [RFC1122][RFC3484]. Because
replacement conceals the initiator's IP address, the RVS MUST append this replacement conceals the initiator's IP address, the RVS MUST
a FROM parameter containing the original source IP address of the append a FROM parameter containing the original source IP address of
packet. This FROM parameter MUST be integrity protected by an the 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.ietf-hip-registration]. integrity key [RFC5203].
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) +-----+
| |<---------------------------------------------| | | |<---------------------------------------------| |
| | | | | | | |
| I | I2(I, R, HIT-I, HIT-R) | R | | I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| | | |--------------------------------------------->| |
| |<---------------------------------------------| | | |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+ +-----+ R2(R, I, HIT-R, HIT-I) +-----+
Rendezvous server rewriting IP addresses.
This modification of HIP packets at a rendezvous server can be This modification of HIP packets at a rendezvous server can be
problematic because the HIP protocol uses integrity checks. Because problematic because the HIP protocol uses integrity checks. Because
the I1 does not include HMAC or SIGNATURE parameters, these two end- the I1 does not include HMAC or SIGNATURE parameters, these two end-
to-end integrity checks are unaffected by the operation of rendezvous to-end integrity checks are unaffected by the operation of rendezvous
servers. servers.
The RVS SHOULD verify the checksum field of an I1 packet before doing The RVS SHOULD verify the checksum field of an I1 packet before doing
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 This section describes extensions to the HIP Registration Extension
protocol [I-D.ietf-hip-registration], allowing a HIP node to register [RFC5203], allowing a HIP node to register with a rendezvous server
with a rendezvous server for rendezvous service and notify the RVS for rendezvous service and notify the RVS aware of changes to its
aware of changes to its current location. It also describes an current location. It also describes an extension to the HIP
extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing specification [RFC5201] itself, allowing establishment of HIP
establishment of HIP associations via one or more HIP rendezvous 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.ietf-hip-registration] that allows Registration Extension [RFC5203] that allows registering with a
registering with a rendezvous server for rendezvous service. 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
The RVS_HMAC is a non-critical parameter whose only difference with The RVS_HMAC is a non-critical parameter whose only difference with
the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code. the HMAC parameter defined in the HIP specification [RFC5201] is its
This change causes it to be located after the FROM parameter (as "type" code. This change causes it to be located after the FROM
opposed to the HMAC): parameter (as opposed to the HMAC):
Type [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ] Type 65500
Length 20 Length Variable. Length in octets, excluding Type, Length, and
HMAC 160 low order bits of a HMAC keyed with the Padding.
appropriate HIP integrity key (HIP_lg or HIP_gl), HMAC HMAC computed over the HIP packet, excluding the
established when rendezvous registration happened. RVS_HMAC parameter and any following parameters. The
This HMAC is computed over the HIP packet, excluding HMAC is keyed with the appropriate HIP integrity key
RVS_HMAC and any following parameters. The (HIP-lg or HIP-gl) established when rendezvous
"checksum" field MUST be set to zero and the HIP header registration happened. The HIP "checksum" field MUST be set
length in the HIP common header MUST be calculated to zero, and the HIP header length in the HIP common header
not to cover any excluded parameter when the MUST be calculated not to cover any excluded parameter
"authenticator" field is calculated. when the HMAC is calculated. The size of the
HMAC is the natural size of the hash computation
output depending on the used hash function.
To allow a rendezvous client and its RVS to verify the integrity of To allow a rendezvous client and its RVS to verify the integrity of
packets flowing between them, both SHOULD protect packets with an packets flowing between them, both SHOULD protect packets with an
added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity added RVS_HMAC parameter keyed with the HIP-lg or HIP-gl integrity
key established while registration occurred. A valid RVS_HMAC SHOULD key established while registration occurred. A valid RVS_HMAC SHOULD
be present on every packets flowing between a client and a server and be present on every packet flowing between a client and a server and
MUST be present when a FROM parameters is processed. MUST be present when a FROM parameter is processed.
4.2.2. FROM Parameter 4.2.2. FROM Parameter
0 1 2 3 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 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 | | Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (65498 = 2^16 - 2^5 - 2) ] Type 65498
Length 16 Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address. Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
A rendezvous server MUST add a FROM parameter containing the original A rendezvous server MUST add a FROM parameter containing the original
source IP address of a HIP packet whenever the source IP address in source IP address of a HIP packet whenever the source IP address in
the IP header is rewritten. If one or more FROM parameters are the IP header is rewritten. If one or more FROM parameters are
already present, the new FROM parameter MUST be appended after the already present, the new FROM parameter MUST be appended after the
existing ones. existing ones.
Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
skipping to change at page 9, line 26 skipping to change at page 10, line 26
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (65502 = 2^16 - 2^5 + 2) ] Type 65502
Length Variable Length Variable
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address.
After the responder receives a relayed I1 packet, it can begin to After the responder receives a relayed I1 packet, it can begin to
send HIP packets addressed to the initiator's IP address, without send HIP packets addressed to the initiator's IP address, without
further assistance from an RVS. For debugging purposes, it MAY further assistance from an RVS. For debugging purposes, it MAY
include a subset of the IP addresses of its RVSs in some of these include a subset of the IP addresses of its RVSs in some of these
packets. When a responder does so, it MUST append a newly created packets. When a responder does so, it MUST append a newly created
VIA_RVS parameter at the end of the HIP packet. The main goal of VIA_RVS parameter at the end of the HIP packet. The main goal of
using the VIA_RVS parameter is to allow operators to diagnose using the VIA_RVS parameter is to allow operators to diagnose
possible issues encountered while establishing a HIP association via possible issues encountered while establishing a HIP association via
an RVS. an RVS.
4.3. Modified Packets Processing 4.3. Modified Packets Processing
The following subsections describe the differences of processing of The following subsections describe the differences of processing of
I1 and R1 while a rendezvous server is involved in the base exchange. I1 and R1 while a rendezvous server is involved in the base exchange.
4.3.1. Processing Outgoing I1 Packets 4.3.1. Processing Outgoing I1 Packets
An initiator SHOULD NOT send an opportunistic I1 with a NULL An initiator SHOULD NOT send an opportunistic I1 with a NULL
destination HIT to an IP address which is known to be a rendezvous destination HIT to an IP address that is known to be a rendezvous
server address, unless it wants to establish a HIP association with server address, unless it wants to establish a HIP association with
the rendezvous server itself and does not know its HIT. the rendezvous server itself and does not know its HIT.
When an RVS rewrites the source IP address of an I1 packet due to When an RVS rewrites the source IP address of an I1 packet due to
egress filtering, it MUST add a FROM parameter to the I1 that egress filtering, it MUST add a FROM parameter to the I1 that
contains the initiator's source IP address. This FROM parameter MUST contains the initiator's source IP address. This FROM parameter MUST
be protected by an RVS_HMAC keyed with the integrity key established be protected by an RVS_HMAC keyed with the integrity key established
at rendezvous registration. at rendezvous registration.
4.3.2. Processing Incoming I1 packets 4.3.2. Processing Incoming I1 Packets
When a rendezvous server receives an I1 whose destination HIT is not When a rendezvous server receives an I1 whose destination HIT is not
its own, it consults its registration database to find a registration its own, it consults its registration database to find a registration
for the rendezvous service established by the HIT owner. If it finds for the rendezvous service established by the HIT owner. If it finds
an appropriate registration, it relays the packet to the registered an appropriate registration, it relays the packet to the registered
IP address. If it does not find an appropriate registration, it IP address. If it does not find an appropriate registration, it
drops the packet. drops the packet.
A rendezvous server SHOULD interpret any incoming opportunistic I1 A rendezvous server SHOULD interpret any incoming opportunistic I1
(i.e., an I1 with a NULL destination HIT) as an I1 addressed to (i.e., an I1 with a NULL destination HIT) as an I1 addressed to
skipping to change at page 10, line 35 skipping to change at page 11, line 37
parameter is present, the packet MUST be dropped. parameter is present, the packet MUST be dropped.
A rendezvous client acting as responder SHOULD drop opportunistic I1s A rendezvous client acting as responder SHOULD drop opportunistic I1s
that include a FROM parameter, because this indicates that the I1 has that include a FROM parameter, because this indicates that the I1 has
been relayed. been relayed.
4.3.3. Processing Outgoing R1 Packets 4.3.3. Processing Outgoing R1 Packets
When a responder replies to an I1 relayed via an RVS, it MUST append When a responder replies to an I1 relayed via an RVS, it MUST append
to the regular R1 header a VIA_RVS parameter containing the IP to the regular R1 header a VIA_RVS parameter containing the IP
addresses of the traversed RVS's. addresses of the traversed RVSs.
4.3.4. Processing Incoming R1 packets 4.3.4. Processing Incoming R1 Packets
The HIP base specification [I-D.ietf-hip-base] mandates that a system The HIP specification [RFC5201] mandates that a system receiving an
receiving an R1 MUST first check to see if it has sent an I1 to the R1 MUST first check to see if it has sent an I1 to the originator of
originator of the R1 (i.e., it is in state I1-SENT). When the R1 is the R1 (i.e., the system is in state I1-SENT). When the R1 is
replying to a relayed I1, this check SHOULD be based on HITs only. replying to a relayed I1, this check SHOULD be based on HITs only.
In case the IP addresses are also checked, then the source IP address In case the IP addresses are also checked, then the source IP address
MUST be checked against the IP address included in the VIA_RVS MUST be checked against the IP address included in the VIA_RVS
parameter. parameter.
5. Security Considerations 5. Security Considerations
This section discusses the known threats introduced by these HIP This section discusses the known threats introduced by these HIP
extensions and implications on the overall security of HIP. In extensions and the implications on the overall security of HIP. In
particular, it argues that the extensions described in this document particular, it argues that the extensions described in this document
do not introduce additional threats to the Host Identity Protocol. do not introduce additional threats to the Host Identity Protocol.
It is difficult to encompass the whole scope of threats introduced by It is difficult to encompass the whole scope of threats introduced by
rendezvous servers, because their presence has implications both at rendezvous servers because their presence has implications both at
the IP and HIP layers. In particular, these extensions might allow the IP and HIP layers. In particular, these extensions might allow
for redirection, amplification and reflection attacks at the IP for redirection, amplification, and reflection attacks at the IP
layer, as well as attacks on the HIP layer itself, for example, man- layer, as well as attacks on the HIP layer itself, for example, man-
in-the-middle attacks against the HIP base exchange. in-the-middle attacks against the HIP base exchange.
If an initiator has a priori knowledge of the responder's host If an initiator has a priori knowledge of the responder's host
identity when it first contacts it via an RVS, it has a means to identity when it first contacts the responder via an RVS, it has a
verify the signatures in the HIP base exchange, which is known to be means to verify the signatures in the HIP base exchange, which
thus resilient to man-in-the-middle attacks. protects against man-in-the-middle attacks.
If an initiator does not have a priori knowledge of the responder's If an initiator does not have a priori knowledge of the responder's
host identity (so-called "opportunistic initiators"), it is almost host identity (so-called "opportunistic initiators"), it is almost
impossible to defend the HIP exchange against these attacks, because impossible to defend the HIP exchange against these attacks, because
the public keys exchanged cannot be authenticated. The only approach the public keys exchanged cannot be authenticated. The only approach
would be to mitigate hijacking threats on HIP state by requiring an would be to mitigate hijacking threats on HIP state by requiring an
R1 answering an opportunistic I1 to come from the same IP address R1 answering an opportunistic I1 to come from the same IP address
that originally sent the I1. This procedure retains a level of that originally sent the I1. This procedure retains a level of
security which is equivalent to what exists in the Internet today. security that is equivalent to what exists in the Internet today.
However, for reasons of simplicity, this specification does not allow However, for reasons of simplicity, this specification does not allow
to establish a HIP association via a rendezvous server in an the establishment of a HIP association via a rendezvous server in an
opportunistic manner. opportunistic manner.
6. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to [RFC2434]. This section is to be interpreted according to the Guidelines for
Writing an IANA Considerations Section in RFCs [RFC2434].
This document updates the IANA Registry for HIP Parameters Types by This document updates the IANA Registry for HIP Parameters Types by
assigning new HIP Parameter Types values for the new HIP Parameters assigning new HIP Parameter Types values for the new HIP Parameters
defined in Section 4.2: defined in Section 4.2:
o RVS_HMAC (defined in Section 4.2.1) o RVS_HMAC (defined in Section 4.2.1)
o FROM (defined in Section 4.2.2) o FROM (defined in Section 4.2.2)
o VIA_RVS (defined in Section 4.2.3) o VIA_RVS (defined in Section 4.2.3)
This document defines an additional registration for the HIP
Registration Extension [RFC5203] that allows registering with a
rendezvous server for rendezvous service.
Number Registration Type
------ -----------------
1 RENDEZVOUS
7. Acknowledgments 7. Acknowledgments
The following people have provided thoughtful and helpful discussions The following people have provided thoughtful and helpful discussions
and/or suggestions that have improved this document: Marcus Brunner, and/or suggestions that have improved this document: Marcus Brunner,
Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino
Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
Stiemerling and Juergen Quittek. Stiemerling, and Juergen Quittek.
Julien Laganier and Lars Eggert are partly funded by Ambient
Networks, a research project supported by the European Commission
under its Sixth Framework Program. 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.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-hip-base]
Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-05 (work in progress), March 2006.
[I-D.ietf-hip-dns]
Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-06 (work in progress), February 2006.
[I-D.ietf-hip-registration]
Laganier, J., "Host Identity Protocol (HIP) Registration
Extension", draft-ietf-hip-registration-01 (work in
progress), December 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 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
Henderson, "Host Identity Protocol", RFC 5201, April 2008.
[I-D.ietf-hip-mm] [RFC5203] Laganier, J., Koponen, T., and L. Eggert, "Host Identity
Nikander, P., "End-Host Mobility and Multihoming with the Protocol (HIP) Registration Extension", RFC 5203,
Host Identity Protocol", draft-ietf-hip-mm-03 (work in April 2008.
progress), March 2006.
[RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions", RFC 5205,
April 2008.
8.2. Informative References
[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.
[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.
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol
(HIP) Architecture", RFC 4423, May 2006. (HIP) Architecture", RFC 4423, May 2006.
[RFC5206] Henderson, T., Ed., "End-Host Mobility and Multihoming
with the Host Identity Protocol", RFC 5206, April 2008.
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
Germany Germany
Phone: +49 89 56824 231 Phone: +49 89 56824 231
Email: julien.ietf@laposte.net EMail: julien.ietf@laposte.net
URI: http://www.docomolab-euro.com/ URI: http://www.docomolab-euro.com/
Lars Eggert Lars Eggert
NEC Network Laboratories Nokia Research Center
Kurfuerstenanlage 36 P.O. Box 407
Heidelberg 69115 Nokia Group 00045
Germany Finland
Phone: +49 6221 90511 43 Phone: +358 50 48 24461
Fax: +49 6221 90511 55 EMail: lars.eggert@nokia.com
Email: lars.eggert@netlab.nec.de URI: http://research.nokia.com/people/lars_eggert/
URI: http://www.netlab.nec.de/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
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, THE IETF TRUST 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.
Intellectual Property
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.
skipping to change at page 15, line 28 skipping to change at line 590
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. 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 (2006). 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.
 End of changes. 53 change blocks. 
183 lines changed or deleted 172 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/