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

From: [email-masked] (Henderson, Thomas R)
Date: Mon Nov 8 07:52:00 2004

> -----Original Message-----
> From: Pekka Nikander [mailto:[email-masked]]=20
> Sent: Sunday, November 07, 2004 9:07 PM
> To: Julien Laganier; Lars Eggert
> Cc: [email-masked]
> Subject: [Hipsec] Comments to rvs-00.txt
>=20
> Julien and Lars,
>=20
> I have a number of high level comments to the rendezvous draft.
> In general, I think that the desired mechanisms are there,=20
> but according to my understanding of the WG charter, based on=20
> what I remember from the discussions with the ADs during the=20
> chartering time, the draft still has a too wide scope.  In my=20
> opinion, we should cut down the document contents quite a lot.

I have some similar concerns.  In case I am not at WG meeting
tomorrow when this is discussed, I would also suggest the
following:

- the Introduction could (should) be cut down substantially=20
by referring to the HIP architecture and base documents, and just=20
succintly state something like: =20

"The Host Identity Protocol (HIP) Architecture [arch] introduces=20
a new name space and protocol layer for Internet hosts.  The Host=20
Identity Protocol [base] provides a rapid exchange of Host Identities=20
between two hosts and establishes a pair of IPsec Security Associations
to be used with IPsec Encapsulated Security Payload (ESP) [ESP]."

Then, introduce briefly what this document is about; namely,
defining a HIP extension to allow for an infrastructure node called
a Rendezvous Server to serve as a relay point for HIP messages.

And then introduce the pieces (here I agree with Pekka to reduce
the scope substantially):
i) host registration to its rendezvous server (and associated state)
ii) host update of its care-of IP address to the rendezvous server
iii) how, if an initiator gets IP address of rendezvous server via=20
HIPRVS DNS record or other means, it can send I1 (and return R1)=20
through the rendezvous server

If document is split, then i)+ii) can go into one document and iii) into
another.

- I agree with the need to generalize the means by which I1 (and R1)
are sent between R-Server and its client (i.e., various tunneling
techniques are possible).

- should we define, at this time, how rendezvous servers help
the double jump problem (by allowing RVS to also forward
HIP UPDATE packets)?  Right now, it only seems to deal with
I1 and R1.  We could describe suitable end host behavior in the
hip-mm document.

Tom

---

From: [email-masked] (Pekka Nikander)
Date: Mon Nov 8 08:20:00 2004

> i) host registration to its rendezvous server (and associated state)

As I already stated, I think that this should probably be a separate
document, since such a registration function seems to be useful also
in other contexts, like HIP NAT traversal.

> ii) host update of its care-of IP address to the rendezvous server

I agree that this should be there, and probably part of the registration
protocol.  Right now, the required mechanism is not that cleanly
explained.  There will probably be some dependencies to the mm draft.

> iii) how, if an initiator gets IP address of rendezvous server via
> HIPRVS DNS record or other means, it can send I1 (and return R1)

Right.  And while there seem to be a lots of different ways of
how to forward I1 (and R1), I think that we basically want to
define only one or two.  Maybe two, since I see a tunnelling
based solution different enough from a header-rewriting solution
so that you probably want both.

> I1 and R1.

Yes, that is missing.

> We could describe suitable end host behavior in the
> hip-mm document.

I agree.

--Pekka