Re: [Hipsec] DEX parameters and parameter usage

[Robert Moskowitz <[e-mail]>]

>
> Hello Robert,
>
> Am 14.07.2010 um 15:22 schrieb Robert Moskowitz:
>
>    
>> 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?
>>      
> +1 implies that the HIP_MAC_3 is not critical. Is this the case? Otherwise, +2 would be appropriate. Some spacing might not hurt either.
>
>    
>> 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?
>>      
> I would suggest to use a different one if it does something different.
>    
>> 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).
>>
>>      
> I believe the packet types should stay the same as long as the function is identical. They may have different parameters but no implementation will ever run into the problem of having to handle a Diet HIP CLOSE, UPDATE or NOTIFY if it does not complete a DEX first. Of course it could receive such packet as result of an error but that would just be a malformed packet then, right?
>
>
>    
>> Then there is the HIP RFID ID.  How should the parameters there be numbered and what about the Packet Types?
>>      
> It is difficult to answer this question without knowing the actual differences between HIP BEX and the RFID thing.
>    


draft-irtf-hiprg-rfid-00.txt


>    
>> 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.
>>
>>      
> I would be cautious not to stretch this too far. It makes sense to be flexible but engineered flexibility often comes at the price of complexity. I think there should be a good amount of overlap between the concepts and technical solutions of BEX, DEX, and TEX to really state that they are all HIP.
>
> Tobias
>
>    
>>      
>
>
>
>