Re: [Hipsec] Parameter space design

[Ari Keranen <[e-mail]>]

On 07/14/2010 05:24 PM, Tobias Heer wrote:
> Am 14.07.2010 um 12:22 schrieb Ari Keranen:
>> On 07/14/2010 01:03 PM, 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).
>> Actually, I did not mean to change the current "signed/unsigned, BEX, other stuff" grouping but rather add more semantics to the "other stuff" parts (signed and unsigned).
>>
> We are absolutely on the same page here. Using the current state as reference you are right. Using a more fine grained approach, which we might have in the near future, large buckets make no sense. Since we don't have that shiny new approach you are right to propose to take this and that number. I just wonder if we can't come up with something better.

Maybe we can, but on the other hand, we should try to avoid over 
engineering this.

>> Anyhow, I guess we agree that the 0-1023 is not the best range for these new parameters.
> Absolutely.
> 
>> I think the 4096+ range is good since that will leave us some space between the "BEX range" and the "new range" if need for a more "BEXy" range shows up later.
> Considering a possible redesign of the parameter space, I think it is a bit early to decide that.
> 
>> Right now that range is listed by IANA as "first come first served" so we don't need any real process for this, but I'm just asking if anyone thinks this is a bad idea.
>>
>>> Maybe this could be one agenda item for the 5201-bis document
>>> crafting session?
>> That would make sense.
>>
> Can we agree to come up with a "good" parameter space segmentation during the next IETF and take further steps then? Otherwise, we can also collect suggestions for a parameter space redesign here on the list. However, it would be nice to always have the big picture in mind and not discuss about subspaces in isolation.

I think we should do both; first get some ideas here on the list and 
then discuss at the meeting -- unless we can come up with good solution 
before that. Anyway, I would not consider this a critical issue, so we 
should not spend too much time on this.

> Right now it the complete parameter space looks like:
> 
> 0     - 1023  Handshake
> 1024  - 2047  Reserved
> 2048  - 4095  Signed if signature is present 
> 4096  - 61439 Reserved
> 61440 - 62463 Signatures and signed MACs
> 62464 - 63487 Parameters that are not signed
> 63488 - 64511 Rendezvous and relaying
> 64512 - 65535 Reserved
> 
> Any suggestions for new groups based on the parameter use?

I would prefer to keep the "group" definitions high level, and maybe 
even non-normative. The parameters discussed before are all "overlay 
networks related" so that could possibly be one group, but I'm not sure 
if even that is too low-level.

Also, I wonder if we would ever have over 1k different "signatures and 
signed MACs".


Cheers,
Ari