HIP Working Group                                            J. Laganier
Internet-Draft                                    LIP / Sun Microsystems
Expires: April 18, August 19, 2005                                       L. Eggert
                                                                     NEC
                                                        October
                                                       February 18, 2004 2005

           Host Identity Protocol (HIP) Rendezvous Extensions
                         draft-ietf-hip-rvs-00 Extension
                         draft-ietf-hip-rvs-01

Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of section 3 of RFC 3667.  By submitting this Internet-Draft, each
   author represents that any applicable patent or other IPR claims of
   which he or she is aware have been or will be disclosed, and any of
   which he or she become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 18, August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2004). (2005).

Abstract

   This document discusses rendezvous extensions a Rendezvous extension for the Host Identity
   Protocol (HIP).  The Rendezvous mechanisms extension extend HIP and the HIP
   registration extension for initiating communication
   with between HIP nodes
   via HIP Rendezvous Servers.  Rendezvous Servers improve operation
   when HIP nodes are multi-homed or mobile.  The first part of his
   document motivates the need for rendezvous mechanisms; the second
   part describes the protocol extensions in detail.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4  3
   3.  Communication Between HIP Nodes  Overview of Rendezvous Server Operation  . . . . . . . . . . .  4
     3.1   Diagram Notation . . . . . . . . .  4
   4.  Communication Between Mobile or Multi-Homed HIP Nodes . . . .  6
     4.1   Mobility and Multi-Homing with DNS Updates . . . . . . . .  6
     4.2   Mobility and Multi-Homing
     3.2   Rendezvous Client Registering with a Rendezvous Servers  . . Server . .  8
   5.  6
     3.3   Establishing HIP Extensions for Associations via Rendezvous Servers . . .  7
       3.3.1   Encapsulating I1 into a Tunnel . . . . . . . . . 10
     5.1   Additional RVS_CAPABLE Control Field . . . . . .  7
       3.3.2   Rewriting I1 IP Header . . . . . 10
     5.2   Additional HIP Parameters . . . . . . . . . . .  7
       3.3.3   Bidirectional Forwarding of HIP packets  . . . . . 10
       5.2.1   RVA_REQUEST Parameter Format and Processing . .  8
       3.3.4   Implication on the HIP integrity checks  . . . 10
       5.2.2   RVA_REPLY Parameter Format and Processing . . . .  9
   4.  RVS Extensions Definition  . . 12
       5.2.3   RVA_HMAC Parameter Format and Processing . . . . . . . 12
       5.2.4   FROM Parameter Format and Processing . . . . . . . . . 13
       5.2.5   TO Parameter Format 10
     4.1   Usage and Processing of Existing Parameters  . . . . . . . 11
       4.1.1   ECHO_REQUEST and ECHO_REPLY Parameters . . . 14
       5.2.6   VIA_RVS Parameter Format and Processing . . . . . 11
       4.1.2   REA Parameter  . . 15
     5.3   Use of Existing HIP Messages and Parameters . . . . . . . 16
       5.3.1   ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 16
       5.3.2   REA Parameter . . . 11
     4.2   New Registration Type  . . . . . . . . . . . . . . . . . 16
   6.  Diagram Notation . 11
     4.3   New Parameter Formats and Processing . . . . . . . . . . . 11
       4.3.1   RVR_TYPE Parameter . . . . . . . . . . . 17
   7.  Establishing Rendezvous Associations . . . . . . . 12
       4.3.2   RVR_HMAC Parameter . . . . . . 17
   8.  Establishing HIP Associations via Rendezvous Servers . . . . . 20
     8.1   Sending a Redirect in Reply to I1 . . . . . . . 13
       4.3.3   FROM Parameter . . . . . 20
     8.2   Passing I1 onto an ESP SA . . . . . . . . . . . . . . . 14
       4.3.4   TO Parameter . 21
     8.3   Rewriting I1 Destination IP Address . . . . . . . . . . . 22
     8.4   Rewriting I1 Source and Destination IP Addresses . . . . . 23
     8.5   Rewriting I1 and R1 Source and Destination IP Addresses . 24
     8.6   Cascading Rendezvous Servers . . . 15
       4.3.5   VIA_RVS Parameter  . . . . . . . . . . . . 26
     8.7   Implication on the HIP integrity checks . . . . . . 16
   5.  Security Considerations  . . . 27
       8.7.1   Checksum . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . 27
       8.7.2   HMAC and SIGNATURE . . . . . . . . . . . . . . 17
   7.  Acknowledgments  . . . . 27
       8.7.3   Example . . . . . . . . . . . . . . . . . . . . . . . 28
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 28
   10.   IANA Considerations  . . . . . . . . . . . . . . . . . . . . 29
   11.   Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 29
   12. 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . 30
   12.1 . 19
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 30
   12.2 19
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 31 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 31 20
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 32 20
       Intellectual Property and Copyright Statements . . . . . . . . 33 21

1.  Introduction

   The current Internet uses two global namespaces: domain names and IP
   addresses.  The Domain Name System (DNS) provides has a two-way lookup
   service between the two [1].  Domain names are symbolic identifiers
   for sets dual use of IP addresses.

   IP addresses have two uses.  First, they are
   topological locators for network attachment points.  Second, they act
   as names for the attached network interfaces.  Saltzer [11] [6] discusses
   these naming concepts in detail.  Routing and other network-layer
   mechanisms are based on the locator aspects of IP addresses.
   Transport-layer protocols and mechanisms typically use IP addresses
   in their role as names for communication endpoints.  This dual use of
   IP addresses limits the flexibility of the Internet architecture.
   The need to avoid readdressing in order to maintain existing
   transport-layer connections complicates advanced functionality, such
   as mobility, multi-homing, or network composition.

   The Host Identity Protocol (HIP) architecture [2] [1] defines a new third
   namespace.  The Host Identity namespace decouples the name and
   locator roles currently filled by IP addresses.  Instead of mapping
   domain names directly into IP addresses, HIP maps domain names into
   Host Identities, and Host Identities into 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.

   Without HIP, nodes establish transport-layer connections by first
   looking up the fully-qualified domain name (FQDN)  Because of a peer in the
   DNS.  A successful DNS lookup returns this decoupling the peer's HIP layer
   needs to map Host Identities into IP addresses.  A

   Without HIP, a node uses one of the returned IP addresses needs to initiate
   transport-layer communication with a know its peer node.

   HIP nodes will also look up the domain name IP address to make an
   initial contact.  The Host Identity Protocol architecture [1]
   introduces an additional piece of desired peers in infrastructure, the
   DNS, Rendezvous
   Server (RVS), which serves as specified in an initial contact point (rendezvous)
   for nodes trying to reach the HIP DNS Extensions[3].  When a successful
   lookup includes RVS clients.  A RVS offers to a peer's Host Identities, HIP nodes perform peer it
   serves to relay to its IP address the first packet of a HIP
   Base Exchange before establishing transport-layer connections.  The
   HIP Base Exchange authenticates exchange
   incoming at the end hosts RVS IP address and can bootstrap
   encryption of the subsequent communication with IPsec [12].  The HIP
   specification [4] discusses the details of the Base Exchange peer receiver HIT.  A
   peer uses the HIP Registration Protocol [2] to register its HIT->IP
   address mapping with its RVS.  Then an initiator and responder can
   have rendezvous together at the
   related protocol exchanges. RVS IP address.  The initiator would
   send a I1 packet to the RVS IP address, which would then relay the I1
   to the responder IP address.  Then, further communications would
   typically occurs directly without further assistance from the RVS.

   After the Base Exchange, HIP nodes use Host Identities instead of IP
   addresses for to name transport-layer connections with a peer. endpoints.  The HIP layer in the
   network stack internally translates Host Identities (HI) into
   network-layer IP addresses.  This additional mapping between Host
   Identities and IP addresses (HI->IP) is logically separate from the
   first mapping between fully-qualified domain names and Host
   Identities (FQDN->HI).

   For application and transport-layer compatibility, the FQDN->HI
   mapping must remain in the DNS.  However, the HI->IP mapping is
   internal to the HIP layer and may be performed in a number of ways.
   Different lookup mechanism may support communication between two
   mobile or multi-homed HIP nodes better [5].

2.  Terminology

   Rendezvous Server (RVS): A HIP enabled node which relays incoming HIP
   I1 packets to the owner of the receiver HIT contained in the I1
   header.  A RVS may also relay back an R1 to an opportunistic
   Initiator.

   Rendezvous Association (RVA): A lightweight HIP association
   established between a HIP node and its RVS.  The associated state
   doesn't require communication to be maintained and contains the
   peer's HIT, two symmetric integrity keys, and

   This section defines terms used throughout the IP addresses remainder of
   both nodes. this
   specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [6].

3.  Communication Between [3].

   Rendezvous Service : A HIP Nodes

   In the current Internet, the DNS provides a FQDN->IP mapping.  With
   HIP, it must continue to provide Service provided by a mapping based on domain names.
   This allows transport-layer connections HIP Rendezvous
   Server to bind its Rendezvous Clients.  The Rendezvous Server offers to Host Identities
   instead of IP addresses transparently.

   Instead
   relay some of mapping domain names directly into IP addresses
   (FQDN->IP), with HIP the DNS maps them to Host Identities (FQDN->HI).
   In incoming HIP packets exchanged during a second step, another lookup that is internal HIP
   exchange to the HIP-layer
   translates owner of their receiver HIT (i.e.  the Host Identities into IP addresses for network-layer
   delivery (HI->IP).

   Several alternative approaches are possible for maintaining Rendezvous
   Client or one of its correspondent nodes).

   Rendezvous Server (RVS): A HIP Registrar providing the
   HI->IP information.  The DNS can maintain this mapping along with Rendezvous
   Service.

   Rendezvous Client (RVC): A HIP Requester which has registered for the
   FQDN->HI mapping.  Alternatively,
   Rendezvous Service at a database separate from the DNS
   can manage this information.  This section discusses the different
   approaches and their implications on communication between two HIP
   nodes.

   The Rendezvous Server.

   Rendezvous Registration (RVR): A HIP architecture, protocol and DNS extensions specifications
   suggest storing Host Identities along with a node's IP addresses in
   the DNS [3][2][4].  The index Registration for both tables will be domain names.
   Logically, the DNS will thus contain two separate mappings: FQDN->HI
   and FQDN->IP.

   Figure 1 shows the lookup steps Rendezvous
   Service, established between a Rendezvous Server and HIP Base Exchange when a node's
   Host Identities are stored alongside its Rendezvous
   Client.

3.  Overview of Rendezvous Server Operation

   HIP decouples domain names from IP addresses.  In step #1,
   the Initiator I performs a DNS lookup on R's domain name FQDN(R).
   The DNS server responds with both R's  Because transport
   protocols bind to Host Identities HI(R) and its Identities, they remain unaware if the set of
   IP addresses IP(R) in step #2 (Details can be found in  [4]).

   The Initiator I uses both pieces of information to perform the HIP
   Base Exchange associated with R in step #3.  (The details of the Base Exchange,
   specified in [4], are a Host Identity changes.  This change
   can have various reasons, including, but not relevant to this discussion limited to, mobility and will thus
   be omitted.)

                       #1 FQDN(R)      +----------+
                 +-------------------->|   DNS    |
                 | +-------------------|          |
                 | |  #2 HI(R), IP(R)  | FQDN->HI |
                 | |                   | FQDN->IP |
                 | |                   +----------+
                 | V
   multi-homing.

   +-----+       #3 HIP Base Exchange                +-----+
   |     |-------------------------------->|     |-------I1------>|     |
   |  I  |<--------------------------------|  |<------R1-------|  R  |
   |     |-------------------------------->|     |-------I2------>|     |
   |     |<--------------------------------|     |<------R2-------|     |
   +-----+                +-----+

         Figure 1: HIP Lookup and Base Exchange

   Note that the DNS does not currently store the HI->IP mapping
   directly.  Instead, a DNS lookup on without Rendezvous Server

   Figure 2 shows a domain name returns both its
   FQDN->HI and FQDN->IP entries.  The simple HIP stack then implicitly
   constructs Base Exchange (without Rendezvous Server)
   in which the HI->IP mapping based on initiator initiates the HI and IP information
   returned by the DNS lookup.  In the example in Figure 1, the FQDN(R)
   lookup in step #1 returns both HI(R) and IP(R) in step #2.  HIP
   implicitly constructs the HI(R)->IP(R) mapping based on the
   assumption that HI(R) is reachable at IP(R).

   One disadvantage of this approach is that a node's domain name is
   required to obtain both its Host Identities and its IP addresses.
   Even if a HIP node already knows the Host Identity of a HIP peer
   through other means, it cannot currently obtain the peer's IP
   addresses through exchange directly with the DNS.  The DNS does not maintain an explicit
   HI->IP table, but instead indexes Host Identities only
   responder by domain
   names.

   A reverse HI->FQDN DNS mapping could address this limitation.  HIP
   nodes would then look up a HIP peer's domain name through its Host
   Identity.  They would then use the returned domain name sending an I1 packet to find the
   peer's responder IP addresses in a second lookup.  However, the DNS may not be
   structurally suited to maintain the reverse HIP->FQDN mapping.  As
   the main Internet-wide database, the DNS is already being overloaded
   with functionality that might be better handled with new mechanisms
   [13].  Finally, the additional reverse lookup would increase the
   latency of address, as per
   the HIP Base Exchange.

4.  Communication Between Mobile or Multi-Homed HIP Nodes

   HIP decouples domain names from IP addresses.  Because transport
   protocols bind to Host Identities, they remain unaware if the set of
   IP addresses associated with a Host Identity changes.  This change
   can have various reasons, including, but not limited to, mobility and
   multi-homing. base specification [4].

   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.

   In addition

   However, such a HIP node might also want to notifying its current be still reachable by
   potential future correspondent peers about changes in unaware of its IP
   addresses, location change.
   The HIP architecture [1] introduces Rendezvous Servers at which a HIP
   node must also update register its HI->IP mapping in response
   to current HIT and IP address changes.  Otherwise, addresses.  The RVS basically
   relays HIP Base Exchanges from new peers
   could fail because they try packet incoming at this HIT to contact the node at an IP address.  Thus,
   a peer publishing its RVS IP address it instead of its own is no longer reachable at.

