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

           Host Identity Protocol (HIP) Rendezvous 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 August 19, 2005.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document discusses a Rendezvous extension for the Host Identity
   Protocol (HIP).  The Rendezvous extension extend HIP and the HIP
   registration extension for initiating communication between HIP nodes
   via HIP Rendezvous Servers.  Rendezvous Servers improve operation
   when HIP nodes are multi-homed or mobile.


Laganier & Eggert       Expires August 19, 2005                 [Page 1]


Internet-Draft          HIP Rendezvous Extension           February 2005

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Overview of Rendezvous Server Operation  . . . . . . . . . . .  4
     3.1   Diagram Notation . . . . . . . . . . . . . . . . . . . . .  6
     3.2   Rendezvous Client Registering with a Rendezvous Server . .  6
     3.3   Establishing HIP Associations via Rendezvous Servers . . .  7
       3.3.1   Encapsulating I1 into a Tunnel . . . . . . . . . . . .  7
       3.3.2   Rewriting I1 IP Header . . . . . . . . . . . . . . . .  7
       3.3.3   Bidirectional Forwarding of HIP packets  . . . . . . .  8
       3.3.4   Implication on the HIP integrity checks  . . . . . . .  9
   4.  RVS Extensions Definition  . . . . . . . . . . . . . . . . . . 10
     4.1   Usage and Processing of Existing Parameters  . . . . . . . 11
       4.1.1   ECHO_REQUEST and ECHO_REPLY Parameters . . . . . . . . 11
       4.1.2   REA Parameter  . . . . . . . . . . . . . . . . . . . . 11
     4.2   New Registration Type  . . . . . . . . . . . . . . . . . . 11
     4.3   New Parameter Formats and Processing . . . . . . . . . . . 11
       4.3.1   RVR_TYPE Parameter . . . . . . . . . . . . . . . . . . 12
       4.3.2   RVR_HMAC Parameter . . . . . . . . . . . . . . . . . . 13
       4.3.3   FROM Parameter . . . . . . . . . . . . . . . . . . . . 14
       4.3.4   TO Parameter . . . . . . . . . . . . . . . . . . . . . 15
       4.3.5   VIA_RVS Parameter  . . . . . . . . . . . . . . . . . . 16
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 17
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   8.1   Normative References . . . . . . . . . . . . . . . . . . . . 19
   8.2   Informative References . . . . . . . . . . . . . . . . . . . 19
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 20
   A.  Document Revision History  . . . . . . . . . . . . . . . . . . 20
       Intellectual Property and Copyright Statements . . . . . . . . 21










Laganier & Eggert       Expires August 19, 2005                 [Page 2]


Internet-Draft          HIP Rendezvous Extension           February 2005

