Subject: [Hipsec] Clarifying HIP parameter type ranges

From: Ari Keranen <[email-masked]>
Date: Tue, 06 Jul 2010 16:50:18 +0300

Hi all,

I think we should clarify, at least for the 5201bis, how new HIP 
parameter type values should be assigned. The current text at the end of 
section 5.2 of 5201 tries to do that, but it is not really accurate, and 
in some places even wrong (I filed errata about that a year ago). Here's 
what is 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.  Parameters numbered between 61440-62463 are used
    for signatures and signed MACs.  Parameters numbered between 62464-
    63487 are used for parameters that fall outside of the signed area of
    the packet.  Parameters numbered between 63488-64511 are used for
    rendezvous and other relaying services.  Parameters numbered between
    64512-65535 are reserved.

I talked about this with Jan, and we were thinking that for the first 
range (0-1023) it could make sense to rather say something like:
"Parameters that are important for basic HIP functionality and thus 
should be implemented by all HIP implementations."

For the reserved ranges, it should be mentioned for what purpose are 
they reserved (for future versions of HIP?).

For extensions that are not "basic functionality" there should be 
explicitly mentioned ranges for both signed and unsigned parameter values.

Also, it would be good to recommend semantic grouping for new 
parameters, i.e., parameters with similar purpose would be close to each 
other. Another question is should one start new sets from binary or 
decimal value boundaries; I'm personally inclined to start from decimal 
value boundaries (e.g., 32800 instead of 32768)

And the IANA page [1] should be updated with the ranges; at least for 
the reserved parts.

Opinions?

Cheers,
Ari

[1] 
http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3

---

From: Tobias Heer <[email-masked]>
Date: Thu, 08 Jul 2010 23:12:48 +0200

Hello Ari, 
Am 06.07.2010 um 15:50 schrieb Ari Keranen:

> Hi all,
> 
> I think we should clarify, at least for the 5201bis, how new HIP parameter type values should be assigned. The current text at the end of section 5.2 of 5201 tries to do that, but it is not really accurate, and in some places even wrong (I filed errata about that a year ago). Here's what is says:
> 
> I talked about this with Jan, and we were thinking that for the first range (0-1023) it could make sense to rather say something like:
> "Parameters that are important for basic HIP functionality and thus should be implemented by all HIP implementations."
> 
> For the reserved ranges, it should be mentioned for what purpose are they reserved (for future versions of HIP?).
> 
> For extensions that are not "basic functionality" there should be explicitly mentioned ranges for both signed and unsigned parameter values.

That works as long as you keep the signed and non-signed parts of the packet apart. Right now signature handling is quite simple and elegant. Therefore at least the fact that parameters with numbers smaller than x will be signed and the osthers won't.

I agree that the ranges could be more useful. We already did some reshaping by removing the transform-related range. However, I would like to keep existing type numbers i possible (and sensible).

Tobias

> 
> Also, it would be good to recommend semantic grouping for new parameters, i.e., parameters with similar purpose would be close to each other. Another question is should one start new sets from binary or decimal value boundaries; I'm personally inclined to start from decimal value boundaries (e.g., 32800 instead of 32768)

> 
> And the IANA page [1] should be updated with the ranges; at least for the reserved parts.
> 
> Opinions?
> 
> 
> Cheers,
> Ari
> 
> 
> [1] http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Distributed Systems Group 
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://ds.cs.rwth-aachen.de/members/heer
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi

---

From: Ari Keranen <[email-masked]>
Date: Fri, 09 Jul 2010 11:59:02 +0300

Hi Tobias,

On 07/09/2010 12:12 AM, Tobias Heer wrote:
> Hello Ari, Am 06.07.2010 um 15:50 schrieb Ari Keranen:
> 
>> Hi all,
>> 
>> parameter type values should be assigned. The current text at the
>> end of section 5.2 of 5201 tries to do that, but it is not really
>> accurate, and in some places even wrong (I filed errata about that
>> a year ago). Here's what is 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.  Parameters numbered between 61440-62463 are used for
>> signatures and signed MACs.  Parameters numbered between 62464- 
>> 63487 are used for parameters that fall outside of the signed area
>> of the packet.  Parameters numbered between 63488-64511 are used
>> for rendezvous and other relaying services.  Parameters numbered
>> between 64512-65535 are reserved.
>> 
>> I talked about this with Jan, and we were thinking that for the
>> first range (0-1023) it could make sense to rather say something
>> like: "Parameters that are important for basic HIP functionality
>> and thus should be implemented by all HIP implementations."
>> 
>> For the reserved ranges, it should be mentioned for what purpose
>> are they reserved (for future versions of HIP?).
>> 
> That works as long as you keep the signed and non-signed parts of the
> packet apart. Right now signature handling is quite simple and
> elegant. Therefore at least the fact that parameters with numbers
> smaller than x will be signed and the osthers won't.
> 
> I agree that the ranges could be more useful. We already did some
> reshaping by removing the transform-related range. However, I would
> like to keep existing type numbers i possible (and sensible).

I think the current way is technically good and I would not touch the 
parameter values or other technical details, but rather add some more 
explicit text to the draft (or modify the existing) giving hints where 
new parameter values should be inserted. Also, table representation 
instead of plain text could be better for that part of the text.

Cheers,
Ari

>> parameters, i.e., parameters with similar purpose would be close to
>> each other. Another question is should one start new sets from
>> binary or decimal value boundaries; I'm personally inclined to
>> start from decimal value boundaries (e.g., 32800 instead of 32768)
> 
>> Cheers, Ari