Subject: [Hipsec] Base HIP: 02 PRE1

From: Petri Jokela <[email-masked]>
Date: Fri, 07 Jan 2005 15:29:18 +0200

Folks,

You can find the current pre-version, draft-ietf-hip-base-02-pre1, of 
the base draft in:

http://hip4inter.net/drafts.php

There are txt and html versions as well as the diff from -01 version.

The major edition is the removal of the ESP stuff (including rekeying) 
from it. There are still some XXXs where text is missing / needs some 
attention. Please read and comment (and provide text if you feel so).

The removed ESP text is moved to a new draft. I will be back with that 
draft next week.

/petri

-- 
Petri Jokela                        Tel:    +358 9 299 2413
Research scientist                  Fax:    +358 9 299 3535
NomadicLab, Ericsson Research       Mobile: +358 44 299 2413
Oy L M Ericsson Ab                  email: [email-masked]
_______________________________________________
Hipsec mailing list
[email-masked]
http://honor.trusecure.com/mailman/listinfo/hipsec

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 11 Jan 2005 14:02:50 +0200

> attention. Please read and comment (and provide text if you feel so).

I have now reviewed about the first third of the new draft in detail, 
and browsed the rest, at so far it looks pretty good.  I've made a few 
editorial and other changes; the editorial ones I'll send directly to 
Petri, and the other's I'll try to summarise here later.

So far I have came up with two more substantial issues:

   1. The order of user data transmission formats.

      The current idea in the draft (IIRC this this idea
      was mine, and hence my mistake) is that different
      user data transmission formats are indicated with
      distinct HIP parameters.  Obviously, ESP_TRANSFORM
      is the first of these.  The idea is also that the
      formats are placed in the HIP message in the
      preference order, if there are several.  Unfortunately,
      this does not work, for two reasons:

      - the hosts may desire to have multiple user data associations at 
the same time

      - the preference order and the parameter type order may be 
different

      Hence, something more flexible must be invented for this.
      Maybe a new USER_DATA_FORMAT parameter, which then carries
      a number of more specific parameters (also in TLV format?)?

      Opinions?

   2. UPDATE packet processing rules.

      The new base draft contains very little about how to process 
UPDATEs.
      I think it should specify, very exactly, how to use SEQ and ACK, 
how
      to retransmit outstanding but unacknowledged UPDATEs, etc.

--Pekka