Subject: [Hipsec] Parameter space layout and significant change in wording

From: Tobias Heer <[email-masked]>
Date: Thu, 29 Jul 2010 19:29:06 +0200

Hi!

We were discussing the parameter space layout during the 5201-bis discussion session.
The result was the following. I marked the changes with "!"

  0     - 1023  Handshake
  1024  - 2047  Reserved
! 2048  - 8191  Signed parameters allocated through specification documents*
! 8192  - 61439 Reserved
! 61440 - 62463 Signatures and (signed) MACs
! 62464 - 63487 Parameters that are neither signed nor MACed*
  63488 - 64511 Rendezvous and relaying
! 64512 - 65023 Parameters that not signed*
! 65024 - 65535 Reserved

The rationale behind the changes was to have a non-BEX block and reserved blocks for future expansion in all vital spaces. The parts marked with * are the sub-spaces that are intended for extensions, etc. that do not strictly extend or modify the handshake. Any comments or objections?

IMPORTANT:
There is a slight change in wording to make creating HIP derivatives without signature less complex. I changed the "Signatures and MACs" to "Signatures and (signed) MACs" and "Parameters that are not signed" to "Parameters that are neither signed nor MACed". This will not change anything in the BEX (most importantly it will stay SIGMA compliant) but it avoids redefinition of parameters with different parameter numbers for DEX and other variants without signature capabilities. This is to allow a movement towards a "family" of interoperable HIP protocols. I would appreciate discussion and comments on this step on the list.

BR, 

Tobias

-- 
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, 30 Jul 2010 14:19:10 +0200

Hi,

29.7.2010 19:29, Tobias Heer kirjoitti:
> The rationale behind the changes was to have a non-BEX block and
> reserved blocks for future expansion in all vital spaces. The parts
> marked with * are the sub-spaces that are intended for extensions,
> etc. that do not strictly extend or modify the handshake. Any
> comments or objections?
>

Makes sense. Some of the old (HIP v1) parameters (FROM, RVS_HMAC, 
VIA_RVS, RELAY_HMAC, ROUTE_VIA) will end up in the last Reserved slot 
with these ranges, but those docs can be bis'ed where needed.

> IMPORTANT: There is a slight change in wording to make creating HIP
> derivatives without signature less complex. I changed the "Signatures
> and MACs" to "Signatures and (signed) MACs" and "Parameters that are
> not signed" to "Parameters that are neither signed nor MACed". This
> will not change anything in the BEX (most importantly it will stay
> SIGMA compliant) but it avoids redefinition of parameters with
> different parameter numbers for DEX and other variants without
> signature capabilities. This is to allow a movement towards a
> "family" of interoperable HIP protocols. I would appreciate
> discussion and comments on this step on the list.

Sounds like a good approach.

Cheers,
Ari