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

Robert Moskowitz <> Wed, 14 July 2010 13:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7610E3A681C for <>; Wed, 14 Jul 2010 06:22:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id H-apcivKjy51 for <>; Wed, 14 Jul 2010 06:22:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 5FE253A6877 for <>; Wed, 14 Jul 2010 06:22:40 -0700 (PDT)
Received: from localhost (unknown []) by (Postfix) with ESMTP id D0F0D68B0E; Wed, 14 Jul 2010 13:14:16 +0000 (UTC)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gyuyRqj9XJMb; Wed, 14 Jul 2010 09:14:07 -0400 (EDT)
Received: from (unknown []) (Authenticated sender: by (Postfix) with ESMTPSA id ACD9A68B4F; Wed, 14 Jul 2010 09:14:06 -0400 (EDT)
Message-ID: <>
Date: Wed, 14 Jul 2010 06:22:35 -0700
From: Robert Moskowitz <>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: Tobias Heer <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: HIP WG <>
Subject: Re: [Hipsec] Updating parameter type values for VIA and BONE drafts
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Jul 2010 13:22:42 -0000

On 07/14/2010 03:03 AM, 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).
> Maybe this could be one agenda item for the 5201-bis document crafting session?

In HIP DEX I have a HIP_MAC_3 parameter since its MACing rules are 
different than HIP_MAC or HIP_MAC_2.  So do I use the type +1 of 
HIP_MAC_2 or some other range?

I need an ENCRYPTED parameter but it has a much different content than 
what HIP BEX is encrypting.  Do I use the same parameter or make a 
different one?

In HIP DEX R1, I2, R2, UPDATE, NOTIFY, and CLOSE have different 
constructions.  R1, I2, R2 should not be a problem using the same Packet 
Type, by the HIP_SUITE_ID you know you are doing HPI DEX.  But what 
about UPDATE, NOTIFY, and CLOSE?  Is the HIP_SUITE_ID enough information 
to process them appropriately?  (note that the difference is they lack a 
HIP_SIGNATURE parameter, as DEX cannot do a signing operation).

Then there is the HIP RFID ID.  How should the parameters there be 
numbered and what about the Packet Types?

As I look at the evolving HIP Exchange 'family', I see we are able to 
target different classes of computing entities.  This is goodness and I 
am looking forward to pushing this concept in a number of venues.

HIP BEX     -     For REAL computing platforms, PCs, PDA, Network 
Infrastructure things
HIP DEX     -     For constrained sensors and embedded processors
HIP TEX     -      (what I am calling the RFID exchange, I don't like 
REX, it is for any tag object)

I am thinking of reworking a part of 4423-bis to discuss a family of 
exchanges beyond just the Base EXchange.