Subject: RE: [Hipsec] Base HIP: 02 PRE1

From: "Henderson, Thomas R" <[email-masked]>
Date: Sun, 16 Jan 2005 21:07:06 -0800

> 
> 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?

I agree that this is a problem for multiple user data associations.
I didn't think that it was mandatory to include them in parameter
type order.  Regarding multiple associations and USER_DATA_FORMAT,
does this start to take us down the path of replicating IKE?

> 
>    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.
> 

Agreed.

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

---

From: Pekka Nikander <[email-masked]>
Date: Tue, 18 Jan 2005 14:56:09 +0200

>>         associations at the same time
>>

I don't think we *need* to solve this within the base specification.
On the other hand, we probably *could* solve this, e.g., by
relaxing the current parameter ordering rules.  For example, we
could define that a certain range of parameter types may appear
in any order.

What comes to IKE, I would consider that a completely separate
question, and belonging to the RG side.  FWIW, I still would like
to see  a concrete proposal for supporting HIP-like identities on
the top of IKEv2.  (I think there was a draft on something like
that some time ago, but IIRC I found it quite lacking.)

--Pekka