[Hipsec] Parameter space design (was: Updating parameter type values for VIA and BONE drafts)

[Tobias Heer <[e-mail]>]

Hello Ari,

Am 14.07.2010 um 12:22 schrieb Ari Keranen:

> Hi Tobias,
> 
> 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.

> 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.

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?


BR, 

Tobias


> 
> Cheers,
> Ari
> 
>>> [1] http://tools.ietf.org/html/draft-ietf-hip-bone-07#section-6.1 [2] http://tools.ietf.org/html/draft-ietf-hip-via-03#section-4.1 [3]
>>> http://tools.ietf.org/html/draft-ietf-hip-hiccups-05#section-4.1 
> 




-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: [phone]
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi