Re: [Hipsec] Updating parameter type values for VIA and BONE drafts

[Robert Moskowitz <[e-mail]>]

On 07/14/2010 03:03 AM, Tobias Heer wrote:
> Hello Ari,
>
> Am 13.07.2010 um 16:21 schrieb Ari Keranen:
>
>    
>> Hi all,
>>
>> As discussed in the other thread, instead of adding new parameters to the 0-1023 range, we should rather use higher ranges for "non-essential" type of extensions. Currently the text in RFC5201 about the ranges says:
>>
>>    Parameters numbered between 0-1023 are used in HIP
>>    handshake and update procedures and are covered by signatures.
>>    Parameters numbered between 1024-2047 are reserved.  Parameters
>>    numbered between 2048-4095 are used for parameters related to HIP
>>    transform types.  Parameters numbered between 4096 and (2^16 - 2^12)
>>    61439 are reserved.
>>
>> The VIA and BONE extensions are not actually "handshake and update procedures", or "essential stuff", but we originally put the signed parameters OVERLAY_ID [1] and ROUTE_DST [2] there since the other possible ranges, according to the text above, were "reserved".
>>
>> However, better approach would be to use a higher range for this kind of extensions. For example, 4096-16383. Latest version of HICCUPS [3] already uses that range and we were planning to move the OVERLAY_ID and ROUTE_DST parameters there too (values 4592 and 4600, respectively), unless someone objects.
>>      
> I agree that the current assignments are way to coarse grained. However, I am not really convinced that putting all extensions into one big bucket is the solution we want. Right now we have a grouping based on functionality and security requirements (signed/unsigned, BEX, other stuff). I like that approach (and would like it even better if it was a bit more fine grained) because it allows implementors to classify parameters easily. Putting every extension into the same range would mean that you can only distinguish between extension and non-extension. I would rather try to come up with a sensible allocation based on functions (although I don't have one at hand right now).
>
> Maybe this could be one agenda item for the 5201-bis document crafting session?

In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are 
different than HIP_MAC or HIP_MAC_2.  So do I use the type +1 of 
HIP_MAC_2 or some other range?

I need an ENCRYPTED parameter but it has a much different content than 
what HIP BEX is encrypting.  Do I use the same parameter or make a 
different one?

In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different 
constructions.  R1, I2, R2 should not be a problem using the same Packet 
Type, by the HIP_SUITE_ID you know you are doing HPI DEX.  But what 
about UPDATE, NOTIFY, and CLOSE?  Is the HIP_SUITE_ID enough information 
to process them appropriately?  (note that the difference is they lack a 
HIP_SIGNATURE parameter, as DEX cannot do a signing operation).

Then there is the HIP RFID ID.  How should the parameters there be 
numbered and what about the Packet Types?

As I look at the evolving HIP Exchange 'family', I see we are able to 
target different classes of computing entities.  This is goodness and I 
am looking forward to pushing this concept in a number of venues.

HIP BEX     -     For REAL computing platforms, PCs, PDA, Network 
Infrastructure things
HIP DEX     -     For constrained sensors and embedded processors
HIP TEX     -      (what I am calling the RFID exchange, I don't like 
REX, it is for any tag object)

I am thinking of reworking a part of 4423-bis to discuss a family of 
exchanges beyond just the Base EXchange.