[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 [127.0.0.1]) 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-Level:
X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (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 [127.0.0.1]) 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 ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (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 2.0.0.24 (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. Opinions? Cheers, Ari [1] http://www.iana.org/assignments/hip-parameters/hip-parameters.xhtml#hip-parameters-3
- [Hipsec] Clarifying HIP parameter type ranges Ari Keranen
- Re: [Hipsec] Clarifying HIP parameter type ranges Tobias Heer
- Re: [Hipsec] Clarifying HIP parameter type ranges Ari Keranen