1.  Introduction

   The current Internet has a dual use of IP addresses.  First, they are
   topological locators for network attachment points.  Second, they act
   as names for the attached network interfaces.  Saltzer [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 [1] defines a new third
   namespace.  The Host Identity namespace decouples the name and
   locator roles currently filled by IP addresses.  Transport-layer
   mechanisms operate on Host Identities instead of using IP addresses
   as endpoint names.  Network-layer mechanisms continue to use IP
   addresses as pure locators.  Because of this decoupling the HIP layer
   needs to map Host Identities into IP addresses.

   Without HIP, a node needs to know its peer IP address to make an
   initial contact.  The Host Identity Protocol architecture [1]
   introduces an additional piece of infrastructure, the Rendezvous
   Server (RVS), which serves as an initial contact point (rendezvous)
   for nodes trying to reach the RVS clients.  A RVS offers to a peer it
   serves to relay to its IP address the first packet of a HIP exchange
   incoming at the RVS IP address and with the 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 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 to name transport-layer endpoints.  The HIP layer in the
   network stack internally translates Host Identities (HI) into
   network-layer IP addresses.

2.  Terminology

   This section defines terms used throughout the remainder of this
   specification.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this


Laganier & Eggert       Expires August 19, 2005                 [Page 3]


Internet-Draft          HIP Rendezvous Extension           February 2005

   document are to be interpreted as described in RFC 2119 [3].

   Rendezvous Service : A HIP Service provided by a HIP Rendezvous
   Server to its Rendezvous Clients.  The Rendezvous Server offers to
   relay some of the incoming HIP packets exchanged during a HIP
   exchange to the owner of their receiver HIT (i.e.  the Rendezvous
   Client or one of its correspondent nodes).

   Rendezvous Server (RVS): A HIP Registrar providing the Rendezvous
   Service.

   Rendezvous Client (RVC): A HIP Requester which has registered for the
   Rendezvous Service at a Rendezvous Server.

   Rendezvous Registration (RVR): A HIP Registration for the Rendezvous
   Service, established between a Rendezvous Server and a Rendezvous
   Client.

3.  Overview of Rendezvous Server Operation

   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.

   +-----+                +-----+
   |     |-------I1------>|     |
   |  I  |<------R1-------|  R  |
   |     |-------I2------>|     |
   |     |<------R2-------|     |
   +-----+                +-----+

         Figure 1: HIP Base Exchange without Rendezvous Server

   Figure 2 shows a simple HIP Base Exchange (without Rendezvous Server)
   in which the initiator initiates the exchange directly with the
   responder by sending an I1 packet to the responder IP address, as per
   the HIP 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.

   However, such a HIP node might also want to be still reachable by
   potential future correspondent peers unaware of its location change.
   The HIP architecture [1] introduces Rendezvous Servers at which a HIP


Laganier & Eggert       Expires August 19, 2005                 [Page 4]


Internet-Draft          HIP Rendezvous Extension           February 2005

   node register its current HIT and IP addresses.  The RVS basically
   relays HIP packet incoming at this HIT to the node IP address.  Thus,
   a peer publishing its RVS IP address instead of its own is reachable
   by means of rendezvous at its RVS IP address.

               +-----+
      +--I1--->| RVS |---I1--+
      |        +-----+       |
      |                      v
   +-----+                +-----+
   |     |<------R1-------|     |
   |  I  |-------I2------>|  R  |
   |     |<------R2-------|     |
   +-----+                +-----+

           Figure 2: HIP Base Exchange with Rendezvous Server

   Figure 2 shows a HIP Base Exchange involving a Rendezvous Server RVS.
   It is assumed that HIP node R precedently used the HIP registration
   protocol [2] to register with the RVS its HIT and IP address.  When
   the initiator I tries to establish contact with the responder, it
   does not need to know the current IP address of R.  Instead, I is
   aware of the RVS IP address of R, at which it sends an I1 packet.
   The RVS, noticing that the receiver HIT is not its own, but the HIT
   of a HIP node registered for the rendezvous Service, would relay the
   I1 to the responder IP address.  Typically the responder would then
   complete the exchange without further assistance from the RVS by
   sending an R1 directly to the initiator IP address.












Laganier & Eggert       Expires August 19, 2005                 [Page 5]


Internet-Draft          HIP Rendezvous Extension           February 2005

3.1  Diagram Notation

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

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

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

   REA:I                A REA parameter containing the IP address i is
                present in the HIP header

   FROM:I               A FROM parameter containing the IP address I is present
                in the HIP header

   TO:I         A TO parameter containing the IP address I is present
                in the HIP header

   VIA:RVS              A VIA_RVS parameter containing IP addresses RVS
                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 REG_REQUEST parameter is present in the HIP header

   RRES         A REG_RESPONSE parameter is present in the HIP header

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

3.2  Rendezvous Client Registering with a Rendezvous Server

   Before the Rendezvous Server starts to relay HIP packets to their
   receiver HIT owner (i.e.  a Rendezvous Client or one of its
   correspondent node), the Rendezvous Client needs to register with its
   Server for the Rendezvous Service, as shown in the following schema:





Laganier & Eggert       Expires August 19, 2005                 [Page 6]


Internet-Draft          HIP Rendezvous Extension           February 2005

   +-----+                            +-----+
   |     |            I1              |     |
   |     |--------------------------->|     |
   |     |<---------------------------|     |
   | RVC |    R1(REG_INFO,RVR:1,2)    | RVS |
   |     |      I2(REG_REQ,RVR:2)     |     |
   |     |--------------------------->|     |
   |     |<---------------------------|     |
   |     |      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
   +-----+    R1(R, I, HIT-R, HIT-I, REA:R, VIA:RVS)    +-----+
   |     |<---------------------------------------------|     |
   |     |                                              |     |
   |  I  |            I2(I, R, HIT-I, HIT-R)            |  R  |
   |     |--------------------------------------------->|     |
   |     |<---------------------------------------------|     |
   +-----+             R2(R, I, HIT-R, HIT-I)           +-----+

 Figure 5: I1_TUNNEL: Rendezvous Server Encapsulating I1 into a Tunnel

3.3.2  Rewriting I1 IP Header

   If a HIP node and one of its Rendezvous Servers have a Rendezvous
   Registration of type REWRITE_I1, the Rendezvous Server relays up to
   this node I1s incoming to this node's HIT by merely rewrite the IP


Laganier & Eggert       Expires August 19, 2005                 [Page 7]


Internet-Draft          HIP Rendezvous Extension           February 2005

   header.  The destination IP address of the I1 is replaced by the IP
   address of the receiver HIT owner (i.e.  the Rendezvous Client).

   However, because of egress filtering, a HIP Rendezvous Server might
   also 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.  Hence, such a node MUST append I1 packets with a FROM
   parameter containing the original source IP address of the 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 Rewriting I1 Source and
                        Destination IP Addresses

3.3.3  Bidirectional Forwarding of HIP packets

   In some cases it is useful to have a RVS which relay further HIP
   packets in a bidirectional manner, i.e.  from the initiator to the
   responder but also from the responder to the initiator.  These
   further packets would typically be either an R1 or an UPDATE.  A RVS
   behaves accordingly when the Rendezvous Registration Type is
   BIDIRECTIONAL.

   However, because such packets are larger than I1 (they contain a
   signature), their relaying create an opportunity for denial of
   service attacks.  To defend against these attacks, the Rendezvous
   Server needs to differentiate between legitimate HIP packets (i.e.,
   I1 and subsequent HIP packets triggered by an I1) and illegitimate
   ones.

   For the sake of reducing the load incurred on the RVS, an RVS is not


Laganier & Eggert       Expires August 19, 2005                 [Page 8]


Internet-Draft          HIP Rendezvous Extension           February 2005

   required to keep track of IP addresses and other pieces of state
   associated with ongoing HIP exchanges.  Such behavior is OPTIONAL.
   Instead, the relaying facility SHOULD make use of ECHO_REQUEST and
   ECHO_RESPONSE parameters.

   Each time a packet is being relayed and will possibly trigger an
   answer, the RVS MUST augment it with an ECHO_REQUEST parameter
   containing a chunk of opaque data.  The receiver of such a packet
   MUST augment any packet answering to this packet with an ECHO_REPLY
   parameter containing the same chunk of opaque data.  This opaque data
   allows an RVS to find and validate the answered packet IP addresses
   and HITs.  When successfully validated, ECHO_REPLY parameters MUST be
   removed from the packet before relaying.

       I1(I, RVS,                    I1(RVS, R, HIT-I, HIT-0
          HIT-I, HIT-0)   +---------+   FROM:I, EREQ)
    +-------------------->|         |----------------------+
    |+--------------------|         |<--------------------+|
    || R1(RVS, I, HIT-R,  |   RVS   | R1(R, RVS, HIT-R,   ||
    ||    HIT-I, REA:R,   |         |    HIT-I, REA:R,    ||
    ||    VIA:RVS)        |         |    TO:I, EREP)      ||
    ||                    |         |                     ||
    ||                    +---------+                     ||
    |V                                                    |V
   +-----+             I2(R, I, HIT-R, HIT-I)          +-----+
   |     |-------------------------------------------->|     |
   |  I  |<--------------------------------------------|  R  |
   |     |             R2(I, R, HIT-I, HIT-R)          |     |
   +-----+                                             +-----+

  Figure 7: BIDIRECTIONAL: Responder replying via the RVS to Initiator

3.3.4  Implication on the HIP integrity checks

   The establishment of HIP associations via one or more Rendezvous
   Servers causes HIP packets flowing between the HIP nodes to be
   modified during transmission.  Several kinds of modifications to both
   the IP and HIP headers are possible.  The HIP protocol uses two kinds
   of packet integrity checks: hop-by-hop and end-to-end.  The HIP
   checksum is a hop-by-hop check and SHOULD be verified and recomputed
   by each of the on-path HIP middle-boxes (e.g., Rendezvous Servers).
   The HMAC and SIGNATURE are end-to-end checks and MUST be computed by
   the sender and verified by the receiver.



Laganier & Eggert       Expires August 19, 2005                 [Page 9]


Internet-Draft          HIP Rendezvous Extension           February 2005

3.3.4.1  Checksum

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

3.3.4.2  HMAC and SIGNATURE

   The HMAC and SIGNATURE field of a HIP header MUST be computed and
   verified based on a "sender view" or "receiver view" of the HIP
   header.  In particular, this implies that SIGNATURE and HMAC MUST NOT
   cover FROM and TO parameters added or removed by Rendezvous Servers
   and that the HIP pseudo-header used to compute and verify them MUST
   contain the IP addresses as seen by the remote HIP peer.  In case of
   IP address concealment by the RVS, this means that the IP address of
   this RVS MUST be used in the pseudo-header in place of the IP address
   of the end host it conceals.

3.3.4.3  Example

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

   End-to-end integrity checks: HMAC and SIGNATURE are computed with a
   pseudo-header containing RVS1 as a place holder for the destination
   IP address, the rationale being that RVS1 is concealing the Responder
   IP address.  Therefore, R will verify the signature using RVS1 as the
   destination IP address in the pseudo-header.

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

4.  RVS Extensions Definition

   The following sections describe extensions to:

   o  The HIP registration protocol [2], allowing a HIP node to register
      with its Rendezvous Server for the Rendezvous Service and maintain
      the RVS aware of its current location.

   o  The HIP protocol [4] itself, allowing to establish an HIP
      association via one or more HIP Rendezvous Server(s).




Laganier & Eggert       Expires August 19, 2005                [Page 10]


Internet-Draft          HIP Rendezvous Extension           February 2005

4.1  Usage and Processing of Existing Parameters

4.1.1  ECHO_REQUEST and ECHO_REPLY Parameters

   A FROM parameter MAY be augmented by including an ECHO_REQUEST
   parameter to the carrying packet.  The contents of the ECHO_REQUEST
   MUST then be echoed back in ECHO_RESPONSE.

   A TO parameter MUST be augmented and authenticated by including an
   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



Laganier & Eggert       Expires August 19, 2005                [Page 11]


Internet-Draft          HIP Rendezvous Extension           February 2005

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            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  RVR Type #1  |  RVR Type #2  |                               |
     +-+-+-+-+-+-+-+-+---------------+        Padding                |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type         [ TBD by IANA {110) ]
   Length       8
   RVR Type An 8 bit number indicating the specific type of the
   Rendezvous Server/Service.

      Number RVR Type       Definition

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

      1      TUNNEL_I1      Tunneling I1 - Section 3.3.1

      2      REWRITE_I1     Rewriting I1 - Section 3.3.2

      3      BIDIRECTIONAL  Rewriting I1 and followers - Section 3.3.3

      3-200     Reserved by IANA

      201-255   Reserved by IANA for private use

   A Requester of a Rendezvous Registration SHOULD include the RVR_RYPE
   parameter along with any REG_REQUEST for the Rendezvous Service.
   This parameter specifies the desired RVS Type (i.e.  TUNNEL_I1,
   REWRITE_I1 or BIDIRECTIONAL).  It SHOULD NOT include the parameter
   unless there is a REG_REQUEST parameter included along.

   A Rendezvous Server SHOULD include a RVR_TYPE parameter along with
   any REG_INFO announcing support for the Rendezvous Service.  This
   parameter SHOULD specify all the RVR Types supported by the
   Rendezvous Server, in preference order.

   A Rendezvous Server MUST include a RVR_RYPE parameter along with any


Laganier & Eggert       Expires August 19, 2005                [Page 12]


Internet-Draft          HIP Rendezvous Extension           February 2005

   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
                HIP Association. This HMAC is computed over the HIP packet
                excluding 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 Rendezvous Client and its RVS to verify the integrity of
   packets flowing between them, both use an RVR_HMAC parameter keyed
   with a HMAC of HIP_lg and HIP_gl integrity keys.  One RVR_HMAC SHOULD
   be present on every packets flowing between a client and a server and
   MUST be present when FROM and TO parameters are processed.

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









Laganier & Eggert       Expires August 19, 2005                [Page 13]


Internet-Draft          HIP Rendezvous Extension           February 2005

4.3.3  FROM Parameter

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |             Type              |             Length            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     |                             Address                           |
     |                                                               |
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

   A Rendezvous Server MAY add a FROM parameter containing the original
   source IP address of a HIP packet whose source IP address has been
   rewritten.  If one or more FROM parameters are already present, the
   new FROM parameter MUST be appended after the existing ones.

   Each time an RVS inserts a FROM parameter, it MUST also insert an
   RVR_HMAC protecting the packet integrity that the Rendezvous Client
   will use to validate this packet.

   If the type of the RVR allows the Rendezvous Client to answer to a
   relayed packet via the RVS, an ECHO_REQUEST MUST be included along
   with the FROM parameter.  It contains a chunk of opaque data allowing
   to validate TO parameters included in a subsequent answer.  These TO
   parameters MUST be protected by an ECHO_RESPONSE containing the same
   opaque data.

   When a HIP node validates a FROM parameter, it is removed from the
   packet and recorded for later use (i.e., for building the
   corresponding TO parameter to be piggy-backed onto a subsequent
   answer).  The packet's source IP address is also replaced by the
   address included in the first occurrence of FROM parameter.

   For each FROM parameter, a HIP node MAY add to its replies a TO
   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.



Laganier & Eggert       Expires August 19, 2005                [Page 14]


Internet-Draft          HIP Rendezvous Extension           February 2005

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

   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 final
   destination IP address of a HIP packet whose destination IP address
   needs to be rewritten by an RVS.  This is essentially equivalent to
   loose source-routing.  If one or more TO parameters are already
   present, the new TO parameter MUST be appended after the existing
   ones.  Each time a node inserts a TO parameter, it MUST also insert
   additional parameters that will be used by the RVS for validation.
   These parameters are:

   o  An ECHO_RESPONSE, containing a chunk of opaque data allowing the
      RVS to validate the address contained in the TO parameter.

   o  A valid RVR_HMAC, protecting the packet integrity.

   When the RVS validates a TO parameter, SHALL remove it from the
   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.





Laganier & Eggert       Expires August 19, 2005                [Page 15]


Internet-Draft          HIP Rendezvous Extension           February 2005

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

   Type         [ TBD by IANA {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


Laganier & Eggert       Expires August 19, 2005                [Page 16]


Internet-Draft          HIP Rendezvous Extension           February 2005

   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.

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)


Laganier & Eggert       Expires August 19, 2005                [Page 17]


Internet-Draft          HIP Rendezvous Extension           February 2005

   o  FROM (defined in Section 4.3.3)

   o  TO (defined in Section 4.3.4)

   o  VIA_RVS (defined in Section 4.3.5)

   IANA needs to open a new registry specific to the HIP Rendezvous
   Extensions, for the Rendezvous Registration (RVR) Types values
   defined in Section 4.3.1:

      Type number       RVR Type

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

      0         Reserved by IANA

      1         TUNNEL_I1

      2         REWRITE_I1

      3         BIDIRECTIONAL

      3-200     Reserved by IANA

      201-255   Reserved by IANA for private use

   Adding new reservations requires IETF consensus RFC2434 [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.



Laganier & Eggert       Expires August 19, 2005                [Page 18]


Internet-Draft          HIP Rendezvous Extension           February 2005

8.  References

8.1  Normative References

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

   [2]  Laganier, J., Koponen, T. and L. Eggert, "Host Identity Protocol
        (HIP) Registration Extensions",
        draft-koponen-hip-registration-00 (work in progress), 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.

8.2  Informative References

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

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

   [8]   Nikander, P. and 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 2827, May 2000.

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




Laganier & Eggert       Expires August 19, 2005                [Page 19]


Internet-Draft          HIP Rendezvous Extension           February 2005

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                                              |
   +-----------+-------------------------------------------------------+
   | 01        | Splitted out the registration sub-protocol. Simplify  |
   |           | typology of relaying techniques (keep only TUNNEL,    |
   |           | REWRITE, BIDIRECTIONAL). Rewrote IANA Considerations. |
   | 00        | Initial version as a HIP WG item.                     |
   +-----------+-------------------------------------------------------+









Laganier & Eggert       Expires August 19, 2005                [Page 20]


Internet-Draft          HIP Rendezvous Extension           February 2005

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 (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.


Laganier & Eggert       Expires August 19, 2005                [Page 21]