draft-ietf-hip-rvs-02.txt   draft-ietf-hip-rvs-03.txt 
HIP Working Group J. Laganier Network Working Group J. Laganier
Internet-Draft DoCoMo Euro-Labs Internet-Draft DoCoMo Euro-Labs
Expires: December 12, 2005 L. Eggert Expires: January 12, 2006 L. Eggert
NEC NEC
June 10, 2005 July 11, 2005
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rvs-02 draft-ietf-hip-rvs-03
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 December 12, 2005. This Internet-Draft will expire on January 12, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This document discusses 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 6 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 5
3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 6 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 5
3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 7 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 6
4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 8 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 7
4.1 LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 8 4.1 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 7
4.2 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 8 4.2 Parameter Formats and Processing . . . . . . . . . . . . . 7
4.3 New Parameter Formats and Processing . . . . . . . . . . . 9 4.2.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 7
4.3.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 9 4.2.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 8
4.3.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 9 4.2.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 9
4.3.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10 4.3 Modified Packets Processing . . . . . . . . . . . . . . . 9
4.4 Processing Outgoing I1 Packets . . . . . . . . . . . . . . 10 4.3.1 Processing Outgoing I1 Packets . . . . . . . . . . . . 9
4.5 Processing Incoming I1 packets . . . . . . . . . . . . . . 11 4.3.2 Processing Incoming I1 packets . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 4.3.3 Processing Outgoing R1 Packets . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 4.3.4 Processing Incoming R1 packets . . . . . . . . . . . . 10
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1 Normative References . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8.2 Informative References . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 13
A. Document Revision History . . . . . . . . . . . . . . . . . . 14 A. Document Revision History . . . . . . . . . . . . . . . . . . 14
Intellectual Property and Copyright Statements . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 15
1. Introduction 1. Introduction
The current Internet uses IP addresses for two purposes. First, they The Host Identity Protocol architecture [I-D.ietf-hip-arch]
are topological locators for network attachment points. Second, they introduces the rendezvous mechanism to help a HIP node to contact a
act as names for the attached network interfaces. Saltzer [9] frequently moving HIP node. The rendezvous mechanism involves a
discusses these naming concepts in detail. Routing and other third party, the rendezvous server (RVS), which serves as an initial
network-layer mechanisms are based on the locator aspects of IP contact point ("rendezvous point") for its clients. The clients of
addresses. Transport-layer protocols and mechanisms typically use IP an RVS are HIP nodes that use the HIP Registration Protocol
addresses in their role as names for communication endpoints. This [I-D.koponen-hip-registration] to register their HIT->IP address
dual use of IP addresses limits the flexibility of the Internet mappings with the RVS. After this registration, other HIP nodes can
architecture. The need to avoid readdressing in order to maintain initiate a base exchange using the IP address of the RVS instead of
existing transport-layer connections complicates advanced the current IP address of the node they attempt to contact.
functionality, such as mobility, multi-homing, or network Essentially, the clients of an RVS become reachable at the RVS' IP
composition. addresses. Peers can initiate a HIP base exchange with the IP
address of the RVS, which will relay this initial communication such
The Host Identity Protocol (HIP) architecture [1] defines a new third that the base exchange may successfully complete.
namespace. The Host Identity namespace decouples the name and
locator roles currently filled by IP addresses. 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. Because of this decoupling the HIP layer
needs to map Host Identities into IP addresses.
Without HIP, a node needs to know its peer's IP address to make
initial contact. The Host Identity Protocol architecture [1] does
not change this basic property, but introduces an additional,
optional piece of infrastructure, the rendezvous server (RVS). An
RVS serves as an additional initial contact point ("rendezvous
point") for its clients. The clients of an RVS are HIP nodes that
use the HIP Registration Protocol [2] to register their HIT->IP
address mappings with the RVS. After this registration, other HIP
nodes can initiate a base exchange using the IP address of the RVS
instead of the current IP address of the node they attempt to
contact. Essentially, the clients of an RVS become reachable at the
RVS' IP addresses. Peers can initiate a HIP base exchange with the
IP address of the RVS, which will relay this initial communication
such that the base exchange may successfully complete.
When HIP nodes frequently change their network attachment points,
using a RVS can improve reachability and operation. Without an RVS,
a HIP node needs to update its DNS entry with its current IP address
before it becomes reachable to its peers. Although the DNS offers
mechanisms for dynamic updates to records[10][11], they may not be
suitable when a record changes frequently. Caching, state lifetimes
and deficiences in existing DNS implementations limit the rate-of-
change for a given record. When using an RVS - which is assumed to
be reachable at a static or at least infrequently changing IP address
- HIP nodes need not update their DNS records whenever their local IP
addresses change. Instead, they register the IP address of their RVS
in their DNS entry and then update only their RVS when their IP
addresses change. Because the RVS is specifically designed to
support high-rate updates, this indirection can improve reachability
of HIP nodes.
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 [3]. document are to be interpreted as described in RFC 2119 [RFC2119].
In addition to the terminology defined in [2], this document defines In addition to the terminology defined in [I-D.koponen-hip-
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. [Comment.1] responder.
Rendezvous Server (RVS) Rendezvous Server (RVS)
A HIP registrar providing rendezvous service. A HIP registrar providing rendezvous service.
Rendezvous Client Rendezvous Client
A HIP requester that has registered for rendezvous service at a A HIP requester that has registered for rendezvous service at a
rendezvous server. rendezvous server.
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
HIP decouples domain names from IP addresses. Because transport Figure 1 shows a simple HIP base exchange without a rendezvous
protocols bind to host identities, they remain unaware if the set of server, in which the initiator initiates the exchange directly with
IP addresses associated with a host identity changes. This change the responder by sending an I1 packet to the responder's IP address,
can have various reasons, including, but not limited to, mobility and as per the HIP base specification [I-D.ietf-hip-base].
multi-homing.
+-----+ +-----+ +-----+ +-----+
| |-------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.
Figure 2 shows a simple HIP base exchange without a rendezvous Proposed extensions for mobility and multi-homing [I-D.ietf-hip-mm]
server, in which the initiator initiates the exchange directly with allow a HIP node to notify its peers about changes in its set of IP
the responder by sending an I1 packet to the responder's IP address, addresses. These extensions presumes initial reachability of the two
as per the HIP base specification [4]. nodes with respect to each other.
Proposed extensions for mobility and multi-homing [5] allow a HIP
node to notify its peers about changes in its set of IP addresses.
These extensions require an established HIP association between two
nodes, i.e., a completed HIP base exchange.
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 [1] introduces rendezvous servers with whom a The HIP architecture [I-D.ietf-hip-arch] introduces rendezvous
HIP node MAY register its host identity tags (HITs) and current IP servers with whom a HIP node MAY register its host identity tags
addresses. An RVS relays HIP packets arriving for these HITs to the (HITs) and current IP addresses. An RVS relays HIP packets arriving
node's registered IP addresses. When a HIP node has registered with for these HITs to the node's registered IP addresses. When a HIP
an RVS, it SHOULD record the IP address of its RVS in its DNS record, node has registered with an RVS, it SHOULD record the IP address of
using the HIPRVS DNS record type defined in [12]. its RVS in its DNS record, using the HIPRVS DNS record type defined
in [I-D.ietf-hip-dns].
+-----+ +-----+
+--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 [2]. IP addresses with the RVS, using the HIP registration protocol
When the initiator I tries to establish contact with the responder R, [I-D.koponen-hip-registration]. When the initiator I tries to
it MAY send the I1 of the base exchange either to one of R's DNS establish contact with the responder R, it must send the I1 of the
addresses or it MAY send it to the address of one of R's rendezvous base exchange either to one of R's IP addresses (if known via DNS or
servers instead. Here, I obtains the IP address of R's rendezvous other means) or to one of R's rendezvous servers instead. Here, I
server from R's DNS record and then sends the I1 packet of the HIP obtains the IP address of R's rendezvous server from R's DNS record
base exchange to RVS. RVS, noticing that the HIT contained in the and then sends the I1 packet of the HIP base exchange to RVS. RVS,
arriving I1 packet is not one of its own, MUST check its current noticing that the HIT contained in the arriving I1 packet is not one
registrations to determine if if needs to relay the packets. Here, of its own, MUST check its current registrations to determine if if
it determines that the HIT belongs to R and then relays the I1 packet needs to relay the packets. Here, it determines that the HIT belongs
to the registered IP address. R then completes the base exchange to R and then relays the I1 packet to the registered IP address. R
without further assistance from RVS by sending an R1 directly to the then completes the base exchange without further assistance from RVS
I's IP address, as obtained from the I1 packet. by sending an R1 directly to the I's IP address, as obtained from the
I1 packet. In this specification the client of the RVS is always the
responder. However, there might be reasons to allow a client to
initiate a base exchange through its own RVS, like NAT and firewall
traversal. This specification does not address such scenarios which
should be 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.
LOC:I A LOCATOR parameter containing the IP address I is REG_REQ A REG_REQUEST parameter is present in the HIP header.
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.
VIA:RVS A VIA_RVS parameter containing the IP addresses of an RVS_HMAC A RVS_HMAC parameter containing a HMAC keyed with the
RVS is present in the HIP header. appropriate registration key 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. VIA:RVS A VIA_RVS parameter containing the IP address RVS of a
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
[2] as illustrated in the following schema: [I-D.koponen-hip-registration] 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) | |
+-----+ +-----+ +-----+ +-----+
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 MUST relay inbound I1 packets registration, the rendezvous servers relay inbound I1 packets that
that contain one of the client's HITs by rewriting the IP header. contain one of the client's HITs by rewriting the IP header. They
They replace the destination IP address of the I1 packet with one of replace the destination IP address of the I1 packet with one of the
the IP addresses of the owner of the HIT, i.e., the rendezvous IP addresses of the owner of the HIT, i.e., the rendezvous client.
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, a Because of egress filtering on the path from the RVS to the client
HIP rendezvous server MAY also need to replace the source IP address, [RFC2827][RFC3013], a HIP rendezvous server SHOULD replace the source
i.e., the IP address of I, with one of its own IP addresses. The IP address, i.e., the IP address of I, with one of its own IP
replacement IP address SHOULD be chosen according to [6] and, when addresses. The replacement IP address SHOULD be chosen according to
IPv6 is used, to [7]. Because this replacement conceals the [RFC1122] and, when IPv6 is used, to [RFC3484]. Because this
initiator's IP address, the RVS MUST append a FROM parameter replacement conceals the initiator's IP address, the RVS MUST append
containing the original source IP address of the packet. This FROM a FROM parameter containing the original source IP address of the
parameter MUST be integrity protected by a RVS_HMAC keyed with the packet. This FROM parameter MUST be integrity protected by a
corresponding rendezvous registration integrity key [2]. RVS_HMAC keyed with the corresponding rendezvous registration
integrity key [I-D.koponen-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, VIA:RVS) I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, RVS_HMAC)
+----------------------->| |--------------------+ +----------------------->| |--------------------+
| | RVS | | | | RVS | |
| | | | | | | |
| +---------+ | | +---------+ |
| V | V
+-----+ R1(R, I, HIT-R, HIT-I, LOC:R, 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) +-----+
Figure 5: 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. The HIP protocol uses two kinds of packet integrity problematic because the HIP protocol uses integrity checks. Because
checks: hop-by-hop and end-to-end. The HIP checksum is a hop-by-hop the I1 does not include HMAC or SIGNATURE parameters, these two end-
check and SHOULD be verified and recomputed by each of the on-path to-end integrity checks are unaffected by the operation of rendezvous
HIP-enabled middleboxes, such as rendezvous servers. The HMAC and servers.
SIGNATURE are end-to-end checks and MUST be computed by the sender
and verified by the receiver.
The RVS MUST verify the checksum field of an I1 packet doing any
modifications. After modification, it MUST recompute the checksum
field using the updated HIP header, which possibly included new FROM
and RVS_HMAC parameters, and a pseudo-header containing the updated
source and destination IP addresses. This enables the responder to
validate the checksum of the I1 packet "as is", without having to
parse any FROM parameters.
The SIGNATURE and HMAC verification MUST NOT cover any FROM and The RVS SHOULD verify the checksum field of an I1 packet before doing
RVS_HMAC parameters added by rendezvous servers. Hence, HMAC and any modifications. After modification, it MUST recompute the
SIGNATURE are unaffected by the modifications performed by an RVS. checksum field using the updated HIP header, which possibly included
The computation and verification of HMAC and SIGNATURE MUST only new FROM and RVS_HMAC parameters, and a pseudo-header containing the
cover the original HIP header with a checksum field set to zero, MUST updated source and destination IP addresses. This enables the
NOT cover the pseudo header that contains modified IP addresses, and responder to validate the checksum of the I1 packet "as is", without
mUST NOT cover any new FROM and RVS_HMAC parameters that MAY be having to parse any FROM parameters.
situated after the HMAC and SIGNATURE in the HIP header.
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 [2], allowing a HIP node to register with a rendezvous protocol [I-D.koponen-hip-registration], allowing a HIP node to
server for rendezvous service and notify the RVS aware of changes to register with a rendezvous server for rendezvous service and notify
its current location. It also describes an extension to the HIP the RVS aware of changes to its current location. It also describes
protocol [4] itself, allowing establishment of HIP associations via an extension to the HIP protocol [I-D.ietf-hip-base] itself, allowing
one or more HIP rendezvous server(s). establishment of HIP associations via one or more HIP rendezvous
server(s).
4.1 LOCATOR Parameter
A HIP responder contacted via an RVS MAY use a LOCATOR parameter in
the R1 packet to notify the initiator of its current IP address, in
conformance with the guidelines specified in [5].
4.2 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 [2] that allows registering with a rendezvous registration protocol [I-D.koponen-hip-registration] that allows
server for rendezvous service. registering with a rendezvous server for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
4.3 New Parameter Formats and Processing 4.2 Parameter Formats and Processing
4.3.1 RVS_HMAC Parameter 4.2.1 RVS_HMAC Parameter
The RVS_HMAC is an OPTIONAL parameter whose only difference with the The RVS_HMAC is a non-critical parameter whose only difference with
HMAC parameter defined in [4] is its "type" code. This change causes the HMAC parameter defined in [I-D.ietf-hip-base] is its "type" code.
it to be located after the FROM parameter (as opposed to the HMAC): This change causes it to be located after the FROM parameter (as
opposed to the HMAC):
Type [ TBD by IANA (65472 = 2^16 - 2^6) ] Type [ TBD by IANA (65500 = 2^16 - 2^5 - 2^2) ]
Length 20 Length 20
HMAC 160 low order bits of a HMAC keyed with the HMAC 160 low order bits of a HMAC keyed with the
appropriate HIP integrity key (HIP_lg or HIP_gl), appropriate HIP integrity key (HIP_lg or HIP_gl),
established when rendezvous registration happened. established when rendezvous registration happened.
This HMAC is computed over the HIP packet, excluding This HMAC is computed over the HIP packet, excluding
RVS_HMAC and any following parameters. The RVS_HMAC and any following parameters. The
"checksum" field MUST be set to zero and the HIP header "checksum" field MUST be set to zero and the HIP header
length in the HIP common header MUST be calculated length in the HIP common header MUST be calculated
not to cover any excluded parameter when the not to cover any excluded parameter when the
"authenticator" field is calculated. "authenticator" field is calculated.
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. A valid RVS_HMAC SHOULD be present on every packets flowing key established while registration occurred. A valid RVS_HMAC SHOULD
between a client and a server and MUST be present when a FROM be present on every packets flowing between a client and a server and
parameters is processed. MUST be present when a FROM parameters is processed.
4.3.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 (65470 = 2^16 - 2^6 - 2) ] Type [ TBD by IANA (65498 = 2^16 - 2^5 - 2) ]
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
protecting the packet integrity, especially the IP address included protecting the packet integrity, especially the IP address included
in the FROM parameter. in the FROM parameter.
4.3.3 VIA_RVS Parameter 4.2.3 VIA_RVS 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 |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. . . . . .
. . . . . .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Address | | Address |
| | | |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA (65474 = 2^16 - 2^6 + 2) ] Type [ TBD by IANA (65502 = 2^16 - 2^5 + 2) ]
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
a RVS. an RVS.
4.4 Processing Outgoing I1 Packets 4.3 Modified Packets Processing
An initiator SHOULD not send an opportunistic I1 with a NULL The following subsections describe the differences of processing of
I1 and R1 while a rendezvous server is involved in the base exchange.
4.3.1 Processing Outgoing I1 Packets
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 which 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.
If an RVS needs to rewrite the source IP address of an I1 packet due When an RVS rewrites the source IP address of an I1 packet due to
to egress filtering, then it MUST add a FROM parameter to the I1 that egress filtering, it MUST add a FROM parameter to the I1 that
contasins the initiator's source IP address. This FROM parameter contains the initiator's source IP address. This FROM parameter MUST
MUST be protected by a RVS_HMAC keyed with the integrity key be protected by an RVS_HMAC keyed with the integrity key established
established at rendezvous registration. at rendezvous registration.
4.5 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 MUST consult its registration database to find a its own, it consults its registration database to find a registration
registration for the rendezvous service established by the HIT owner. for the rendezvous service established by the HIT owner. If it finds
If it finds an appropriate registration, it MUST relay the packet to an appropriate registration, it relays the packet to the registered
the registered IP address. If it does not find an appropriate IP address. If it does not find an appropriate registration, it
registration, is MUST drop 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
itself and SHOULD NOT attempt to relay it to one of its clients. itself and SHOULD NOT attempt to relay it to one of its clients.
When a rendezvous client receives an I1, it MUST validate any present When a rendezvous client receives an I1, it MUST validate any present
RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet RVS_HMAC parameter. If the RVS_HMAC cannot be verified, the packet
SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM SHOULD be dropped. If the RVS_HMAC cannot be verified and a FROM
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
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
addresses of the traversed RVS's.
4.3.4 Processing Incoming R1 packets
The HIP base specification [I-D.ietf-hip-base] mandates that a system
receiving an R1 MUST first check to see if it has sent an I1 to the
originator of the R1 (i.e., it is in state I1-SENT). When the R1 is
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
MUST be checked against the IP address included in the VIA_RVS
parameter.
5. Security Considerations 5. Security Considerations
The security aspects of different HIP rendezvous mechanisms are This section discusses the known threats introduced by these HIP
currently being investigated. This section describes the known extensions and implications on the overall security of HIP. In
threats introduced by these HIP extensions and implications on the particular, it argues that the extensions described in this document
overall security of HIP and IP. In particular, it argues that the do not introduce additional threats to the Host Identity Protocol.
extensions described in this document do not introduce additional
threats to the Internet infrastructure.
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 HIP's SIGMA protocol. 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 it via an RVS, it has a means to
verify the signatures in the HIP exchange, thus conforming to the verify the signatures in the HIP base exchange, which is known to be
SIGMA protocol which is resilient to man-in-the-middle attacks. thus resilient to 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 identiy (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 which 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 to establish 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 [8]. This section is to be interpreted according to [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.3: defined in Section 4.2:
o RVS_HMAC (defined in Section 4.3.1) o RVS_HMAC (defined in Section 4.2.1)
o FROM (defined in Section 4.3.2) o FROM (defined in Section 4.2.2)
o VIA_RVS (defined in Section 4.3.3) o VIA_RVS (defined in Section 4.2.3)
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.
Lars Eggert is partly funded by Ambient Networks, a research project Julien Laganier and Lars Eggert are partly funded by Ambient
supported by the European Commission under its Sixth Framework Networks, a research project supported by the European Commission
Program. The views and conclusions contained herein are those of the under its Sixth Framework Program. The views and conclusions
authors and should not be interpreted as necessarily representing the contained herein are those of the authors and should not be
official policies or endorsements, either expressed or implied, of interpreted as necessarily representing the official policies or
the Ambient Networks project or the European Commission. 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
[1] Moskowitz, R., "Host Identity Protocol Architecture", [I-D.ietf-hip-base]
draft-ietf-hip-arch-02 (work in progress), January 2005. Moskowitz, R., "Host Identity Protocol",
draft-ietf-hip-base-03 (work in progress), June 2005.
[2] Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-koponen-hip-registration-00 (work
in progress), February 2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [I-D.ietf-hip-dns]
Levels", BCP 14, RFC 2119, March 1997. Nikander, P. and J. Laganier, "Host Identity Protocol
(HIP) Domain Name System (DNS) Extensions",
draft-ietf-hip-dns-01 (work in progress), February 2005.
[4] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02 [I-D.koponen-hip-registration]
Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
Registration Extension", draft-koponen-hip-registration-00
(work in progress), February 2005. (work in progress), February 2005.
[5] Nikander, P., "End-Host Mobility and Multi-Homing with Host [RFC1122] Braden, R., "Requirements for Internet Hosts -
Identity Protocol", draft-ietf-hip-mm-01 (work in progress), Communication Layers", STD 3, RFC 1122, October 1989.
February 2005.
[6] Braden, R., "Requirements for Internet Hosts - Communication [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Layers", STD 3, RFC 1122, October 1989. Requirement Levels", BCP 14, RFC 2119, March 1997.
[7] Draves, R., "Default Address Selection for Internet Protocol [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
version 6 (IPv6)", RFC 3484, February 2003. IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [RFC3484] Draves, R., "Default Address Selection for Internet
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2 Informative References 8.2 Informative References
[9] Saltzer, J., "On the Naming and Binding of Network [I-D.ietf-hip-arch]
Destinations", RFC 1498, August 1993. Moskowitz, R., "Host Identity Protocol Architecture",
draft-ietf-hip-arch-02 (work in progress), January 2005.
[10] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
April 1997.
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic [I-D.ietf-hip-mm]
Update", RFC 3007, November 2000. Nikander, P., "End-Host Mobility and Multi-Homing with
Host Identity Protocol", draft-ietf-hip-mm-01 (work in
progress), February 2005.
[12] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) [RFC1498] Saltzer, J., "On the Naming and Binding of Network
Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01 Destinations", RFC 1498, August 1993.
(work in progress), February 2005.
[13] 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.
[14] Killalea, T., "Recommended Internet Service Provider Security [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Services and Procedures", BCP 46, RFC 3013, November 2000. Update", RFC 3007, November 2000.
Editorial Comments
[Comment.1] In this specification the client of the RVS is always [RFC3013] Killalea, T., "Recommended Internet Service Provider
the responder. However, there might be reasons to allow Security Services and Procedures", BCP 46, RFC 3013,
a client to initiate a base exchange through its own November 2000.
RVS, like NAT and firewall traversal. This specification
does not address such scenarios which should be
specified in other documents.
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
skipping to change at page 14, line 45 skipping to change at page 14, line 10
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 Appendix A. Document Revision History
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 03 | Removed architectural discussions. Fixed some |
| | requirements keywords. |
| 02 | Removed multiple relaying techniques but simple I1 | | 02 | Removed multiple relaying techniques but simple I1 |
| | header rewriting. Updated new HIP parameters type | | | header rewriting. Updated new HIP parameters type |
| | numbers (consistent with new layout and assigning | | | numbers (consistent with new layout and assigning |
| | rules from draft-ietf-hip-base.) Updated IANA | | | rules from draft-ietf-hip-base.) Updated IANA |
| | Considerations. | | | Considerations. |
| 01 | Splitted out the registration sub-protocol. Simplify | | 01 | Splitted out the registration sub-protocol. Simplify |
| | typology of relaying techniques (keep only TUNNEL, | | | typology of relaying techniques (keep only TUNNEL, |
| | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. | | | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
| 00 | Initial version as a HIP WG item. | | 00 | Initial version as a HIP WG item. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
 End of changes. 

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