draft-ietf-hip-rvs-01.txt   draft-ietf-hip-rvs-02.txt 
HIP Working Group J. Laganier HIP Working Group J. Laganier
Internet-Draft LIP / Sun Microsystems Internet-Draft DoCoMo Euro-Labs
Expires: August 19, 2005 L. Eggert Expires: December 12, 2005 L. Eggert
NEC NEC
February 18, 2005 June 10, 2005
Host Identity Protocol (HIP) Rendezvous Extension Host Identity Protocol (HIP) Rendezvous Extension
draft-ietf-hip-rvs-01 draft-ietf-hip-rvs-02
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions By submitting this Internet-Draft, each author represents that any
of section 3 of RFC 3667. By submitting this Internet-Draft, each applicable patent or other IPR claims of which he or she is aware
author represents that any applicable patent or other IPR claims of have been or will be disclosed, and any of which he or she becomes
which he or she is aware have been or will be disclosed, and any of aware will be disclosed, in accordance with Section 6 of BCP 79.
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 August 19, 2005. This Internet-Draft will expire on December 12, 2005.
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 discusses a rendezvous extension for the Host Identity
Protocol (HIP). The Rendezvous extension extend 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 operation via HIP rendezvous servers. Rendezvous servers improve reachability
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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4 3. Overview of Rendezvous Server Operation . . . . . . . . . . . 4
3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 6 3.1 Diagram Notation . . . . . . . . . . . . . . . . . . . . . 6
3.2 Rendezvous Client Registering with a Rendezvous Server . . 6 3.2 Rendezvous Client Registration . . . . . . . . . . . . . . 6
3.3 Establishing HIP Associations via Rendezvous Servers . . . 7 3.3 Relaying the Base Exchange . . . . . . . . . . . . . . . . 7
3.3.1 Encapsulating I1 into a Tunnel . . . . . . . . . . . . 7 4. Rendezvous Server Extensions . . . . . . . . . . . . . . . . . 8
3.3.2 Rewriting I1 IP Header . . . . . . . . . . . . . . . . 7 4.1 LOCATOR Parameter . . . . . . . . . . . . . . . . . . . . 8
3.3.3 Bidirectional Forwarding of HIP packets . . . . . . . 8 4.2 RENDEZVOUS Registration Type . . . . . . . . . . . . . . . 8
3.3.4 Implication on the HIP integrity checks . . . . . . . 9 4.3 New Parameter Formats and Processing . . . . . . . . . . . 9
4. RVS Extensions Definition . . . . . . . . . . . . . . . . . . 10 4.3.1 RVS_HMAC Parameter . . . . . . . . . . . . . . . . . . 9
4.1 Usage and Processing of Existing Parameters . . . . . . . 11 4.3.2 FROM Parameter . . . . . . . . . . . . . . . . . . . . 9
4.1.1 ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 11 4.3.3 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 10
4.1.2 REA Parameter . . . . . . . . . . . . . . . . . . . . 11 4.4 Processing Outgoing I1 Packets . . . . . . . . . . . . . . 10
4.2 New Registration Type . . . . . . . . . . . . . . . . . . 11 4.5 Processing Incoming I1 packets . . . . . . . . . . . . . . 11
4.3 New Parameter Formats and Processing . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
4.3.1 RVR_TYPE Parameter . . . . . . . . . . . . . . . . . . 12 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
4.3.2 RVR_HMAC Parameter . . . . . . . . . . . . . . . . . . 13 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
4.3.3 FROM Parameter . . . . . . . . . . . . . . . . . . . . 14 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.3.4 TO Parameter . . . . . . . . . . . . . . . . . . . . . 15 8.1 Normative References . . . . . . . . . . . . . . . . . . . 13
4.3.5 VIA_RVS Parameter . . . . . . . . . . . . . . . . . . 16 8.2 Informative References . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 Editorial Comments . . . . . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18 A. Document Revision History . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Intellectual Property and Copyright Statements . . . . . . . . 16
8.1 Normative References . . . . . . . . . . . . . . . . . . . . 19
8.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
A. Document Revision History . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
The current Internet has a dual use of IP addresses. First, they are The current Internet uses IP addresses for two purposes. First, they
topological locators for network attachment points. Second, they act are topological locators for network attachment points. Second, they
as names for the attached network interfaces. Saltzer [6] discusses act as names for the attached network interfaces. Saltzer [9]
these naming concepts in detail. Routing and other network-layer discusses these naming concepts in detail. Routing and other
mechanisms are based on the locator aspects of IP addresses. network-layer mechanisms are based on the locator aspects of IP
Transport-layer protocols and mechanisms typically use IP addresses addresses. Transport-layer protocols and mechanisms typically use IP
in their role as names for communication endpoints. This dual use of addresses in their role as names for communication endpoints. This
IP addresses limits the flexibility of the Internet architecture. dual use of IP addresses limits the flexibility of the Internet
The need to avoid readdressing in order to maintain existing architecture. The need to avoid readdressing in order to maintain
transport-layer connections complicates advanced functionality, such existing transport-layer connections complicates advanced
as mobility, multi-homing, or network composition. functionality, such as mobility, multi-homing, or network
composition.
The Host Identity Protocol (HIP) architecture [1] defines a new third The Host Identity Protocol (HIP) architecture [1] defines a new third
namespace. The Host Identity namespace decouples the name and namespace. The Host Identity namespace decouples the name and
locator roles currently filled by IP addresses. Transport-layer locator roles currently filled by IP addresses. Transport-layer
mechanisms operate on Host Identities instead of using IP addresses mechanisms operate on Host Identities instead of using IP addresses
as endpoint names. Network-layer mechanisms continue to use IP as endpoint names. Network-layer mechanisms continue to use IP
addresses as pure locators. Because of this decoupling the HIP layer addresses as pure locators. Because of this decoupling the HIP layer
needs to map Host Identities into IP addresses. needs to map Host Identities into IP addresses.
Without HIP, a node needs to know its peer IP address to make an Without HIP, a node needs to know its peer's IP address to make
initial contact. The Host Identity Protocol architecture [1] initial contact. The Host Identity Protocol architecture [1] does
introduces an additional piece of infrastructure, the Rendezvous not change this basic property, but introduces an additional,
Server (RVS), which serves as an initial contact point (rendezvous) optional piece of infrastructure, the rendezvous server (RVS). An
for nodes trying to reach the RVS clients. A RVS offers to a peer it RVS serves as an additional initial contact point ("rendezvous
serves to relay to its IP address the first packet of a HIP exchange point") for its clients. The clients of an RVS are HIP nodes that
incoming at the RVS IP address and with the peer receiver HIT. A use the HIP Registration Protocol [2] to register their HIT->IP
peer uses the HIP Registration Protocol [2] to register its HIT->IP address mappings with the RVS. After this registration, other HIP
address mapping with its RVS. Then an initiator and responder can nodes can initiate a base exchange using the IP address of the RVS
have rendezvous together at the RVS IP address. The initiator would instead of the current IP address of the node they attempt to
send a I1 packet to the RVS IP address, which would then relay the I1 contact. Essentially, the clients of an RVS become reachable at the
to the responder IP address. Then, further communications would RVS' IP addresses. Peers can initiate a HIP base exchange with the
typically occurs directly without further assistance from the RVS. IP address of the RVS, which will relay this initial communication
such that the base exchange may successfully complete.
After the Base Exchange, HIP nodes use Host Identities instead of IP When HIP nodes frequently change their network attachment points,
addresses to name transport-layer endpoints. The HIP layer in the using a RVS can improve reachability and operation. Without an RVS,
network stack internally translates Host Identities (HI) into a HIP node needs to update its DNS entry with its current IP address
network-layer IP addresses. 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 [3].
Rendezvous Service : A HIP Service provided by a HIP Rendezvous In addition to the terminology defined in [2], this document defines
Server to its Rendezvous Clients. The Rendezvous Server offers to and uses the following terms:
relay some of the incoming HIP packets exchanged during a HIP
exchange to the owner of their receiver HIT (i.e. the Rendezvous
Client or one of its correspondent nodes).
Rendezvous Server (RVS): A HIP Registrar providing the Rendezvous Rendezvous Service
Service. A HIP service provided by a rendezvous server to its rendezvous
clients. The rendezvous server offers to relay some of the
arriving base exchange packets between the initiator and
responder. [Comment.1]
Rendezvous Client (RVC): A HIP Requester which has registered for the Rendezvous Server (RVS)
Rendezvous Service at a Rendezvous Server. A HIP registrar providing rendezvous service.
Rendezvous Registration (RVR): A HIP Registration for the Rendezvous Rendezvous Client
Service, established between a Rendezvous Server and a Rendezvous A HIP requester that has registered for rendezvous service at a
Client. rendezvous server.
Rendezvous Registration
A HIP registration for rendezvous service, established between a
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 HIP decouples domain names from IP addresses. Because transport
protocols bind to Host Identities, they remain unaware if the set of protocols bind to host identities, they remain unaware if the set of
IP addresses associated with a Host Identity changes. This change IP addresses associated with a host identity changes. This change
can have various reasons, including, but not limited to, mobility and can have various reasons, including, but not limited to, mobility and
multi-homing. 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 Rendezvous Server) Figure 2 shows a simple HIP base exchange without a rendezvous
in which the initiator initiates the exchange directly with the server, in which the initiator initiates the exchange directly with
responder by sending an I1 packet to the responder IP address, as per the responder by sending an I1 packet to the responder's IP address,
the HIP base specification [4]. as per the HIP base specification [4].
Proposed extensions for mobility and multi-homing [5] allow a HIP Proposed extensions for mobility and multi-homing [5] allow a HIP
node to notify its peers about changes in its set of IP addresses. node to notify its peers about changes in its set of IP addresses.
These extensions require an established HIP association between two These extensions require an established HIP association between two
nodes, i.e., a completed HIP Base Exchange. nodes, i.e., a completed HIP base exchange.
However, such a HIP node might also want to be still reachable by However, such a HIP node MAY also want to be reachable to other
potential future correspondent peers unaware of its location change. future correspondent peers that are unaware of its location change.
The HIP architecture [1] introduces Rendezvous Servers at which a HIP The HIP architecture [1] introduces rendezvous servers with whom a
node register its current HIT and IP addresses. The RVS basically HIP node MAY register its host identity tags (HITs) and current IP
relays HIP packet incoming at this HIT to the node IP address. Thus, addresses. An RVS relays HIP packets arriving for these HITs to the
a peer publishing its RVS IP address instead of its own is reachable node's registered IP addresses. When a HIP node has registered with
by means of rendezvous at its RVS IP address. an RVS, it SHOULD record the IP address of its RVS in its DNS record,
using the HIPRVS DNS record type defined in [12].
+-----+ +-----+
+--I1--->| RVS |---I1--+ +--I1--->| RVS |---I1--+
| +-----+ | | +-----+ |
| v | v
+-----+ +-----+ +-----+ +-----+
| |<------R1-------| | | |<------R1-------| |
| I |-------I2------>| R | | I |-------I2------>| R |
| |<------R2-------| | | |<------R2-------| |
+-----+ +-----+ +-----+ +-----+
Figure 2: HIP Base Exchange with Rendezvous Server Figure 2: HIP base exchange with a rendezvous server.
Figure 2 shows a HIP Base Exchange involving a Rendezvous Server RVS. Figure 2 shows a HIP base exchange involving a rendezvous server. It
It is assumed that HIP node R precedently used the HIP registration is assumed that HIP node R previously registered its HITs and current
protocol [2] to register with the RVS its HIT and IP address. When IP addresses with the RVS, using the HIP registration protocol [2].
the initiator I tries to establish contact with the responder, it When the initiator I tries to establish contact with the responder R,
does not need to know the current IP address of R. Instead, I is it MAY send the I1 of the base exchange either to one of R's DNS
aware of the RVS IP address of R, at which it sends an I1 packet. addresses or it MAY send it to the address of one of R's rendezvous
The RVS, noticing that the receiver HIT is not its own, but the HIT servers instead. Here, I obtains the IP address of R's rendezvous
of a HIP node registered for the rendezvous Service, would relay the server from R's DNS record and then sends the I1 packet of the HIP
I1 to the responder IP address. Typically the responder would then base exchange to RVS. RVS, noticing that the HIT contained in the
complete the exchange without further assistance from the RVS by arriving I1 packet is not one of its own, MUST check its current
sending an R1 directly to the initiator IP address. registrations to determine if if needs to relay the packets. Here,
it determines that the HIT belongs to R and then relays the I1 packet
to the registered IP address. R then completes the base exchange
without further assistance from RVS by sending an R1 directly to the
I's IP address, as obtained from the I1 packet.
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 of the IP header addresses in the IP header.
HIT-I,HIT-R HIT-I and HIT-R are respectively the Initiator and the
Responder HIT of the packet
REA:I A REA parameter containing the IP address i is
present in the HIP header
FROM:I A FROM parameter containing the IP address I is present
in the HIP header
TO:I A TO parameter containing the IP address I is present
in the HIP header
VIA:RVS A VIA_RVS parameter containing IP addresses RVS HIT-I, HIT-R HIT-I and HIT-R are the initiator's and the
is present in the HIP header responder's HITs in the packet, respectively.
EREQ An ECHO_REQUEST parameter is present in the HIP header LOC:I A LOCATOR parameter containing the IP address I is
present in the HIP header.
EREP An ECHO_REPLY parameter is present in the HIP header FROM:I A FROM parameter containing the IP address I is
present in the HIP header.
RREQ A REG_REQUEST parameter is present in the HIP header VIA:RVS A VIA_RVS parameter containing the IP addresses of an
RVS is present in the HIP header.
RRES A REG_RESPONSE parameter is present in the HIP header REG_REQ A REG_REQUEST parameter is present in the HIP header.
RVR:t1,t2 A RVR_TYPE parameter with Type value t1 and t2 is present REG_RES A REG_RESPONSE parameter is present in the HIP header.
in the HIP header.
3.2 Rendezvous Client Registering with a Rendezvous Server 3.2 Rendezvous Client Registration
Before the Rendezvous Server starts to relay HIP packets to their Before a rendezvous server starts to relay HIP packets to a
receiver HIT owner (i.e. a Rendezvous Client or one of its rendezvous client, the rendezvous client needs to register with it to
correspondent node), the Rendezvous Client needs to register with its receive rendezvous service by using the HIP registration extension
Server for the Rendezvous Service, as shown in the following schema: [2] as illustrated in the following schema:
+-----+ +-----+ +-----+ +-----+
| | I1 | | | | I1 | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| RVC | R1(REG_INFO,RVR:1,2) | RVS | | I | R1(REG_INFO) | RVS |
| | I2(REG_REQ,RVR:2) | | | | I2(REG_REQ) | |
| |--------------------------->| | | |--------------------------->| |
| |<---------------------------| | | |<---------------------------| |
| | R2(REG_RES,RVR:2) | | | | R2(REG_RES) | |
+-----+ +-----+ +-----+ +-----+
3.3 Establishing HIP Associations via Rendezvous Servers 3.3 Relaying the Base Exchange
3.3.1 Encapsulating I1 into a Tunnel
If a HIP node and one of its Rendezvous Servers have a Rendezvous
Registration of type TUNNEL_I1, the Rendezvous Server tunnels up to
this node I1s incoming to this node's HIT using the appropriate
encapsulation technique. The technique to be used is determined
based on the kind of association established between the RVS and its
client, and differs only by the type of header prepended to the HIP
packet (e.g. HIP, ESP or UDP).
ENCAP(RVS, R)[ I1(I, RVS, ]
[ HIT-I, HIT-R, ]
I1(I, RVS, HIT-I, HIT-R) +---------+ [ FROM:I) ]
+----------------------->| |--------------------+
| | RVS | |
| | | |
| +---------+ |
| V
+-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+
| |<---------------------------------------------| |
| | | |
| I | I2(I, R, HIT-I, HIT-R) | R |
| |--------------------------------------------->| |
| |<---------------------------------------------| |
+-----+ R2(R, I, HIT-R, HIT-I) +-----+
Figure 5: I1_TUNNEL: Rendezvous Server Encapsulating I1 into a Tunnel
3.3.2 Rewriting I1 IP Header
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 of type REWRITE_I1, the Rendezvous Server relays up to registration, the rendezvous servers MUST relay inbound I1 packets
this node I1s incoming to this node's HIT by merely rewrite the IP that contain one of the client's HITs by rewriting the IP header.
header. The destination IP address of the I1 is replaced by the IP They replace the destination IP address of the I1 packet with one of
address of the receiver HIT owner (i.e. the Rendezvous Client). the IP addresses of the owner of the HIT, i.e., the rendezvous
client. They MUST also recompute the IP checksum accordingly.
However, because of egress filtering, a HIP Rendezvous Server might Because of egress filtering on the path from the RVS to the client, a
also need to replace the original source IP address of an I1 by its HIP rendezvous server MAY also need to replace the source IP address,
own IP address, thus concealing the Initiator's IP address to the i.e., the IP address of I, with one of its own IP addresses. The
Responder. Hence, such a node MUST append I1 packets with a FROM replacement IP address SHOULD be chosen according to [6] and, when
parameter containing the original source IP address of the packet. IPv6 is used, to [7]. Because this replacement conceals the
This FROM parameter MUST be integrity protected by a RVR_HMAC keyed initiator's IP address, the RVS MUST append a FROM parameter
with the corresponding rendezvous registration integrity key [2]. containing the original source IP address of the packet. This FROM
parameter MUST be integrity protected by a RVS_HMAC keyed with the
corresponding rendezvous registration integrity key [2].
I1(I, RVS, HIT-I, I1(RVS, R, HIT-I, HIT-R
I1(I, RVS, HIT-I, HIT-R) +---------+ HIT-R, FROM:I, VIA:RVS) I1(I, RVS, HIT-I, HIT-R) +---------+ FROM:I, VIA:RVS)
+----------------------->| |--------------------+ +----------------------->| |--------------------+
| | RVS | | | | RVS | |
| | | | | | | |
| +---------+ | | +---------+ |
| V | V
+-----+ R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS) +-----+ +-----+ R1(R, I, HIT-R, HIT-I, LOC:R, 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 6: I1_REWRITE: Rendezvous Server Rewriting I1 Source and Figure 5: Rendezvous server rewriting IP addresses
Destination IP Addresses This modification of HIP packets at a rendezvous server can be
problematic. The HIP protocol uses two kinds of packet integrity
3.3.3 Bidirectional Forwarding of HIP packets checks: hop-by-hop and end-to-end. The HIP checksum is a hop-by-hop
check and SHOULD be verified and recomputed by each of the on-path
In some cases it is useful to have a RVS which relay further HIP HIP-enabled middleboxes, such as rendezvous servers. The HMAC and
packets in a bidirectional manner, i.e. from the initiator to the SIGNATURE are end-to-end checks and MUST be computed by the sender
responder but also from the responder to the initiator. These and verified by the receiver.
further packets would typically be either an R1 or an UPDATE. A RVS
behaves accordingly when the Rendezvous Registration Type is
BIDIRECTIONAL.
However, because such packets are larger than I1 (they contain a
signature), their relaying create an opportunity for denial of
service attacks. To defend against these attacks, the Rendezvous
Server needs to differentiate between legitimate HIP packets (i.e.,
I1 and subsequent HIP packets triggered by an I1) and illegitimate
ones.
For the sake of reducing the load incurred on the RVS, an RVS is not
required to keep track of IP addresses and other pieces of state
associated with ongoing HIP exchanges. Such behavior is OPTIONAL.
Instead, the relaying facility SHOULD make use of ECHO_REQUEST and
ECHO_RESPONSE parameters.
Each time a packet is being relayed and will possibly trigger an
answer, the RVS MUST augment it with an ECHO_REQUEST parameter
containing a chunk of opaque data. The receiver of such a packet
MUST augment any packet answering to this packet with an ECHO_REPLY
parameter containing the same chunk of opaque data. This opaque data
allows an RVS to find and validate the answered packet IP addresses
and HITs. When successfully validated, ECHO_REPLY parameters MUST be
removed from the packet before relaying.
I1(I, RVS, I1(RVS, R, HIT-I, HIT-0
HIT-I, HIT-0) +---------+ FROM:I, EREQ)
+-------------------->| |----------------------+
|+--------------------| |<--------------------+|
|| R1(RVS, I, HIT-R, | RVS | R1(R, RVS, HIT-R, ||
|| HIT-I, REA:R, | | HIT-I, REA:R, ||
|| VIA:RVS) | | TO:I, EREP) ||
|| | | ||
|| +---------+ ||
|V |V
+-----+ I2(R, I, HIT-R, HIT-I) +-----+
| |-------------------------------------------->| |
| I |<--------------------------------------------| R |
| | R2(I, R, HIT-I, HIT-R) | |
+-----+ +-----+
Figure 7: BIDIRECTIONAL: Responder replying via the RVS to Initiator
3.3.4 Implication on the HIP integrity checks
The establishment of HIP associations via one or more Rendezvous
Servers causes HIP packets flowing between the HIP nodes to be
modified during transmission. Several kinds of modifications to both
the IP and HIP headers are possible. The HIP protocol uses two kinds
of packet integrity checks: hop-by-hop and end-to-end. The HIP
checksum is a hop-by-hop check and SHOULD be verified and recomputed
by each of the on-path HIP middle-boxes (e.g., Rendezvous Servers).
The HMAC and SIGNATURE are end-to-end checks and MUST be computed by
the sender and verified by the receiver.
3.3.4.1 Checksum
The checksum field of a HIP header to be modified MUST be verified
before applying the modification and recomputed accordingly after.
3.3.4.2 HMAC and SIGNATURE
The HMAC and SIGNATURE field of a HIP header MUST be computed and
verified based on a "sender view" or "receiver view" of the HIP
header. In particular, this implies that SIGNATURE and HMAC MUST NOT
cover FROM and TO parameters added or removed by Rendezvous Servers
and that the HIP pseudo-header used to compute and verify them MUST
contain the IP addresses as seen by the remote HIP peer. In case of
IP address concealment by the RVS, this means that the IP address of
this RVS MUST be used in the pseudo-header in place of the IP address
of the end host it conceals.
3.3.4.3 Example
Here is an example showing how to compute the different integrity
checks (end-to-end and hop-by-hop) when two Rendezvous Servers are
cascaded and conceals the Responder IP address (packet flowing along
the path I -> RVS1 -> RVS2 -> R)
End-to-end integrity checks: HMAC and SIGNATURE are computed with a
pseudo-header containing RVS1 as a place holder for the destination
IP address, the rationale being that RVS1 is concealing the Responder
IP address. Therefore, R will verify the signature using RVS1 as the
destination IP address in the pseudo-header.
Hop-by-hop integrity checks: Checksum is computed hop-by-hop; first
with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and
R.
4. RVS Extensions Definition
The following sections describe extensions to:
o The HIP registration protocol [2], allowing a HIP node to register
with its Rendezvous Server for the Rendezvous Service and maintain
the RVS aware of its current location.
o The HIP protocol [4] itself, allowing to establish an HIP
association via one or more HIP Rendezvous Server(s).
4.1 Usage and Processing of Existing Parameters
4.1.1 ECHO_REQUEST and ECHO_REPLY Parameters
A FROM parameter MAY be augmented by including an ECHO_REQUEST
parameter to the carrying packet. The contents of the ECHO_REQUEST
MUST then be echoed back in ECHO_RESPONSE.
A TO parameter MUST be augmented and authenticated by including an The RVS MUST verify the checksum field of an I1 packet doing any
ECHO_REPLY parameter to the carrying packet. The contents of the modifications. After modification, it MUST recompute the checksum
ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE. 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.
All the HIP packets requiring RVS relaying facility to carry an The SIGNATURE and HMAC verification MUST NOT cover any FROM and
answer packet MUST be augmented by the RVS with an ECHO_REQUEST RVS_HMAC parameters added by rendezvous servers. Hence, HMAC and
parameter. SIGNATURE are unaffected by the modifications performed by an RVS.
The computation and verification of HMAC and SIGNATURE MUST only
cover the original HIP header with a checksum field set to zero, MUST
NOT cover the pseudo header that contains modified IP addresses, and
mUST NOT cover any new FROM and RVS_HMAC parameters that MAY be
situated after the HMAC and SIGNATURE in the HIP header.
A possible packet answered via the RVS, thus requiring relaying 4. Rendezvous Server Extensions
facility, MUST be authenticated by an ECHO_REPLY parameter. The
contents of the ECHO_REPLY MUST be copied from a previously received
ECHO_RESPONSE.
On the receiving side, when a HIP node validates an ECHO_REPLY The following sections describe extensions to the HIP registration
located after the signatures, it MUST remove it from the packet and protocol [2], allowing a HIP node to register with a rendezvous
recompute packet length and checksum accordingly. server for rendezvous service and notify the RVS aware of changes to
its current location. It also describes an extension to the HIP
protocol [4] itself, allowing establishment of HIP associations via
one or more HIP rendezvous server(s).
4.1.2 REA Parameter 4.1 LOCATOR Parameter
A HIP node associated via an RVS MAY use a REA parameter to make its A HIP responder contacted via an RVS MAY use a LOCATOR parameter in
correspondent aware of its veritable current IP address. If used, the R1 packet to notify the initiator of its current IP address, in
the REA parameter MUST be used in conformance with the guidelines conformance with the guidelines specified in [5].
specified in [5].
4.2 New Registration Type 4.2 RENDEZVOUS Registration Type
This specification defines an additional Registration Type to use This specification defines an additional registration for the HIP
within the HIP Registration protocol [2] while registering with a registration protocol [2] that allows registering with a rendezvous
Rendezvous Server for the Rendezvous Service. server for rendezvous service.
Number Registration Type Number Registration Type
------ ----------------- ------ -----------------
1 RENDEZVOUS 1 RENDEZVOUS
4.3 New Parameter Formats and Processing 4.3 New Parameter Formats and Processing
4.3.1 RVR_TYPE Parameter 4.3.1 RVS_HMAC Parameter
The RVR_RYPE is an OPTIONAL parameter allowing a Rendezvous Server
and its Requesters to negotiate the type of Rendezvous Service
provided by a Rendezvous Registration.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RVR Type #1 | RVR Type #2 | |
+-+-+-+-+-+-+-+-+---------------+ Padding |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA {110) ]
Length 8
RVR Type An 8 bit number indicating the specific type of the
Rendezvous Server/Service.
Number RVR Type Definition
------ ------------- -----------------------
1 TUNNEL_I1 Tunneling I1 - Section 3.3.1
2 REWRITE_I1 Rewriting I1 - Section 3.3.2
3 BIDIRECTIONAL Rewriting I1 and followers - Section 3.3.3
3-200 Reserved by IANA
201-255 Reserved by IANA for private use
A Requester of a Rendezvous Registration SHOULD include the RVR_RYPE
parameter along with any REG_REQUEST for the Rendezvous Service.
This parameter specifies the desired RVS Type (i.e. TUNNEL_I1,
REWRITE_I1 or BIDIRECTIONAL). It SHOULD NOT include the parameter
unless there is a REG_REQUEST parameter included along.
A Rendezvous Server SHOULD include a RVR_TYPE parameter along with
any REG_INFO announcing support for the Rendezvous Service. This
parameter SHOULD specify all the RVR Types supported by the
Rendezvous Server, in preference order.
A Rendezvous Server MUST include a RVR_RYPE parameter along with any
REG_RESPONSE establishing a Rendezvous Registration. This parameter
MUST specify a single RVR Type for the established Registration.
A Rendezvous Server SHOULD NOT include the parameter unless there is
a REG_INFO or REG_REQUEST parameter included along.
4.3.2 RVR_HMAC Parameter
The RVR_HMAC is an OPTIONAL parameter whose only difference with the The RVS_HMAC is an OPTIONAL parameter whose only difference with the
HMAC parameter defined in [4] is the Type code, making it situated HMAC parameter defined in [4] is its "type" code. This change causes
after the TO and FROM parameters (as opposed to HMAC): it to be located after the FROM parameter (as opposed to the HMAC):
Type [ TBD by IANA {65320) ] Type [ TBD by IANA (65472 = 2^16 - 2^6) ]
Length 20 Length 20
HMAC 160 low order bits of a HMAC keyed with the appropriate HMAC 160 low order bits of a HMAC keyed with the
HIP integrity keys (HIP_lg or HIP_gl) of the corresponding appropriate HIP integrity key (HIP_lg or HIP_gl),
HIP Association. This HMAC is computed over the HIP packet established when rendezvous registration happened.
excluding RVR_HMAC and any other following parameter. This HMAC is computed over the HIP packet, excluding
The checksum field MUST be set to zero and the HIP header RVS_HMAC and any following parameters. The
length in the HIP common header MUST be calculated not to "checksum" field MUST be set to zero and the HIP header
cover any excluded parameter when the Authenticator field length in the HIP common header MUST be calculated
is calculated. not to cover any excluded parameter when the
"authenticator" field is calculated.
To allow a Rendezvous Client and its RVS to verify the integrity of
packets flowing between them, both use an RVR_HMAC parameter keyed
with a HMAC of HIP_lg and HIP_gl integrity keys. One RVR_HMAC SHOULD
be present on every packets flowing between a client and a server and
MUST be present when FROM and TO parameters are processed.
On the receiving side, when an RVR_HMAC is validated, it SHOULD be
removed from the packet and if so, packet length and checksum MUST be
recomputed accordingly.
4.3.3 FROM Parameter
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Address |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type [ TBD by IANA {65100 under signature, 65300 after) ]
Length 16
Address An IPv6 address or an IPv4-in-IPv6 format IPv4 address
A Rendezvous Server MAY add a FROM parameter containing the original
source IP address of a HIP packet whose source IP address has been
rewritten. If one or more FROM parameters are already present, the
new FROM parameter MUST be appended after the existing ones.
Each time an RVS inserts a FROM parameter, it MUST also insert an
RVR_HMAC protecting the packet integrity that the Rendezvous Client
will use to validate this packet.
If the type of the RVR allows the Rendezvous Client to answer to a
relayed packet via the RVS, an ECHO_REQUEST MUST be included along
with the FROM parameter. It contains a chunk of opaque data allowing
to validate TO parameters included in a subsequent answer. These TO
parameters MUST be protected by an ECHO_RESPONSE containing the same
opaque data.
When a HIP node validates a FROM parameter, it is removed from the
packet and recorded for later use (i.e., for building the
corresponding TO parameter to be piggy-backed onto a subsequent
answer). The packet's source IP address is also replaced by the
address included in the first occurrence of FROM parameter.
For each FROM parameter, a HIP node MAY add to its replies a TO To allow a rendezvous client and its RVS to verify the integrity of
parameter containing the IP address included in the FROM. These packets flowing between them, both SHOULD protect packets with an
replies will be sent via the RVS, which MUST remove the outer TO added RVS_HMAC parameter keyed with the HIP_lg or HIP_gl integrity
parameter from the packet and replace its destination address with key. A valid RVS_HMAC SHOULD be present on every packets flowing
the address contained in the TO parameter before relaying it. between a client and a server and MUST be present when a FROM
parameters is processed.
4.3.4 TO Parameter 4.3.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 {65102 under signature, 65302 after) ] Type [ TBD by IANA (65470 = 2^16 - 2^6 - 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 HIP node MAY add one or more TO parameter containing the final
destination IP address of a HIP packet whose destination IP address
needs to be rewritten by an RVS. This is essentially equivalent to
loose source-routing. If one or more TO parameters are already
present, the new TO parameter MUST be appended after the existing
ones. Each time a node inserts a TO parameter, it MUST also insert
additional parameters that will be used by the RVS for validation.
These parameters are:
o An ECHO_RESPONSE, containing a chunk of opaque data allowing the
RVS to validate the address contained in the TO parameter.
o A valid RVR_HMAC, protecting the packet integrity.
When the RVS validates a TO parameter, SHALL remove it from the A rendezvous server MUST add a FROM parameter containing the original
packet, and SHALL replace the packet destination IP address with the source IP address of a HIP packet whenever the source IP address in
address included in the TO parameter. Packet length and checksum the IP header is rewritten. If one or more FROM parameters are
MUST then be recomputed accordingly. already present, the new FROM parameter MUST be appended after the
existing ones.
For each FROM parameter, a HIP node MAY add to its replies a TO Whenever an RVS inserts a FROM parameter, it MUST insert an RVS_HMAC
parameter containing the IP address included in the FROM. These protecting the packet integrity, especially the IP address included
replies will be sent via the RVS, which MUST remove the outer TO in the FROM parameter.
parameter from the packet and replace its destination address field
with the address contained in the TO parameter before relaying it.
4.3.5 VIA_RVS Parameter 4.3.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 {65500) ] Type [ TBD by IANA (65474 = 2^16 - 2^6 + 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
At some point a, HIP endpoint might be in position to begin to send After the responder receives a relayed I1 packet, it can begin to
HIP packets directly towards the remote HIP endpoint's IP address, send HIP packets addressed to the initiator's IP address, without
without further assistance from one or more of its RVS(s). In that further assistance from an RVS. For debugging purposes, it MAY
case, it MAY include in these packets a subset of the IP address(es) include a subset of the IP addresses of its RVSs in some of these
of its RVSs for debugging purposes. 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
using the VIA_RVS parameter is to allow operators to diagnose
possible issues encountered while establishing a HIP association via
a RVS.
Similarly, a RVS relaying an I1 to the Responder or an R1 to the 4.4 Processing Outgoing I1 Packets
Initiator MAY include in these packets its IP address for debugging
as well.
When the IP address of a RVS need to be included in a packet, by An initiator SHOULD not send an opportunistic I1 with a NULL
either an end-node or the RVS itself, one of these two methods is destination HIT to an IP address which is known to be a rendezvous
used: server address, unless it wants to establish a HIP association with
the rendezvous server itself and does not know its HIT.
o Add RVS IP address into an existing VIA_RVS parameter situated at If an RVS needs to rewrite the source IP address of an I1 packet due
the end of the HIP packet, while modifying accordingly the size of to egress filtering, then it MUST add a FROM parameter to the I1 that
the parameter. contasins the initiator's source IP address. This FROM parameter
MUST be protected by a RVS_HMAC keyed with the integrity key
established at rendezvous registration.
o Append a newly created VIA_RVS parameter at the end of the HIP 4.5 Processing Incoming I1 packets
packet if it does not already contain a VIA_RVS parameter.
Note that the main goal of using the VIA_RVS parameter is to allow When a rendezvous server receives an I1 whose destination HIT is not
operators to diagnose possible issues encountered while establishing its own, it MUST consult its registration database to find a
a HIP association via a RVS. registration for the rendezvous service established by the HIT owner.
If it finds an appropriate registration, it MUST relay the packet to
the registered IP address. If it does not find an appropriate
registration, is MUST drop the packet.
A rendezvous server SHOULD interpret any incoming opportunistic I1
(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.
When a rendezvous client receives an I1, it MUST validate any present
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
parameter is present, the packet MUST be dropped.
A rendezvous client acting as responder SHOULD drop opportunistic I1s
that include a FROM parameter, because this indicates that the I1 has
been relayed.
5. Security Considerations 5. Security Considerations
The security aspects of different HIP rendezvous mechanisms are The security aspects of different HIP rendezvous mechanisms are
currently being investigated. This section describes the known currently being investigated. This section describes the known
threats introduced by these HIP extensions, and implications on the threats introduced by these HIP extensions and implications on the
overall security of HIP and IP. In particular, the following tries overall security of HIP and IP. In particular, it argues that the
to show that the extensions described in this document do not extensions described in this document do not introduce additional
introduce additional threats in the Internet infrastructure. 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 have implications both at rendezvous servers, because their presence has implications both at
the IP and HIP layer. In particular, the extensions hereby described the IP and HIP layers. In particular, these extensions might allow
might allow for redirection, amplification and reflection attacks at for redirection, amplification and reflection attacks at the IP
the IP layer, as well as attacks on the HIP layer itself, for example layer, as well as attacks on the HIP layer itself, for example, man-
Man-in-the-Middle attacks against the cryptographic core-protocol in-the-middle attacks against HIP's SIGMA protocol.
SIGMA used by HIP.
If an Initiator has an a priori knowledge of the Responder's HI when If an initiator has a priori knowledge of the responder's host
it first contacts it via the RVS, it has a means to verify the identity when it first contacts it via an RVS, it has a means to
signatures in the HIP exchange, thus conforming to the SIGMA protocol verify the signatures in the HIP exchange, thus conforming to the
which is resilient to Man-in-the-Middle attacks. SIGMA protocol which is resilient to man-in-the-middle attacks.
If an Initiator has not an a priori knowledge of the Responder's HI If an initiator does not have a priori knowledge of the responder's
(so called Opportunistic Initiators), it is almost impossible to host identiy (so-called "opportunistic initiators"), it is almost
defend the HIP exchange against MitM attacks (cannot authenticate impossible to defend the HIP exchange against these attacks, because
public keys exchanged). The only solution is to mitigate hijacking the public keys exchanged cannot be authenticated. The only approach
threats on the HIP state by requiring an R1 answering an would be to mitigate hijacking threats on HIP state by requiring an
Opportunistic I1 to come from the IP address where the I1 was R1 answering an opportunistic I1 to come from the same IP address
initially sent. That way we retain a level of security which is that originally sent the I1. This procedure retains a level of
equivalent to what exists today in the Internet: By sending an IP security which is equivalent to what exists in the Internet today.
packet to an IP address, and receiving an answered IP packet from
this same IP address, I know that the routing fabric trusts my However, for reasons of simplicity, this specification does not allow
correspondent to be represented by this IP address. While it is true to establish a HIP association via a rendezvous server in an
that such security is weak, it is better than none, and avoids to opportunistic manner.
introduce additional threats at the IP layer.
6. IANA Considerations 6. IANA Considerations
This section is to be interpreted according to [8].
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.3:
o RVR_TYPE (defined in Section 4.3.1) o RVS_HMAC (defined in Section 4.3.1)
o RVR_HMAC (defined in Section 4.3.2)
o FROM (defined in Section 4.3.3)
o TO (defined in Section 4.3.4)
o VIA_RVS (defined in Section 4.3.5)
IANA needs to open a new registry specific to the HIP Rendezvous
Extensions, for the Rendezvous Registration (RVR) Types values
defined in Section 4.3.1:
Type number RVR Type
----------- --------
0 Reserved by IANA
1 TUNNEL_I1
2 REWRITE_I1
3 BIDIRECTIONAL
3-200 Reserved by IANA
201-255 Reserved by IANA for private use o FROM (defined in Section 4.3.2)
Adding new reservations requires IETF consensus RFC2434 [7]. o VIA_RVS (defined in Section 4.3.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, Simon Schuetz, Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Justino
Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen Santos, Simon Schuetz, Tim Shepard, Kristian Slavov, Martin
Quittek. Stiemerling and Juergen Quittek.
Part of this work is a product of the Ambient Networks project, Lars Eggert is partly funded by Ambient Networks, a research project
partially supported by the European Commission under its Sixth supported by the European Commission under its Sixth Framework
Framework Programme. It is provided "as is" and without any express Program. The views and conclusions contained herein are those of the
or implied warranties, including, without limitation, the implied authors and should not be interpreted as necessarily representing the
warranties of fitness for a particular purpose. The views and official policies or endorsements, either expressed or implied, of
conclusions contained herein are those of the authors and should not the Ambient Networks project or the European Commission.
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
[1] Moskowitz, R. and P. Nikander, "Host Identity Protocol [1] Moskowitz, R., "Host Identity Protocol Architecture",
Architecture", draft-ietf-hip-arch-00 (work in progress), draft-ietf-hip-arch-02 (work in progress), January 2005.
October 2004.
[2] Laganier, J., Koponen, T. and L. Eggert, "Host Identity Protocol [2] Koponen, T. and L. Eggert, "Host Identity Protocol (HIP)
(HIP) Registration Extensions", Registration Extension", draft-koponen-hip-registration-00 (work
draft-koponen-hip-registration-00 (work in progress), January in progress), February 2005.
2005.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[4] Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity [4] Moskowitz, R., "Host Identity Protocol", draft-ietf-hip-base-02
Protocol", draft-ietf-hip-base-01 (work in progress), October (work in progress), February 2005.
2004.
[5] Nikander, P., "End-Host Mobility and Multi-Homing with Host [5] Nikander, P., "End-Host Mobility and Multi-Homing with Host
Identity Protocol", draft-ietf-hip-mm-00 (work in progress), Identity Protocol", draft-ietf-hip-mm-01 (work in progress),
October 2004. February 2005.
[6] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[7] Draves, R., "Default Address Selection for Internet Protocol
version 6 (IPv6)", RFC 3484, February 2003.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
8.2 Informative References 8.2 Informative References
[6] Saltzer, J., "On the Naming and Binding of Network [9] Saltzer, J., "On the Naming and Binding of Network
Destinations", RFC 1498, August 1993. Destinations", RFC 1498, August 1993.
[7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [10] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic
Considerations Section in RFCs", BCP 26, RFC 2434, October Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
1998. April 1997.
[8] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP) [11] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Domain Name System (DNS) Extensions", draft-ietf-hip-rvs-00 Update", RFC 3007, November 2000.
(work in progress), October 2004.
[9] Ferguson, P. and D. Senie, "Network Ingress Filtering: [12] Nikander, P. and J. Laganier, "Host Identity Protocol (HIP)
Domain Name System (DNS) Extensions", draft-ietf-hip-dns-01
(work in progress), February 2005.
[13] 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.
[10] Killalea, T., "Recommended Internet Service Provider Security [14] Killalea, T., "Recommended Internet Service Provider Security
Services and Procedures", BCP 46, RFC 3013, November 2000. Services and Procedures", BCP 46, RFC 3013, November 2000.
Editorial Comments
[Comment.1] 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.
Authors' Addresses Authors' Addresses
Julien Laganier Julien Laganier
Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL) DoCoMo Communications Laboratories Europe GmbH
180, Avenue de l'Europe Landsberger Strasse 312
Saint Ismier CEDEX 38334 Munich 80687
FR Germany
Phone: +33 476 188 815 Phone: +49 89 56824 231
EMail: ju@sun.com Email: julien.ietf@laposte.net
URI: http://research.sun.com/ URI: http://www.docomolab-euro.com/
Lars Eggert Lars Eggert
NEC Network Laboratories NEC Network Laboratories
Kurfuersten-Anlage 36 Kurfuerstenanlage 36
Heidelberg 69115 Heidelberg 69115
DE Germany
Phone: +49 6221 90511 43 Phone: +49 6221 90511 43
Fax: +49 6221 90511 55 Fax: +49 6221 90511 55
EMail: lars.eggert@netlab.nec.de Email: lars.eggert@netlab.nec.de
URI: http://www.netlab.nec.de/ URI: http://www.netlab.nec.de/
Appendix A. Document Revision History Appendix A. Document Revision History
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| Revision | Comments | | Revision | Comments |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
| 02 | Removed multiple relaying techniques but simple I1 |
| | header rewriting. Updated new HIP parameters type |
| | numbers (consistent with new layout and assigning |
| | rules from draft-ietf-hip-base.) Updated IANA |
| | Considerations. |
| 01 | Splitted out the registration sub-protocol. Simplify | | 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. |
+-----------+-------------------------------------------------------+ +-----------+-------------------------------------------------------+
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
 End of changes. 

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