Subject: [Hipsec] Base HIP: 10-pre2 available

From: [email-masked] (Petri Jokela)
Date: Fri Apr 23 07:14:05 2004

I uploaded 10-pre2 version to our server:

http://hip4inter.net/drafts.php

There are text and html versions as well as diffs from 09 and 10-pre1.

Some notes and questions:

REJECT mechanism (NOTIFY): We should probably define more detailed the 
data that should be included in the Notification data field with each of 
the error types.

New parameters in 6.2, HIP parameters, we have now allocated all values 
up to 13. Should there be left more space or not? And is the current 
order of TLVs ok?

RESYNC mechanism changed.

Birthday changed.

Cookie mechanism changed. We have now opaque data in two locations: 
PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have it in two 
places?

/petri

---

From: [email-masked] (Julien Laganier)
Date: Mon Apr 26 12:57:03 2004

> I uploaded 10-pre2 version to our server:

<snip/>

> PUZZLE/SOLUTION and in ECHO_REQ/RESP. Is it necessary to have it in
> two places?

Related to Petri's question, I was wondering if an opaque data field 
should be present in the FROM/TO parameters used while a RVS is 
involved in a HIP exchange, or should we re-use ECHO_REQ/REP instead?

Also, the HMAC field included in FROM/TO parameters might be replaced 
by a stand-alone HMAC parameter added after FROM/TO. What do you 
think?

Thanks,

--julein

---

From: [email-masked] (Pekka Nikander)
Date: Tue Apr 27 03:06:00 2004

> involved in a HIP exchange, or should we re-use ECHO_REQ/REP instead?

That is a matter of taste.  But see below.

> by a stand-alone HMAC parameter added after FROM/TO. What do you

The intended semantics of HMAC are different.  Additionally, the current
HMAC is designed to be located before the signatures, while TO
and FROM are designed to be placed after the signature.

Yes, we could add a new HMAC type that comes after the signatures.
However, for the time being I would like to have the HMAC field
explicitly in FROM/TO.  Besides, their design has not been finalised.

More generally, this seems to be yet another occasion where we
have to find the balance between simplicity and flexibility.
Parameters that serve one purpose are easier to process, in general,
than cases where one must first process multiple parameters and is
only then able to act.  On the other hand, if the same data type
is clearly needed for multiple purposes, then it makes sense to
generalise it, even on the cost of some added complexity.

Considering this, the case of having an opaque data blob in
the TO/FROM depends heavily on how the blob is being planned
to be used, and how much complexity it would add to separate
it to the ECHO_* parameters.  My current feeling is that it would
probably be easier to have the separate opaque blob there.
Doing so most probably makes it easier to handle received
TO parameters.

--Pekka