Subject: [Hipsec] Comments to rvs-00.txt

From: Pekka Nikander <[email-masked]>
Date: Sun, 7 Nov 2004 21:07:08 -0500

Julien and Lars,

I have a number of high level comments to the rendezvous draft.
In general, I think that the desired mechanisms are there, but
according to my understanding of the WG charter, based on what
I remember from the discussions with the ADs during the
chartering time, the draft still has a too wide scope.  In my
opinion, we should cut down the document contents quite a lot.
More specifically, I would suggest the following:

   1. Split the draft into two documents:

      a.  A generic HIP "Registration" protocol that could
          be also used for other purposes but registering
          oneself to a rendezvous server.

      b.  A rendezvous service document, relying on the
          generic registration protocol, and defining just
          some basic rendezvous services

   2. Moving of many advanced rendezvous features either
      to an appendix or to a separate draft.  As a first
      step, I suggest that the content is moved to an
      appendix, determining later whether it should be
      cut out altogether, left in an appendix, or moved
      to a separate draft.

At the detail level, this could be accomplished in the
following way:

- Section 3, page 4, starting from "This section
   discusses the different approaches...", and ending
   at the end of Section 3 on page 6:  Move to an appendix.

- Section 4.1: Move to an appendix.

- From Section 5.1, page 10, to end of Section 5.2.3 on
   page 13:  Move to the generic registration draft.

- Section 7:  Move to the generic registration draft

- Section 7, page 19, starting with "If a HIP node wants to
   associate...", ending at the end of Section 7: Move to
   an appendix.

- Section 8.1:  Remove or move to an appendix.

- Section 8.3:  Remove or move to an appendix.

- Section 8.6:  Move to an appendix.

After these structural changes, I would suggest the
following content changes:

1. In the generic registration protocol:

- Rename the parameters to REGISTRATION_REQUEST and
   REGISTRATION_REPLY.

- Rename the RVA Type field to Registration Type

- Define a new parameter, REGISTRATION_INFO, which
   simply lists a number of registration types.
   The lifetime field denotes a maximum lifetime
   that the server is willing to server.  This
   parameter MAY be included in an R1, and if it is,
   it MUST be protected by the signature.

- Split the Registration Type (previous RVA type)
   field into two 8-bit fields, "Registration Type"
   and "Registration Subtype".   The values of these
   fields are to be specified elsewhere.  Define
   rules (Standards action?) for defining new types.

- Specify that a HIP host that is willing to act as
   a server (of some kind), accepting registration,
   SHOULD send a REGISTRATION_INFO parameter in the
   R1 message, and that it MAY send REGISTRATION_INFO
   other HIP messages, including I1, I2 and UPDATE.

- Remove the RVS_CAPABLE bit as it is no longer
   needed, i.e., delete Section 5.1.

- In Section 7 on page 18, change the second
   paragraph to read as follows:

    A HIP node MAY register with its a server that supports registration
    while establishing a HIP association by adding an 
REGISTRATION_REQUEST
    parameter in an I2.  A server replies with an R2 that contains an
    REGISTRATION_REPLY parameter specifying the characteristics of the
    provided registration (lifetime, type, etc.).  Depending on the
    type of the registration, the server and the HIP node MAY delete 
most of
    the HIP Association state, retaining only the lifetime, Initiator's
    HIT and IP address(es), and the necessary keying material.

- Write a new IANA considerations section.

2. In the slimmed down rendezvous document,

- Specify the following Registration Type and Subtypes.

     Number Registration Type
     ------ -----------------
       1     Rendezvous service

     Subtypes for Rendezvous service

     Number Rendezvous Subtype
     ------ ------------------
       1      TUNNEL_I1     (Section 8.2)
       2      REWRITE_I1    (Section 8.4)
       3      BIDIRECTIONAL (Section 8.5)

    Remove the explanations of the rendezvous types on page 11 and 12,
    and simply add references to the appropriate sections where the
    actual behaviour is defined.

- Section 8.2.  Rewrite the section to be more generic, allowing
   different types of tunnelling.  The server may tunnel the I1 over
   the HIP association, open an ESP association, or e.g. over UDP
   using STUN.  The method used depends on which kind of association
   the server has with the HIP node.

- Write a new IANA considerations section.

3. Finally, some minor edits:

- Section 1, page 3:

   Join paragraphs 2, 3, 4.

- Section 2, page 4:

   IMHO, relaying back R1 is not limited to opportunistic Initiators.
   Remove the word "opportunistic".

- Section 4.2, page 8.

   First paragraph, line 5.  Add a reference to [3] at the full stop.

   Last sentence on the page:  Change the phrase "packets will directly 
flow"
   to "packets may directly flow" or "packets will typically flow 
directly"

- Section 4.2, page 9.

   Second paragraph.  I don't see any reason why a HIP node cannot 
include
   both its native and RVS addresses in the DNS.  Please rephrase to 
reflect
   this.

   Third paragraph, fourth line.  Add "In the typical case, " before
   "The remainder of the ..."

--Pekka

_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Julien Laganier <[email-masked]>
Date: Tue, 09 Nov 2004 23:03:32 +0100

>       cut out altogether, left in an appendix, or moved

Pekka and Tom,

As I said during the WG meeting on monday, I think what you are 
proposing make perfect sense. Hence, I'll follow your recommendations 
and send soon to the ML updated versions of the two resulting I-Ds.

Thanks,

--julien