4.1  Mobility and Multi-Homing with DNS Updates

   If the DNS indirectly maintains the HI->IP mapping in a FQDN->IP
   table, nodes can dynamically update their DNS entry in a secure
   fashion [7][8].  The DNS server maintaining the information will then
   sign and distribute the updated zone.

              #2 FQDN(R)     +----------+
       +-------------------->|   DNS    |
       | +-------------------|          |<------+
       | |  #3 HI(R), IP(R)  | FQDN->HI |       | #1 Update
       | |                   | FQDN->IP |       |    FQDN(R)->IP(R)
       | |                   +----------+
   by means of rendezvous at its RVS IP address.

               +-----+
      +--I1--->| RVS |---I1--+
      |    whenever IP(R)        +-----+       | V
      |    changes.                      v
   +-----+       #4 HIP Base Exchange                +-----+
   |     |-------------------------------->|     |<------R1-------|     |
   |  I  |<--------------------------------|  |-------I2------>|  R  |
   |     |-------------------------------->|     |
     |     |<--------------------------------|     |<------R2-------|     |
   +-----+                +-----+

           Figure 2: HIP Lookup and Base Exchange with DNS Updates Rendezvous Server

   Figure 2 shows an example of this scenario.  In step #1, a HIP Base Exchange involving a Rendezvous Server RVS.
   It is assumed that HIP node R registers
   its FQDN(R)->IP(R) entry in precedently used the DNS.  It will dynamically update HIP registration
   protocol [2] to register with the
   DNS entry whenever RVS its HIT and IP addresses IP(R) change.  Because address.  When
   the DNS
   always contains R's current IP addresses, node initiator I can perform a HIP
   Base Exchange tries to establish contact with R at its new the responder, it
   does not need to know the current IP address (steps #2-4).

   One drawback of using dynamic DNS updates in this way R.  Instead, I is the cost
   aware of
   updating secure zones.  Re-signing an entire zone whenever the RVS IP
   addresses address of one entry change places a high cost on R, at which it sends an I1 packet.
   The RVS, noticing that the DNS server.
   Using dynamic DNS to update HI->IP mappings may thus receiver HIT is not be
   appropriate when changes of IP addresses are frequent.

   A simple, operational change could help limit its own, but the costs of frequent
   DNS updates.  Instead HIT
   of recomputing a zone after each dynamic
   update, a DNS server could aggregate the modifications and only
   perform zone updates periodically.  The disadvantage of this approach
   is that HIP nodes may be unreachable until the DNS server distributes
   the updated zone.

   Another concern with using the DNS to support HIP node mobility is registered for the propagation time of updated DNS entries.  DNS servers frequently
   cache DNS responses to reduce rendezvous Service, would relay the load on
   I1 to the primary servers.
   During responder IP address.  Typically the time-to-live associated with a DNS response, DNS servers
   may answer additional requests for responder would then
   complete the same DNS entry exchange without further assistance from their
   local caches instead of contacting the primary servers.  Thus, even
   after a HIP node updates its DNS entry, RVS by
   sending an R1 directly to the DNS can still serve the
   old entry until the cached responses expire.  This can lead to
   communication problems, because peers may try to contact a HIP node
   at an initiator IP address it is no longer reachable at.

4.2  Mobility address.

3.1  Diagram Notation

   Notation     Significance
   --------     ------------

   I, R         I and Multi-Homing with Rendezvous Servers

   The HIP architecture tries to greatly reduce R are the frequency of Dynamic
   DNS updates by introducing Rendezvous Servers [2].  Instead respective source and destination IP
                addresses of
   registering its current set 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 addresses address i is
                present in its HI->IP entry the HIP header

   FROM:I               A FROM parameter containing the IP address I is present
                in the DNS, a HIP node may instead register header

   TO:I         A TO parameter containing the IP addresses of its
   Rendezvous Servers.  Because address I is present
                in the HIP header

   VIA:RVS              A VIA_RVS parameter containing IP addresses of Rendezvous Servers
   are assumed to change only infrequently, this approach can
   significantly reduce the load on DNS servers.

   Rendezvous Servers maintain a mapping between RVS
                is present in the Host Identities of HIP nodes for which they provide service and header

   EREQ         An ECHO_REQUEST parameter is present in the node's current IP
   addresses. HIP nodes must notify their Rendezvous Servers about any
   changes header

   EREP         An ECHO_REPLY parameter is present in their IP addresses.  This approach effectively relocates the HI->IP information - and HIP header

   RREQ         A REG_REQUEST parameter is present in the burden of keeping it current - from HIP header

   RRES         A REG_RESPONSE parameter is present in the DNS to HIP header

   RVR:t1,t2    A RVR_TYPE parameter with Type value t1 and t2 is present
                in the HIP header.

3.2  Rendezvous Servers.  This can reduce update costs
   under Client Registering with a Rendezvous Server

   Before the assumption that Rendezvous Servers provide more efficient
   ways of maintaining HI->IP tables.

   When Server starts to relay HIP packets to their
   receiver HIT owner (i.e.  a packet destined for Rendezvous Client or one of its HIP nodes arrives at a
   Rendezvous Server, it relays the packet to one of
   correspondent node), the HIP node's
   current IP addresses.  Due Rendezvous Client needs to the specifics of the HIP, only the
   first packet of a HIP Base Exchange will require such relaying [2].
   Subsequent packet of the HIP Base Exchange and all further data
   packets will directly flow between the HIP nodes, bypassing register with its
   Server for the Rendezvous Server.

               #3 FQDN(R)      +----------+ #2 Register IP(RVS) Service, as shown in
        +--------------------->|   DNS    |    FQDN(R)->IP(RVS). the following schema:

   +-----+                            +-----+
   | +--------------------|          |<------------------+     |            I1              |  #4 HI(R), IP(RVS)     | FQDN->HI
   |     |--------------------------->|     |
   |     |<---------------------------|     |
   | FQDN->IP RVC |    R1(REG_INFO,RVR:1,2)    | RVS |
   |                    +----------+     |      I2(REG_REQ,RVR:2)     |     |
   |     |--------------------------->|     |
   |                   #1 Update IP(R) in HI(R)->IP(R)     |<---------------------------|     |
   |     |        +--------+    whenever IP(R) changes.      R2(REG_RES,RVR:2)     |     |
   +-----+                            +-----+

3.3  Establishing HIP Associations via Rendezvous Servers

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     +->| HI->IP |--+                        +---------+                    |
    |                                                       V
   +-----+   |  +--------+  |    R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS)    +-----+
   |     |---+              +------------------------->|     |
      |  I     |<---------------------------------------------|     |    #5 First Message of HIP Base Exchange
   |  R     |                                              |     |
   |  I  |            I2(I, R, HIT-I, HIT-R)            |     |<--------------------------------------------|  R  |
   |     |-------------------------------------------->|     |--------------------------------------------->|     |
   |     |<--------------------------------------------|     |<---------------------------------------------|     |
   +-----+       #6 Remainder of HIP Base Exchange             R2(R, I, HIT-R, HIT-I)           +-----+

 Figure 3: HIP Lookup and Base Exchange with 5: I1_TUNNEL: Rendezvous Server

   Figure 3 shows Encapsulating I1 into a Tunnel

3.3.2  Rewriting I1 IP Header

   If a HIP lookup node and Base Exchange involving one of its Rendezvous Servers have a Rendezvous
   Server.  Here, HIP node R is using
   Registration of type REWRITE_I1, the Rendezvous Server RVS.  In step
   #1, it updates RVS with its current relays up to
   this node I1s incoming to this node's HIT by merely rewrite the IP addresses IP(R).  Then, in
   step #2, R registers
   header.  The destination IP address of the I1 is replaced by the Rendezvous Server's IP addresses IP(RVS) in
   its FQDN(R)->IP(RVS) DNS entry.

   In step #3,
   address of the receiver HIT owner (i.e.  the Rendezvous Client).

   However, because of egress filtering, a second HIP node I issues a DNS lookup on FQDN(R) to
   obtain R's Host Identities HI(R) and IP addresses.  The lookup
   returns R's Host Identities HI(R) in step #4.  The DNS reply Rendezvous Server might
   also
   includes need to replace the original source IP addresses address of an I1 by its
   own IP address, thus concealing the Rendezvous Server IP(RVS) (instead
   of IP(R), because R's current addresses are unknown Initiator's IP address to the DNS.)

   In step #5,
   Responder.  Hence, such a node I initiates the HIP Base Exchange.  It addresses MUST append I1 packets with a FROM
   parameter containing the
   first packet original source IP address of the HIP Base Exchange to IP(RVS).  Upon receipt, packet.
   This FROM parameter MUST be integrity protected by a RVR_HMAC keyed
   with the corresponding rendezvous registration integrity key [2].

                                             I1(I, RVS, HIT-I,
       I1(I, RVS, HIT-I, HIT-R) +---------+     HIT-R, FROM:I, VIA:RVS)
       +----------------------->|         |--------------------+
       |                        |   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 6: I1_REWRITE: Rendezvous Server relays the packet to one of R's current Rewriting I1 Source and
                        Destination IP
   addresses IP(R).  The remainder Addresses

3.3.3  Bidirectional Forwarding of the HIP Base Exchange then occurs
   directly between I and R packets

   In some cases it is useful to have a RVS which relay further HIP
   packets in step #6.

   When Rendezvous Servers maintain a bidirectional manner, i.e.  from the HI->IP information, they may
   support more efficient update operations compared initiator to dynamic DNS
   updates (Section 4.1).  Unlike the DNS, Rendezvous Servers do not
   provide a lookup service.  Instead, they use
   responder but also from the HI->IP information responder to actively relay traffic between HIP nodes.

   This approach changes the role of initiator.  These
   further packets would typically be either an R1 or an UPDATE.  A RVS
   behaves accordingly when the IP addresses stored in Rendezvous Registration Type is
   BIDIRECTIONAL.

   However, because such packets are larger than I1 (they contain a DNS
   entry.  Traditionally, nodes were directly reachable at the IP
   addresses listed in
   signature), their DNS entry.  HIP relaying create an opportunity for denial of
   service attacks.  To defend against these attacks, the Rendezvous
   Server change
   this basic property needs to differentiate between legitimate HIP packets (i.e.,
   I1 and subsequent HIP packets triggered by replacing an I1) and illegitimate
   ones.

   For the IP addresses sake of their client
   nodes in reducing the DNS with their own.  The IP addresses in a DNS entry
   hence no longer directly designate interfaces of an endpoint.
   Instead, they identify interfaces of a node that can relay packets to load incurred on the endpoint.

5.  HIP Extensions for Rendezvous Servers

   The following sections describe HIP extensions for communication with
   Rendezvous Servers.  These extensions allow:

   o  A HIP Rendezvous Server to advertise its RVS, an RVS capabilities to its
      correspondents.

   o  A HIP node to create a Rendezvous Association (RVA) with its
      Rendezvous Server, i.e., is not
   required to register its current set keep track of IP
      address(es).

   o  Two HIP nodes to establish a addresses and other pieces of state
   associated with ongoing HIP Association (HA) between them via
      one or more Rendezvous Server.

