Re: [hiprg] Putting HIP on a Diet

jnc@mercury.lcs.mit.edu (Noel Chiappa) Mon, 17 May 2010 17:33 UTC

Return-Path: <jnc@mercury.lcs.mit.edu>
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 2F1A73A6872 for <hiprg@core3.amsl.com>; Mon, 17 May 2010 10:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[AWL=-0.299, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 cdWtgearwsFE for <hiprg@core3.amsl.com>; Mon, 17 May 2010 10:33:12 -0700 (PDT)
Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by core3.amsl.com (Postfix) with ESMTP id 340AA3A6783 for <hiprg@irtf.org>; Mon, 17 May 2010 10:33:05 -0700 (PDT)
Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 798446BE575; Mon, 17 May 2010 13:32:56 -0400 (EDT)
To: hiprg@irtf.org, hipsec@ietf.org
Message-Id: <20100517173256.798446BE575@mercury.lcs.mit.edu>
Date: Mon, 17 May 2010 13:32:56 -0400 (EDT)
From: jnc@mercury.lcs.mit.edu (Noel Chiappa)
X-Mailman-Approved-At: Mon, 17 May 2010 10:41:41 -0700
Cc: jnc@mercury.lcs.mit.edu
Subject: Re: [hiprg] Putting HIP on a Diet
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: Mon, 17 May 2010 17:33:12 -0000

    > From: Robert Moskowitz <rgm@htt-consult.com>

    > What is HIP? Is HIP the exchange we have now have and only that? Or is
    > HIP a class of protocols built on a Host Identity, each bring a
    > slightly different set of security claims and risks and a slightly
    > different domain of use?  

Well, those are some key (and excellent) questions - and I would think you
need to answer them all fairly fully, and fairly early in the design process.

I don't have a problem with an architecture that includes optional extensions
that provide richer functionality sets, but... I would be wary of a design
that does so _at the expense of interoperability between different groups of
nodes_.

So I would say that you need to define a basic architecture, at a fairly high
semantic level (e.g. 'HIP is an architecture that provides Host Identities
based on cryptographic means blah blah blah'). (Sorry, I haven't read the HIP
architecture document in a long time, so I don't recall if you all already
have such a statement.) It should, in its highest-level form, be a paragraph
or so long - longer than that, and it's either i) not high enough level, or
ii) too complex. And if it doesn't cover all the versions of HIP without
version-specific language, then again there's a problem.

Having done that, I think you should try and define some namespace(s) (both
in semantics and syntax) which are common across _all_ variants, because it
is those namespace(s) which allow interoperation across the variants.
(Although the full detailed semantics of all variants might not be totally
understood by all participants: much as the full meanings of some human names
are only understood by subsets of readers, those who are in the same
linguistic pool - others may be able to parse them, and use them for _some_
functions, e.g. to uniquely identify the bearers, but will not extract the
full semantic functionality. A good example of this sort of thing would be
'Cohen'.)

Then you can define HIP-lite as the 'base' HIP, and the variants which
provide different (presumably more complex/expensive) security properties
(and thus applicability to different usage domains) would be extensions to
that base. Communicating nodes that both implement a particular extension
could opt to use that extension _if the application at hand needed the
security properties that extension provides_, and they were willing to
pay the overhead of using that extension.

Sorry if this all sounds either i) obvious, or ii) hand-wavy - this is as
best as I can put it.

	Noel