Subject: [Hipsec] rendezvous section of hip-arch

From: [email-masked] (Lars Eggert)
Date: Mon Mar 1 19:44:00 2004

This is a cryptographically signed message in MIME format.

--------------ms030809050404090200070101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

as explained during my RG slot yesterday, I'd like the group to consider 
changing the hip-arch ID to remove discussion of the specifics of 
rendezvous mechanisms.

I'll go over this in the WG slot as well, but the basic reason is that 
the current text in the hip-arch ID states some specifics about the 
behavior of rendezvous mechanisms that may paint us into a corner. 
Having this text in the hip-arch ID when it goes to RFC may complicate 
the RG's and WG's work into the details of rendezvous mechanisms.

Here's some proposed changes to the only three parts of 
draft-moskowitz-hip-arch-05.txt that talk about rendezvous. They 
essentially remove these specifics:

(1) Change section 5.1 to:

5.1 Rendezvous mechanism

    Making a contact to a mobile node is slightly more involved.  In
    order to start the HIP exchange, the initiator node has to know how
    to reach the mobile node.  Although Dynamic DNS could be used for
    this function for infrequently moving nodes, an alternative to using
    DNS in this fashion is to use a piece of new static infrastructure
    to facilitate a rendezvous between HIP nodes.

    A rendezvous mechanism is also needed if both of the nodes are mobile
    and happen to move at the same time.  In that case, the HIP readdress
    packets will cross each other in the network and never reach the peer
    node.

    A separate document will specify the details of the HIP rendezvous
    mechanism.

(2) Remove the last paragraph of section 9 (just before 9.1). I'm not 
too worried about what it says about rendezvous servers, but it doesn't 
seem to follow out of the preceding paragraph, and it doesn't lead into 
the following section. Don't know the edit history of the ID in detail; 
maybe it is left over from a previous round of edits? It currently reads:

    Since all systems can have a Host Identity, every system can have an
    entry in the DNS.  The mobility features in HIP make it attractive to
    trusted 3rd parties to offer rendezvous servers.

(3) Change item 6 of section 9.1 to:

    6.  What administrative infrastructure is needed to support it?

           It is possible to use HIP opportunistically, without any
           infrastructure.  However, to gain full benefit from HIP, the
           HIs must be stored in the DNS or a PKI, and a new
           rendezvous mechanism is needed.

Comments?

Lars
-- 
Lars Eggert                                     NEC Network Laboratories

--------------ms030809050404090200070101
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

--------------ms030809050404090200070101--

---

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 5 00:50:01 2004

Lars,

I worded this slightly differently, resulting in the following:

> 6.1 Rendezvous mechanism
> to
>    facilitate rendezvous between HIP nodes.
>
>    The mobile node keeps the rendezvous infrastructure continuously
>    updated with its current IP address(es).  The mobile nodes must 
> trust
>    the rendezvous server to properly maintain their HIT and IP address
>    mappings.
>
>    The rendezvous mechanism is also needed if both of the nodes happen
>    to change their address at the same time, either because they are
>    mobile and happen to move at the same time, because one of them is
>    off-line for a while, or because of some other reason.  In such a
>    case, the HIP readdress packets will cross each other in the network
>    and never reach the peer node.
>

Ok?

> (2) Remove the last paragraph of section 9.

Tentatively removed, subject to further discussion / objection by Bob M.

Again, I worded it slightly differently, resulting in the following:

>           HIs must be stored in the DNS or a PKI, and a new rendezvous
>           mechanism is needed.  Such a new rendezvous mechanism may 
> need
>           new infrastructure to be deployed.

Ok?

--Pekka

---

From: [email-masked] (Lars Eggert)
Date: Fri Mar 5 19:16:00 2004

--------------ms080405010808020407020202
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Pekka,

Pekka Nikander wrote:
>>    DNS in this fashion is to use a piece of new static infrastructure to

editorial nit: This reads like dynDNS could provide the rendezvous 
function, which it can't - it can be used to update the locality 
information. Slightly reworded:

"Although infrequently moving HIP nodes could use Dynamic DNS to update 
their reachability information in the DNS, an alternative is..."

But I can live with your text as well, if you'd rather keep it.

>>    updated with its current IP address(es).  The mobile nodes must trust

Looks good, modulo the change suggested above.

> Tentatively removed, subject to further discussion / objection by Bob M.

Looks fine - this change is not something critical, was a more editorial 
comment.

>>           mechanism is needed.  Such a new rendezvous mechanism may need

Yup.

Thanks for taking care of this so quickly!

Lars

--------------ms080405010808020407020202

--------------ms080405010808020407020202--

---

From: [email-masked] (Pekka Nikander)
Date: Fri Mar 5 19:24:03 2004

> "Although infrequently moving HIP nodes could use Dynamic DNS to 
> update their reachability information in the DNS, an alternative 
> is..."

Ok, adopted.

>>>    the rendezvous server to properly maintain their HIT and IP 

I also fixed the above mention of a "server" to mention a "mechanism".

--Pekka