5.1  Additional RVS_CAPABLE Control Field

   RVS mechanisms exchanges.  Such behavior is OPTIONAL.
   Instead, the relaying facility SHOULD make use of ECHO_REQUEST and
   ECHO_RESPONSE parameters.

   Each time a new Control Fields in the HIP Control
   Field: packet is being relayed and will possibly trigger an
   answer, the RVS_CAPABLE Control Field. RVS MUST augment it with an ECHO_REQUEST parameter
   containing a chunk of opaque data.  The RVS_CAPABLE Control Field ("R") allows receiver of such a Rendezvous Server to
   advertise its rendezvous capabilities packet
   MUST augment any packet answering to the HIP nodes it associates
   with.

5.2  Additional HIP Parameters

5.2.1  RVA_REQUEST Parameter Format this packet with an ECHO_REPLY
   parameter containing the same chunk of opaque data.  This opaque data
   allows an RVS to find and Processing
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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,  |             Type   RVS   |             Length R1(R, RVS, HIT-R,   ||
    ||    HIT-I, REA:R,   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         |                             Lifetime    HIT-I, REA:R,    ||
    ||    VIA:RVS)        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         |           RVA Type #1    TO:I, EREP)      ||
    ||                    |           RVA Type #2         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                     ||
    ||                    +---------+                     ||
    |V                                                    |V
   +-----+             I2(R, I, HIT-R, HIT-I)          +-----+
   |           RVA Type #n     |-------------------------------------------->|     |             padding
   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type		100
   Length	Length in octets, excluding Type, Length and Padding
   Lifetime	This field encode,  I  |<--------------------------------------------|  R  |
   |     |             R2(I, R, HIT-I, HIT-R)          |     |
   +-----+                                             +-----+

  Figure 7: BIDIRECTIONAL: Responder replying via the desired RVA validity time.
   RVA Type	This field encode, in order of preference, RVS to Initiator

3.3.4  Implication on the
   		preferred rendezvous service types. HIP integrity checks

   The following RVA Types are defined:

   Type number	RVA Type
   -----------	--------
   0		Reserved by IANA
   1		I1_REWRITE_DST
   2		I1_REWRITE_SRCDST
   3		I1R1_REWRITE_SRCDST
   4		I1_RELAY_ESP
   5		I1R1_RELAY_ESP
   6		REDIRECT
   6-200	Reserved by IANA
   201-255	Reserved by IANA for private use

   When a Rendezvous Association establishment of type I1_* is established between a HIP RVS and its peer, associations via one or more Rendezvous
   Servers causes HIP packets flowing between the RVS will relay HIP nodes to be
   modified during transmission.  Several kinds of modifications to both
   the peer all inbound I1s
   whose Responder HIT match those of the peer. IP and HIP headers are possible.  The peer will then
   reply with a R1 sent directly to the Initiator, without further
   assistance from the RVS.

   When a Rendezvous Association HIP protocol uses two kinds
   of type I1R1_* packet integrity checks: hop-by-hop and end-to-end.  The HIP
   checksum is established between a
   HIP RVS hop-by-hop check and its peer, the RVS will relay to the peer all inbound I1s
   whose Responder HIT match those SHOULD be verified and recomputed
   by each of the peer. on-path HIP middle-boxes (e.g., Rendezvous Servers).
   The peer will then
   reply with a R1 sent to HMAC and SIGNATURE are end-to-end checks and MUST be computed by
   the Initiator via sender and verified by the RVS, which will relay
   it receiver.

3.3.4.1  Checksum

   The checksum field of a HIP header to be modified MUST be verified
   before applying the Initiator. modification and recomputed accordingly after.

3.3.4.2  HMAC and SIGNATURE

   The Initiator will then reply directly to HMAC and SIGNATURE field of a HIP header MUST be computed and
   verified based on a "sender view" or "receiver view" of the
   Responder HIP
   header.  In particular, this implies that SIGNATURE and HMAC MUST NOT
   cover FROM and TO parameters added or removed by sending an I2, without further assistance from Rendezvous Servers
   and that the RVS.

   A RVS relays packet by either rewriting IP addresses in HIP pseudo-header used to compute and verify them MUST
   contain the IP
   header, or alternatively, if a HIP association is present, addresses as seen by
   forwarding it into the ESP SA associated with the remote HIP Association.

   If the RVA is peer.  In case of type *_REWRITE_*, the
   IP addresses are rewritten address concealment by the RVS.  If RVS, this means that the RVA type is I1_REWRITE_DST, only IP address of
   this RVS MUST be used in the pseudo-header in place of the destination IP address
   of a relayed I1 the end host it conceals.

