Re: [Hipsec] Updating parameter type values for VIA and BONE drafts

Ari Keranen <ari.keranen@nomadiclab.com> Wed, 14 July 2010 10:22 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 ABC203A677C for <hipsec@core3.amsl.com>; Wed, 14 Jul 2010 03:22:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.497
X-Spam-Level:
X-Spam-Status: No, score=-2.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599]
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 6E5uca-bGuGy for <hipsec@core3.amsl.com>; Wed, 14 Jul 2010 03:22:52 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 438C33A69C0 for <hipsec@ietf.org>; Wed, 14 Jul 2010 03:22:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id D00AB4E6DA; Wed, 14 Jul 2010 13:23:00 +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 FigYM828Pemj; Wed, 14 Jul 2010 13:23:00 +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 460294E6D5; Wed, 14 Jul 2010 13:23:00 +0300 (EEST)
Message-ID: <4C3D8FFF.9020005@nomadiclab.com>
Date: Wed, 14 Jul 2010 13:22:55 +0300
From: Ari Keranen <ari.keranen@nomadiclab.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: Tobias Heer <heer@cs.rwth-aachen.de>
References: <4C3C7661.4000408@nomadiclab.com> <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de>
In-Reply-To: <3C59C310-9904-418D-AE52-F1E9891D89C8@cs.rwth-aachen.de>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP WG <hipsec@ietf.org>
Subject: Re: [Hipsec] Updating parameter type values for VIA and BONE drafts
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: Wed, 14 Jul 2010 10:22:54 -0000

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

Anyhow, I guess we agree that the 0-1023 is not the best range for these 
new parameters. 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. 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.


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