[Hipsec] HIP transforms

[Tobias Heer <[e-mail]>]

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?

Tobias



-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi