Re: [Hipsec] HIP transforms

[Miika Komu <[e-mail]>]

Hi,

On 12/02/11 18:47, Tobias Heer wrote:
> Hi everyone,
>
> this came up in Miika's and Ari's review of 5201-bis. The cited text comes from
> rfc5201 - This also affects rfc5202.
>
> <rfc5201>
>> 5.2.1.  TLV Format
>>
>>   The type-field value also describes the order of these
>>   fields in the packet, except for type values from 2048 to 4095 which
>>   are reserved for new transport forms.
>>
> ...
>     Parameters using type values from 2048 up to 4095 are transport
>     formats.  Currently, one transport format is defined: the ESP
>     transport format [I-D.ietf-hip-rfc5202-bis].  The order of these
>     parameters does not follow the order of their type value, but they
>     are put in the packet in order of preference.  The first of the
>     transport formats it the most preferred, and so on.
> ...
>
> </rfc5201>
>
>> Ari: This is a bit strange exception. I wonder if it would make sense to make this consistent with the other ordered lists, i.e., have one parameter that lists the supported transport formats and then, depending on which format was chosen, the corresponding parameter(s) from this range are used (and others ignored).
>
> As Ari correctly stated, we have other negotiations in BEX and these use
> different preference lists encoded as list parameters (e.g., DH list, HIT suite
> list). Even the ESP transform parameter (rfc5202, type 4095) has such list.
>
> The question is: is the exception for the transport formats really
> good/necessary/justified or should we consider an alternative?
>
> I personally think lifting this exception will make implementations simpler and
> less error prone. Especially the checking of the parameter sequence would be
> easier.
>
> I see two options here:
>
>
> A) Give all transforms the same type number and an additional sub-type number.
> The order of the parameters in the HIP packet would indicate the preference
> then. From a handling-point-of-view this option is very similar to as it is now
> but there would be just one transform type with subtypes.
>
> Example HIP packet excerpt:
> (2096 is an arbitrary type number for the new transport form parameter)
> +------+ +------+--------+ +------+--------+
> |Header| | 2096 | 1| ESP | | 2096 | 2| XYZ | ...
> +------+ +---------------+ +------+--------+
> This would mean ESP is preferred, XYZ is not preferred but supported.
>
>
>
> B) Give all transforms different type numbers, keep the ordering and express
> preference in a list. From a specification-point-of-view this is similar to what we have now.
> 5202 could stay mostly as it is now.
>
> Example HIP packet excerpt:
> (ESP has type number 4095 but for the clarity of the example I use 2095)
> +------+ +----+--------------+ +----+---+ +----+---+
> |Header| |2050|List: ESP, XYZ| |2095|XYZ| |4095|ESP| ...
> +------+ +----+--------------+ +----+---+ +----+---+
>                  ^
>                  |
> List------------+
>
> Again, this would mean ESP is preferred, XYZ is not preferred but supported.
>
> I prefer option B because it is more similar to other negotiations in BEX.
>
> Any opinions?

what about:

C) The order of these parameters follows the order of their type value 
and they are put in the packet in order of preference.

Then the type value for ESP should be (2048 + 4095) / 2 =~ 3071 (further 
types should be allocated similarly).

If not C), then my vote goes to B).