[Hipsec] Clarifying HIP parameter type ranges

Ari Keranen <ari.keranen@nomadiclab.com> Tue, 06 July 2010 13:50 UTC

Return-Path: <ari.keranen@nomadiclab.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 122553A6870 for <hipsec@core3.amsl.com>; Tue, 6 Jul 2010 06:50:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.74
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id zfGH-mxahp1a for <hipsec@core3.amsl.com>; Tue, 6 Jul 2010 06:50:19 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id D09FE3A67AE for <hipsec@ietf.org>; Tue, 6 Jul 2010 06:50:17 -0700 (PDT)
Received: from localhost (localhost []) by gw.nomadiclab.com (Postfix) with ESMTP id 7FB9B4E6E6 for <hipsec@ietf.org>; Tue, 6 Jul 2010 16:50:19 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([]) by localhost (inside.nomadiclab.com []) (amavisd-new, port 10024) with ESMTP id V38V73662DoP for <hipsec@ietf.org>; Tue, 6 Jul 2010 16:50:18 +0300 (EEST)
Received: from [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1] (unknown [IPv6:2001:14b8:400:101:21c:23ff:fe45:a6c1]) by gw.nomadiclab.com (Postfix) with ESMTP id 889B74E6E5 for <hipsec@ietf.org>; Tue, 6 Jul 2010 16:50:18 +0300 (EEST)
Message-ID: <4C33349A.7020904@nomadiclab.com>
Date: Tue, 06 Jul 2010 16:50:18 +0300
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Thunderbird (X11/20100411)
MIME-Version: 1.0
To: HIP WG <hipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [Hipsec] Clarifying HIP parameter type ranges
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Jul 2010 13:50:20 -0000

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.