[hiprg] New thoughts on HIT construction

Robert Moskowitz <rgm@htt-consult.com> Tue, 15 June 2010 12:44 UTC

Return-Path: <rgm@htt-consult.com>
X-Original-To: hiprg@core3.amsl.com
Delivered-To: hiprg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BE93A6A6B for <hiprg@core3.amsl.com>; Tue, 15 Jun 2010 05:44:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.387
X-Spam-Level:
X-Spam-Status: No, score=0.387 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_50=0.001]
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 xSRDKnzBvW-v for <hiprg@core3.amsl.com>; Tue, 15 Jun 2010 05:44:45 -0700 (PDT)
Received: from klovia.htt-consult.com (klovia.htt-consult.com [208.83.67.149]) by core3.amsl.com (Postfix) with ESMTP id 9B67C3A68E4 for <hiprg@irtf.org>; Tue, 15 Jun 2010 05:44:45 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1]) by klovia.htt-consult.com (Postfix) with ESMTP id 6656C68B59 for <hiprg@irtf.org>; Tue, 15 Jun 2010 12:37:16 +0000 (UTC)
Received: from klovia.htt-consult.com ([127.0.0.1]) by localhost (klovia.htt-consult.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9LB3WzxJC8iM for <hiprg@irtf.org>; Tue, 15 Jun 2010 08:37:07 -0400 (EDT)
Received: from nc2400.htt-consult.com (h155.home.htt [208.83.67.155]) (Authenticated sender: rgm@htt-consult.com) by klovia.htt-consult.com (Postfix) with ESMTPSA id 2808B68B51 for <hiprg@irtf.org>; Tue, 15 Jun 2010 08:37:07 -0400 (EDT)
Message-ID: <4C1775B5.80702@htt-consult.com>
Date: Tue, 15 Jun 2010 08:44:37 -0400
From: Robert Moskowitz <rgm@htt-consult.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-2.fc12 Thunderbird/3.0.4
MIME-Version: 1.0
To: "hiprg@irtf.org" <hiprg@irtf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [hiprg] New thoughts on HIT construction
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Tue, 15 Jun 2010 12:44:46 -0000

While out on my 8Km morning walk I had some thoughts on HIT construction....

Current HIT construction is a truncation of the hash of the Host ID 
public key.  This binds the HIT strongly to the HI, a key component   
This was OK with our initial (and current) limited choices of Public 
Keys (RSA or DSA) and hash (SHA-1).  We are now looking at a significant 
change in the composite of what identifies a host.

What I propose it including the 'domain' of the HIT in composing the 
HIT.  This means to take the HIT prefix and HostIDSuite and concatenate 
this with the public key before hashing.  This binds the prefix and 
Suite ID into the HIT.

For the 'simple' case in BEX where only the IPv6 prefix and Suite ID are 
now included in the HIT generation, one might wonder what is gained with 
this construct.  Little, I suspect.  But consider other classes of uses 
that we have talked about and are even currently working on:

Hierarchical HITs

The HIT is clearly restricted within the domain of the assigned 
hierarchy by including the Hierarchy ID value in the HIT generation.

MACsec

There are only 24 bits available in EUI-48, but if the 24 bit OUI is 
included in the HIT construction the HIT is specifically bound to the 
OUI as well as the Host ID.  This effectively reduces the NIC population 
to 2^23, as well as needing to add logic to deal with MAC collisions on 
a sub-net, but it offers some interesting binding possiblities.

RFID

I don't know how large the vendor controlled field is in RFID.  I did 
just a couple of searches and came up empty.  I once knew more about 
this (back in my Chrysler days).  But would this be a way to fold RFIDs 
into our HIT concept?

What other places where a host can have an Identity that we can think 
about the construction of a HIT within the framework of that hosts 
network protocol?

This needs fleshing out.  Anyone interested in this?  This IS a good 
time to look deeper into HITs while we are developing 5201-bis.