3.3.4.3  Example

   Here is rewritten.  On an example showing how to compute the contrary, if different integrity
   checks (end-to-end and hop-by-hop) when two Rendezvous Servers are
   cascaded and conceals the RVA
   type *_REWRITE_SRCDST, both Responder IP address (packet flowing along
   the source 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 addresses
   are rewritten.  In address, the case of a *_REWRITE_SRCDST, rationale being that RVS1 is concealing the RVS Responder
   IP address.  Therefore, R will need
   to suffix verify the HIP header with a FROM parameter preserving signature using RVS1 as the
   original source
   destination IP address of in the relayed packet.  This FROM, as well
   as 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 whole Rendezvous Service and maintain
      the RVS aware of its current location.

   o  The HIP header, is integrity protected 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 RVA_HMAC ECHO_REQUEST
   parameter which contains a keyed-HMAC computed over the HIP packet,
   similarly to what the HMAC carrying packet.  The contents of the ECHO_REQUEST
   MUST then be echoed back in ECHO_RESPONSE.

   A TO parameter already does.

5.2.2  RVA_REPLY Parameter Format MUST be augmented and Processing

      0 authenticated by including an
   ECHO_REPLY parameter to the carrying packet.  The contents of the
   ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE.

   All the HIP packets requiring RVS relaying facility to carry an
   answer packet MUST be augmented by the RVS with an ECHO_REQUEST
   parameter.

   A possible packet answered via the RVS, thus requiring relaying
   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
   located after the signatures, it MUST remove it from the packet and
   recompute packet length and checksum accordingly.

4.1.2  REA Parameter

   A HIP node associated via an RVS MAY use a REA parameter to make its
   correspondent aware of its veritable current IP address.  If used,
   the REA parameter MUST be used in conformance with the guidelines
   specified in [5].

4.2  New Registration Type

   This specification defines an additional Registration Type to use
   within the HIP Registration protocol [2] while registering with a
   Rendezvous Server for the Rendezvous Service.

   Number Registration Type
   ------ -----------------
   1      RENDEZVOUS

4.3  New Parameter Formats and Processing

4.3.1  RVR_TYPE 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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                             Lifetime                          |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |           RVA  RVR Type #1  |           RVA  RVR Type #2  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |           RVA Type #n
     +-+-+-+-+-+-+-+-+---------------+        Padding                |
     |             padding                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type		102
   Length	Length in octets, excluding Type,         [ TBD by IANA {110) ]
   Length and Padding
   Lifetime	This field encode the offered RVA validity time
   RVA       8
   RVR Type	This field encode, in order of preference, An 8 bit number indicating the
   		preferred rendezvous service types (the same specific type values than RVA_REQUEST parameter are used).

5.2.3  RVA_HMAC Parameter Format and Processing

   The RVA_HMAC is an OPTIONAL parameter whose only difference with the
   HMAC parameter defined in [4] is of the
   Rendezvous Server/Service.

      Number RVR Type code:

   Type		65320       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
   HMAC parameter defined in [4] is the Type code, making it situated
   after the TO and FROM parameters (as opposed to HMAC):

   Type         [ TBD by IANA {65320) ]
   Length       20
   HMAC         160 low order bits of a HMAC keyed with the appropriate
                HIP integrity keys (HIP_lg or HIP_gl) of the corresponding
   		Rendezvous Association or
                HIP Association. This HMAC is computed over the HIP packet
                excluding RVA_HMAC RVR_HMAC and any other following parameter.
                The checksum field MUST be set to zero and the HIP header
                length in the HIP common header MUST be calculated not to
                cover any excluded parameter when the Authenticator field
                is calculated.

   To allow a HIP node Rendezvous Client and any of its RVS to verify the integrity of
   packets flowing between them, both use an RVA_HMAC RVR_HMAC parameter keyed
   with a HMAC of HIP_lg and HIP_gl integrity keys.  One RVA_HMAC RVR_HMAC SHOULD
   be present on every packets flowing between a HIP node client and any of its
   RVS a server and
   MUST be present when FROM and TO parameters are processed.

   On the receiving side, when an RVA_HMAC RVR_HMAC is validated, it SHOULD be
   removed from the packet and if so, packet length and checksum MUST be
   recomputed accordingly.

5.2.4

4.3.3  FROM Parameter Format and Processing

      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		65100 (under signature) or 65300 (after signature)
   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 (I1, R1, I2 or R2) 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 additional parameters that will be used to validate this
   and the subsequent HIP packets.  These parameters are:

   o  An ECHO_REQUEST, containing a chunk of opaque data allowing to
      validate, in a possible subsequent answer, a TO parameter which
      MUST be protected by an ECHO_RESPONSE containing the same opaque
      data.

   o  A valid RVA_HMAC, protecting the packet integrity.

   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
   parameter containing the IP address included in the FROM.  These
   replies will be sent via the RVS, which MUST remove the outer TO
   parameter from the packet and replace its destination address with
   the address contained in the TO parameter before relaying it.

5.2.5  TO Parameter Format and Processing

      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		65102 (under signature) or 65302 (after signature)
   Length	16
   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 (I1, R1, I2 or R2) 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 RVA_HMAC, protecting the packet integrity.

   When the RVS validates a TO parameter, SHALL remove it from the
   packet, and SHALL replace the packet destination IP address  with the
   address included in the TO parameter.  Packet length and checksum
   MUST then be recomputed accordingly.

   For each FROM parameter, a HIP node MAY add to its replies a TO
   parameter containing the IP address included in the FROM.  These
   replies will be sent via the RVS, which MUST remove the outer TO
   parameter from the packet and replace its destination address field
   with the address contained in the TO parameter before relaying it.

5.2.6  VIA_RVS Parameter Format and Processing

      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                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                               .                               .
     .                               .                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type           65500
   Length         Variable
   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
   HIP packets directly towards the remote HIP endpoint's IP address,
   without further assistance from one or more of its RVS(s).  In that
   case, it MAY include in these packets a subset of the IP address(es)
   of its RVSs for debugging purposes.

   Similarly, a RVS relaying an I1 to the Responder or an R1 to the
   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
   either an end-node or the RVS itself, one of these two methods is
   used:

   o  Add RVS IP address into an existing VIA_RVS parameter situated at
      the end of the HIP packet, while modifying accordingly the size of
      the parameter.

   o  Append a newly created VIA_RVS parameter at the end of the HIP
      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
   operators to diagnose possible issues encountered while establishing
   a HIP association via a RVS.

5.3  Use of Existing HIP Messages and Parameters

5.3.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
   might then be echoed back in ECHO_RESPONSE.

   A TO parameter SHOULD be augmented and authenticated by including an
   ECHO_REPLY parameter to the carrying packet.  The contents of the
   ECHO_REPLY MUST be copied from a previously received ECHO_RESPONSE.

   All the HIP packets requiring RVS relaying facility to carry an
   answer packet SHOULD be augmented by the RVS with an ECHO_REQUEST
   parameter.

   A possible packet answered via the RVS, thus requiring relaying
   facility, SHOULD 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
   located after the signatures, it MUST remove it from the packet and
   recompute packet length and checksum accordingly.

5.3.2  REA Parameter

   A HIP node associated via an RVS MAY use a REA parameter to make its
   correspondent aware of its veritable current IP address.  If used,
   the REA parameter MUST be used in conformance with the guidelines
   specified in [5].

6.  Diagram Notation

   Notation	Significance
   --------	------------

   I, R		I and R are the respective source and destination IP
   		addresses of the IP header

   HIT-I,	HIT-I and HIT-R are respectively the Initiator and the
   HIT-R	Responder HIT of the packet

   R		The RVS_CAPABLE Control Field is set into the Control
   		Field of the HIP header

   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
   		is present in the HIP header

   REDIR:R		A REDIRECT parameter containing IP address R of
   		Responder is present in the HIP header

   EREQ		An ECHO_REQUEST parameter is present in the HIP header

   EREP		An ECHO_REPLY parameter is present in the HIP header

   RREQ		A RVA_REQUEST parameter is present in the HIP header

   RREP		A RVA_REPLY parameter is present in the HIP header

7.  Establishing Rendezvous Associations

   A HIP node that wants to register its IP address with its RVS MAY
   simply establish a HIP association with it.  It MUST then keep its IP
   address current with the server by sending UPDATE packets whenever
   its set of IP addresses changes.

   However, for the sake of economizing RVS resources, which can
   possibly be used by several thousands of different HIP nodes, we
   define a new sort of "soft state" HIP association called a Rendezvous
   Association (RVA).  In order to maintain this RVA established, a HIP
   Association need not remain established.

   A HIP node MAY establish an RVA with its RVS by establishing a HA
   while adding an RVA_REQUEST parameter in an I2, possibly preceded by
   an I1 containing the same RVA_REQUEST.  The possibility offered to
   initiate the protocol in I1 allows a HIP node to query a RVS for the
   set of offered rendezvous service types before completing the
   establishment of the Rendezvous association (in case the desired
   service type isn't available on this RVS).  A RVS MUST then reply
   with, respectively, an R2 possibly preceded by an R1, which will both
   have the RVS_CAPABLE control field set, and contain a RVA_REPLY
   parameter specifying the characteristics of the offered RVA (validity
   time, type, etc.).  Then, the RVS and the HIP node MAY delete most of
   the HIP Association state, retaining only the Lifetime, Initiator's
   HIT and IP address(es), as well as HIP_lg and HIP_gl integrity keys.

   When a HA is established via an RVS, the integrity of HIP packets
   flowing between a HIP node and its RVS is protected by an additional
   RVA_HMAC keyed with these keys.

                      I1(I, RVS, HIT-I,
                         HIT-RVS)           +------+
                +-------------------------->|      |
                |+--------------------------|      |
                ||    R1(RVS, I, HIT-RVS,   |      |
                ||       HIT-I, R)          |      |
                ||                          | RVS1 |
                ||     I2(I, RVS, HIT-I,    |      |
                ||        HIT-RVS, RREQ)    |      |
                || +----------------------->|      |
                || |+-----------------------|      |
                || ||  R2(RVS, I, HIT-RVS,  +------+
                || ||     HIT-I, R, RREP)
                |V |V
               +-----+
               |     |
               |  I  |
               |     |
               +-----+

            Figure 12: Establishing a Rendezvous Association

   There is nothing to prevent an RVS node to advertise its RVS
   capabilities to the peers it associates with, nor to establish an RVA
   with another RVS.

   If a HIP node wants to associate with several cascaded Rendezvous
   Servers RVS_i (0 < i < n+1), it SHALL sequentially create RVAs
   (RVA_i) with each of them, starting from the "nearest" (RVS_1) to the
   "farthest" (RVS_n).  Apart from RVA_1, a node SHOULD create any such
   RVA_i (1 < i < n+1) by sending an I1 to RVS_i via each of the RVS
   which precede it, i.e., RVS_j (1 < j < i).

   This is achieved by using (i - 1) different TO parameters containing,
   in order, the IP address of each RVS preceding RVS_i, i.e., RVS_j (1
   < j < i).  This process is similar to IP loose source-routing.
   Hence, A RVS accepting to be part of a cascade MAY relay an incoming
   I1 from one its clients to any given address and HIT.  Those I1s MUST
   be protected by a valid RVA_HMAC parameter.

         I1(I, RVS1, HIT-I,                  I1(RVS1, RVS2, HIT-I,
         HIT-RVS2, TO:RVS2)      +------+       HIT-RVS2, EREQ1)
     +-------------------------->|      |----------------------------+
     |+--------------------------|      |<--------------------------+|
     || R1(RVS1, I, HIT-RVS2,    |      |   R1(RVS2, RVS1,          ||
     ||    HIT-I, R, EREQ1)      |      |      HIT-RVS2, HIT-I,     ||
     ||                          | RVS1 |      R, EREP1)            ||
     ||   I2(I, RVS1, HIT-I,     |      |                           ||
     ||      HIT-RVS2, RREQ,     |      | I2(RVS1, RVS2, HIT-I,     ||
     ||      EREP1, TO:RVS2)     |      |    HIT-RVS2, RREQ, EREQ1) ||
     || +----------------------->|      |------------------------+  ||
     || |+-----------------------|      |<----------------------+|  ||
     || || R2(RVS1, I, HIT-RVS2, +------+  R2(RVS2, RVS1,       ||  ||
     || ||    HIT-I, R, RREP,                 HIT-RVS2, HIT-I,  ||  ||
     || ||    EREQ1)                          R, RREP, EREP1)   ||  ||
     |V |V                                                      |V  |V
    +-----+                                                    +------+
    |     |                                                    |      |
    |  I  |                                                    | RVS2 |
    |     |                                                    |      |
    +-----+                                                    +------+

        Figure 13: Establishing Cascaded Rendezvous Associations

8.  Establishing HIP Associations via Rendezvous Servers

8.1  Sending a Redirect in Reply to I1

   Instead of having the RVS relay incoming I1s to the correct
   Responder, one possibility is to answer with a REDIRECT packet when a
   HIP packet destined for one of the Rendezvous Server's HIP nodes
   arrives.  This REDIRECT packet would contains the IP address and
   packet signature of the Responder.

   The Responder cannot sign the redirect packets delivered by the RVS
   in real time.  When the RVA is set up, the Responder sends the signed
   REDIRECT packet to the RVS, who stores it until the RVA expires.

   By signing this REDIRECT packet and sending it to the RVS, the
   Responder is authorizing the Rendezvous Server's IP address to
   redirect Initiators to the Responder's IP address.  The authorization
   is weak because the subject of the authorization is the IP address
   which is not bound to the HI of the Responder (similarly to what is
   described in , the possibility to use CGAs as IP addresses for RVSs
   might improve authorization security because the RVS might then prove
   to Initiators ownership of the CGA IP address, and the authorization
   issued to it to redirect to the Responder's IP address.

   An implementation of this redirect packet is a R1 packet signed by
   the Responder, which contains an additional REDIRECT parameter (with
   the IP address of the Responder, and perhaps a limitation of the
   REDIRECT validity, like 'not-before' and 'not-after' dates, or hash
   chains) The RVS redirect an Initiator by replying to an I1 with this
   REDIRECT R1 in which the receiver HIT field has been field with the
   HIT of the Initiator.  Note that this may expose the Initiator to
   replay attacks, but this is not very different from the situation
   where the Initiator receives a signed R1 whose signature also omits
   Receiver HIT.

                                           _____OFFLINE______
                                           R1(R, RVS, HIT-R
    I1(I, RVS, HIT-I, HIT-R) +---------+      HIT-0, REDIR:R)
    +------------------------|         |
    |                        |   RVS   |<-+-+-+-+-+-+-+-+-+-+
    |  +---------------------|         |                    |
    |  | R1(RVS, I, HIT-R,   +---------+                    +
    |  V    HIT-I, REDIR:RVS->R)                            |
   +-----+            I1(I, R, HIT-I, HIT-R)            +-----+
   |     |--------------------------------------------->|     |
   |     |<---------------------------------------------|     |
   |  I  |            R1(R, I, HIT-R, HIT-I)            |  R  |
   |     |            I2(I, R, HIT-I, HIT-R)            |     |
   |     |--------------------------------------------->|     |
   |     |<---------------------------------------------|     |
   +-----+            R2(R, I, HIT-R, HIT-I)            +-----+

      Figure 14: Initiator redirected by Rendezvous Server with a
                          Responder-signed R1

8.2  Passing I1 onto an ESP SA

   If a HIP node and one of its Rendezvous Servers maintain a HIP
   Association, the Rendezvous Server MAY tunnel I1s incoming to this
   node's HIT into the corresponding ESP SA.  The main drawbacks of this
   approach are that, (1) middle-boxes cannot see the encrypted I1
   passing from an RVS to its clients, and (2) the source IP address of
   I1 is lost.  In particular, (2) implies that the RVS MUST transmit to
   the Responder the original source IP address by either of the
   following:

   o  add a FROM parameter to the HIP header

   o  include the whole original IP header in the ESP payload (very
      similar to ESP tunnel mode)
   o  route back the subsequent R1 via the RVS

                                       ESP(RVS, R,
                                           I1(I, RVS, HIT-I,
    I1(I, RVS, HIT-I, HIT-R) +---------+      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 15: Rendezvous Server Forwarding I1 onto an ESP SA

8.3  Rewriting I1 Destination IP Address

   When a HIP packet destined for one of its HIP nodes arrives at a
   Rendezvous Server, it relays the packet to one of the HIP node's
   current IP addresses.  In most case, it is expected that only the
   first packet of a HIP Base Exchange (i.e., I1) will require such
   relaying [2].  Subsequent packet of the HIP Base Exchange and all
   further data packets will directly flow between the HIP nodes,
   bypassing the Rendezvous Server.  The RVA established between such a
   RVS and its peer has type I1_REWRITE_DST.

   In the simplest case, the Rendezvous Server can relay an I1 towards
   its true destination by merely replacing the destination IP address
   of the I1 by one of the destination HIT owner's IP address(es).
   Note, however, that such I1s might be subject to egress filtering on
   the Rendezvous Server's network [9], thus causing I1 packet to be
   dropped (source IP address does not belong to the RVS network).

                                         I1(I, R, HIT-I,
    I1(I, RVS, HIT-I, HIT-R) +---------+    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 16: Rendezvous Server Rewriting I1 Destination IP Address

8.4  Rewriting I1 Source and Destination IP Addresses

   Because of egress filtering, a HIP Rendezvous Server might need to
   replace the original source IP address of an I1 by its own IP
   address, thus concealing the Initiator's IP address to the Responder.

   While this might be desirable, one of the extension described in this
   document allows a Rendezvous Server to piggy-back incoming HIP
   packets with an OPTIONAL FROM parameter containing the original
   source IP address of the packet.  A HIP node receiving a packet
   containing such a FROM parameter has two possibilities for answering
   back.  It might answer an R1 back either:

   o  Directly to the IP address included in the FROM parameter.  The
      RVA established between such a RVS and its peer has type
      I1_REWRITE_SRCDST.

   o  Via the Rendezvous Server IP address, adding to the R1 HIP header
      a TO parameter containing the IP address included in the FROM
      parameter.  The RVA established between such a RVS and its peer
      has type I1R1_REWRITE_SRCDST.

                                             I1(I, RVS, HIT-I,
       I1(I, RVS, HIT-I, HIT-R) +---------+     HIT-R, FROM:I, VIA:RVS)
       +----------------------->|         |--------------------+
       |                        |   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 17: I1_REWRITE_SRCDST: Rendezvous Server Rewriting I1 Source
                      and Destination IP Addresses

8.5  Rewriting I1 and R1 Source and Destination IP Addresses

   It might be useful to relay further HIP packets (i.e., R1) via the
   RVS.  For example, if the Initiator does not know the Responder's
   HIT, it will initiate an opportunistic exchange with the Responder
   via a RVS.  The first problem  is for the RVS to forward an I1 which
   doesn't have a destination HIT to the correct Responder.

   Because an opportunistic Initiator uses the unspecified IPv6 address
   (i.e., ::0) as a place-holder for the Responder HIT in I1s it sends,
   an RVS cannot use this Responder HIT to demultiplex incoming
   "opportunistic" I1s.  The only way to properly relay such
   Opportunistic I1s is for the RVS to lease per-HIT IP addresses, so
   the destination IP addresses of Opportunistic I1s can be used as a
   key to find the correct Responder.

   In order to avoid trivial spoofing attacks with R1s, a HIP node
   receiving an opportunistic I1 from a Rendezvous Server MUST reply
   with its R1 via the same Rendezvous Server.  Accordingly, an
   Initiator who has attempted an opportunistic exchange towards an IP
   address (those of the RVS) MUST discards all R1s received in answers
   which do not come from the same IP address.  When sending the R1 via
   the RVS, the Responder MUST initiate the readdressing protocol as
   described in [5].

   This restriction is made for security reasons.  If the Initiator
   receives an R1 directly from the Responder, the only way to find the
   appropriate HIP state is to use as a key the RVS's IP address, which
   is possibly included in
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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 VIA_RVS parameter.  This solution MUST be
   avoided because the VIA_RVS FROM parameter is not trusted (The Initiator
   doesn't have a priori knowledge of the public key, and the included
   RVS IP address hasn't been "validated" by having the routing fabric
   delivers containing the original
   source IP header with this address as source).  If this
   restriction is not made, a passive attacker might easily hijack a HIP
   state in I1_SENT state: it would learn a (source,destination) tuple of IP addresses in a flowing I1, then send to the HIP packet whose source IP address a
   self-made R1 with a VIA_RVS parameter containing the destination
   address; that's it, has been
   rewritten.  If one or more FROM parameters are already present, the attacker hijacked
   new FROM parameter MUST be appended after the I1_SENT state.  This existing ones.

   Each time an
   opportunity for eavesdropping, MitM, as well as DoS attacks.

   Because these R1 packets are larger than I1 (they contain public keys
   and signatures), RVS inserts a FROM parameter, it MUST also insert an
   RVR_HMAC protecting the relaying of such packet create an opportunity
   for denial of service attacks.  To defend against these attacks, integrity that the Rendezvous Server needs Client
   will use to differentiate between legitimate HIP
   packets (i.e., I1 and subsequent HIP packets triggered by an I1) and
   illegitimate ones.

   For validate this packet.

   If the sake type of reducing the load incurred on RVR allows the RVS, an RVS is not
   required Rendezvous Client to answer to keep track of IP addresses and other pieces of state
   associated with ongoing HIP exchanges.  Such behavior is OPTIONAL.
   Instead, the relaying facility MAY make use of ECHO_REQUEST and
   ECHO_RESPONSE parameters.

   Each time a
   relayed packet is being relayed, via the RVS MAY augment it RVS, an ECHO_REQUEST MUST be included along
   with an
   ECHO_REQUEST parameter containing the FROM parameter.  It contains a chunk of opaque data.  The
   receiver of such a packet SHOULD augment any packet answering data allowing
   to this
   packet with validate TO parameters included in a subsequent answer.  These TO
   parameters MUST be protected by an ECHO_REPLY parameter ECHO_RESPONSE containing the same chunk of
   opaque data.  This opaque data allows an RVS to find and validate

   When a HIP node validates a FROM parameter, it is removed from the
   answered
   packet IP addresses and HITs.  When successfully validated,
   ECHO_REPLY parameters SHOULD recorded for later use (i.e., for building the
   corresponding TO parameter to be removed 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
   parameter containing the IP address included in the FROM.  These
   replies will be sent via the RVS, which MUST remove the outer TO
   parameter from the packet and replace its destination address with
   the address contained in the TO parameter 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)          +-----+
   |     |-------------------------------------------->|     |
   |     |<--------------------------------------------|     |
   |     |             R2(I, R, HIT-I, HIT-R)          |     |
   |  I relaying it.

4.3.4  TO 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              |  R             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |              ESP(R, I, SPI-R)
     |                             Address                           |
     |     |<--------------------------------------------|                                                               |
     |     |-------------------------------------------->|                                                               |
   +-----+              ESP(I, R, SPI-I)               +-----+

  Figure 18: I1R1_REWRITE_SRCDST: Responder replying via
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type         [ TBD by IANA {65102 under signature, 65302 after) ]
   Length               16
   Address              An IPv6 address or an IPv4-in-IPv6 format IPv4 address

   A HIP node MAY add one or more TO parameter containing the RVS final
   destination IP address of a HIP packet whose destination IP address
   needs to an
                        Opportunistic Initiator

8.6  Cascading Rendezvous Servers

   In some situations, it might be useful to use cascaded Rendezvous
   Servers rewritten by an RVS.  This is essentially equivalent to establish RVS associations.  A typical scenario would
   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
   small number of "trusted" Rendezvous Servers and node inserts a larger number of
   "untrusted" Rendezvous Servers.  Only the trusted Rendezvous Servers
   are aware of TO parameter, it MUST also insert
   additional parameters that will be used by the IP addresses RVS for validation.
   These parameters are:

   o  An ECHO_RESPONSE, containing a chunk of opaque data allowing the Responders.  The untrusted
   servers know only
      RVS to validate the IP addresses of other (un)trusted Rendezvous
   Servers.  Untrusted Rendezvous Servers are changed periodically, address contained in
   order to lower the opportunity for flooding-type attacks on their IP
   addresses.

   In TO parameter.

   o  A valid RVR_HMAC, protecting the case of cascaded Rendezvous Servers, packet integrity.

   When the parameters added to RVS validates a TO parameter, SHALL remove it from the HIP base exchange, like FROM, TO, VIA_RVS, ECHO_REQUEST/REPLY or
   RVA_HMAC,
   packet, and SHALL replace the packet destination IP address with the
   address included in the TO parameter.  Packet length and checksum
   MUST then be "aggregated" or "clustered" on a per-type basis.
   This means that, when an RVS needs to add onto recomputed accordingly.

   For each FROM parameter, a HIP packet node MAY add to its replies a TO
   parameter which is already present containing the IP address included in it, this parameter MUST be
   added just after the existing parameter(s) of FROM.  These
   replies will be sent via the same type.  For
   instance, a FROM parameter RVS, which MUST be added just after remove the existing
   FROM(s) parameter(s).  The same applies to  TO, VIA_RVS,
   ECHO_REQUEST/REPLY or RVA_HMAC.

   Another solution to cascaded Rendezvous Servers may be to encapsulate outer TO
   parameter from the original packet into a PAYLOAD and then piggy-back it replace its destination address field
   with
   additional parameters.  This scheme has not been evaluated further.

                                                 I1(RVS2, R, HIT-I,
     I1(I, RVS,         I1(RVS1, RVS2,              HIT-R, EREQ1,
        HIT-I,             HIT-I, HIT-R,            EREQ2, FROM:I,
        HIT-R) +------+    EREQ1, FROM:I)  +------+ FROM:RVS1)
    +--------->|      |------------------->|      |---------+
    |          | RVS1 |                    | RVS2 |         |
    | +--------|      |<-------------------|      |<------+ |
    | |        +------+  R1(RVS2, RVS2,    +------+       | |
    | |                     HIT-I, HIT-R,                 | |
    | |                     EREP1, EREQ2,                 | |
    | |                     TO:I)                         | |
    | | R1(RVS1, I, HIT-R,             R1(R, RVS2, HIT-R, | the address contained in the TO parameter before relaying it.

4.3.5  VIA_RVS 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            |    HIT-I, REA:R,                  HIT-I, REA:R,
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                            Address                            |    EREQ2, EREQ1)                  EREP1, EREP2,
     |                                                               |
     |                                                               |                                   TO:I, TO:RVS2)
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     .                               .                               .
     .                               .                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     | V                            Address                            | V
   +-----+    I2(I, R, HIT-I, HIT-R, EREP2, EREP1)     +-----+
     |     |-------------------------------------------->|                                                               |
     |  I  |<--------------------------------------------|  R                                                               |
   +-----+           R2(R, I, HIT-R, HIT-I)            +-----+

  Figure 19: Two Cascaded Rendezvous Servers Relaying an I1-R1 Message
                                  Pair

8.7  Implication on the HIP integrity checks

   The establishment of HIP associations via one
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type         [ TBD by IANA {65500) ]
   Length               Variable
   Address              An IPv6 address or more Rendezvous
   Servers causes HIP packets flowing between the an IPv4-in-IPv6 format IPv4 address

   At some point a, HIP nodes to endpoint might be
   modified during transmission.  Several kinds of modifications in position to both
   the IP and begin to send
   HIP headers are possible.  The packets directly towards the remote HIP protocol uses two kinds endpoint's IP address,
   without further assistance from one or more of packet integrity checks: hop-by-hop and end-to-end.  The HIP
   checksum is its RVS(s).  In that
   case, it MAY include in these packets a hop-by-hop check and SHOULD be verified and recomputed
   by each subset 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.

8.7.1  Checksum

   The checksum field IP address(es)
   of its RVSs for debugging purposes.

   Similarly, a HIP header RVS relaying an I1 to be modified MUST be verified
   before applying the modification and recomputed accordingly after.

8.7.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 Responder or removed by Rendezvous Servers
   and that the HIP pseudo-header used an R1 to compute and verify them MUST
   contain the IP addresses as seen by the remote HIP peer.  In case of
   Initiator MAY include in these packets its IP address concealment by the RVS, this means that for debugging
   as well.

   When the IP address of
   this a RVS MUST need to be used included in a packet, by
   either an end-node or the pseudo-header in place RVS itself, one of the these two methods is
   used:

   o  Add RVS IP address
   of into an existing VIA_RVS parameter situated at
      the end host it conceals.

8.7.3  Example

   Here is an example showing how to compute of the different integrity
   checks (end-to-end and hop-by-hop) when two Rendezvous Servers are
   cascaded and conceals HIP packet, while modifying accordingly the Responder IP address (packet flowing along size of
      the path I -> RVS1 -> RVS2 -> R)

   End-to-end integrity checks: HMAC and SIGNATURE are computed with a
   pseudo-header containing RVS1 as parameter.

   o  Append a place holder for newly created VIA_RVS parameter at the destination
   IP address, end of the rationale being HIP
      packet if it does not already contain a VIA_RVS parameter.

   Note that RVS1 is concealing the Responder
   IP address.  Therefore, R will verify the signature main goal of using RVS1 as the
   destination IP address in the pseudo-header.

   Hop-by-hop integrity checks: Checksum VIA_RVS parameter is computed hop-by-hop; first
   with I and RVS1, then with RVS1 and RVS2, and finally with RVS2 and
   R.

9. to allow
   operators to diagnose possible issues encountered while establishing
   a HIP association via a RVS.

5.  Security Considerations

   The security aspects of different HIP rendezvous mechanisms are
   currently being investigated.  This section describes the known
   threats introduced by these HIP extensions, and implications on the
   overall security of HIP and IP.  In particular, the following tries
   to show that the extensions described in this document do not
   introduce additional threats in the Internet infrastructure.

   It is difficult to encompass the whole scope of threats introduced by
   Rendezvous Servers because their presence have implications both at
   the IP and HIP layer.  In particular, the extensions hereby described
   might allow for redirection, amplification and reflection attacks at
   the IP layer, as well as attacks on the HIP layer itself, for example
   Man-in-the-Middle attacks against the cryptographic core-protocol
   SIGMA used by HIP.

   If an Initiator has an a priori knowledge of the Responder's HI when
   it first contacts it via the RVS, it has a means to verify the
   signatures in the HIP exchange, thus conforming to the 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
   (so called Opportunistic Initiators), it is almost impossible to
   defend the HIP exchange against MitM attacks (cannot authenticate
   public keys exchanged).  The only solution is to mitigate hijacking
   threats on the HIP state by requiring an R1 answering an
   Opportunistic I1 to come from the IP address where the I1 was
   initially sent.  That way we retain a level of security which is
   equivalent to what exists today in the Internet: By sending an IP
   packet to an IP address, and receiving an answered IP packet from
   this same IP address, I know that the routing fabric trusts my
   correspondent to be represented by this IP address.  While it is true
   that such security is weak, it is better than none, and avoids to
   introduce additional threats at the IP layer.

10.

6.  IANA Considerations

   This document updates the IANA Registry for HIP Parameters Types  by
   assigning new HIP Parameter Types values for the new HIP Parameters
   defined in Section 4.3:

   o  RVR_TYPE (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 Association
   (RVA) type.  Defined RVA types are: Registration (RVR) Types values
   defined in Section 4.3.1:

      Type number	RVA       RVR Type

      -----------       --------

      0         Reserved by IANA

      1		I1_REWRITE_DST         TUNNEL_I1

      2		I1_REWRITE_SRCDST         REWRITE_I1

      3		I1R1_REWRITE_SRCDST

      4		I1_RELAY_ESP

      5		I1R1_RELAY_ESP

      6		REDIRECT

      6-200         BIDIRECTIONAL

      3-200     Reserved by IANA

      201-255   Reserved by IANA for private use

   Adding new reservations requires IETF consensus RFC2434 [14].

11. [7].

7.  Acknowledgments

   The following people have provided thoughtful and helpful discussions
   and/or suggestions that have improved this document: Marcus Brunner,
   Tom Henderson, Miika Komu, Mika Kousa, Pekka Nikander, Simon Schuetz,
   Tim Shepard, Kristian Slavov, Martin Stiemerling, and Juergen
   Quittek.

   Part of this work is a product of the Ambient Networks project,
   partially supported by the European Commission under its Sixth
   Framework Programme.  It is provided "as is" and without any express
   or implied warranties, including, without limitation, the implied
   warranties of fitness for a particular purpose.  The views and
   conclusions contained herein are those of the authors and should not
   be interpreted as necessarily representing the official policies or
   endorsements, either expressed or implied, of the Ambient Networks
   project or the European Commission.

12.

8.  References

12.1

8.1  Normative References

   [1]   Mockapetris, P., "Domain names - concepts and facilities", STD
         13, RFC 1034, November 1987.

   [2]  Moskowitz, R. and P. Nikander, "Host Identity Protocol
        Architecture", draft-ietf-hip-arch-00 (work in progress),
         October 2004.

   [3]   Nikander, P. and J. progress),
        October 2004.

   [2]  Laganier, J., Koponen, T. and L. Eggert, "Host Identity Protocol
        (HIP)
         Domain Name System (DNS) Registration Extensions", draft-ietf-hip-rvs-00
        draft-koponen-hip-registration-00 (work in progress), October 2004. January
        2005.

   [3]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [4]  Moskowitz, R., Nikander, P. and P. Jokela, "Host Identity
        Protocol", draft-ietf-hip-base-01 (work in progress), October
        2004.

   [5]  Nikander, P., "End-Host Mobility and Multi-Homing with Host
        Identity Protocol", draft-ietf-hip-mm-00 (work in progress),
        October 2004.

   [6]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [7]   Vixie, P., Thomson, S., Rekhter, Y. and J. Bound, "Dynamic
         Updates in the Domain Name System (DNS UPDATE)", RFC 2136,
         April 1997.

   [8]   Wellington, B., "Secure Domain Name System (DNS) Dynamic
         Update", RFC 3007, November 2000.

   [9]   Killalea, T., "Recommended Internet Service Provider Security
         Services and Procedures", BCP 46, RFC 3013, November 2000.

   [10]  Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC 2827, May 2000.

12.2

8.2  Informative References

   [11]

   [6]   Saltzer, J., "On the Naming and Binding of Network
         Destinations", RFC 1498, August 1993.

   [12]  Kent, S. and R. Atkinson, "Security Architecture for the
         Internet Protocol", RFC 2401, November 1998.

   [13]  Klensin, J., "Role of the Domain Name System (DNS)", RFC 3467,
         February 2003.

   [14]

   [7]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
         Considerations Section in RFCs", BCP 26, RFC 2434, October
         1998.

   [15]  Rescorla, E.

   [8]   Nikander, P. and B. Korver, "Guidelines for Writing J. Laganier, "Host Identity Protocol (HIP)
         Domain Name System (DNS) Extensions", draft-ietf-hip-rvs-00
         (work in progress), October 2004.

   [9]   Ferguson, P. and D. Senie, "Network Ingress Filtering:
         Defeating Denial of Service Attacks which employ IP Source
         Address Spoofing", BCP 38, RFC Text on 2827, May 2000.

   [10]  Killalea, T., "Recommended Internet Service Provider Security Considerations",
         Services and Procedures", BCP 72, 46, RFC 3552, July 2003. 3013, November 2000.

Authors' Addresses

   Julien Laganier
   Sun Labs (Sun Microsystems) & LIP (CNRS/INRIA/ENSL/UCBL)
   180, Avenue de l'Europe
   Saint Ismier CEDEX  38334
   FR

   Phone: +33 476 188 815
   EMail: ju@sun.com
   URI:   http://research.sun.com/

   Lars Eggert
   NEC Network Laboratories
   Kurfuersten-Anlage 36
   Heidelberg  69115
   DE

   Phone: +49 6221 90511 43
   Fax:   +49 6221 90511 55
   EMail: lars.eggert@netlab.nec.de
   URI:   http://www.netlab.nec.de/

Appendix A.  Document Revision History

   +-----------+-------------------------------------------------------+
   | Revision  | Comments                                              |
   +-----------+-------------------------------------------------------+
   | 00        | Compared to draft-eggert-hip-rvs-00: Add              |
   |           | 'Terminology' section. Remove sections about privacy  | 01        |           | (goes into Splitted out the HIP RG RVS draft). Wrote 'Security     |
   |           | Considerations' and 'IANA Considerations' sections. registration sub-protocol. Simplify  |
   |           | Add I1/R1 typology of relaying to support Opportunistic           |
   |           | Initiators. Complete REDIRECT packet description.     |
   |           | Compared to draft-eggert-hip-rendezvous-00: Minor     |
   |           | fixes to figures and their descriptive text. Added techniques (keep only TUNNEL,    |
   |           | RVS protocol specification. Removed sections related REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
   | 00        | to communications between Initial version as a HIP and non-HIP nodes. Use  |
   |           | boilerplate from RFC 3668. WG item.                     |
   +-----------+-------------------------------------------------------+

Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Copyright Statement

   Copyright (C) The Internet Society (2004). (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.