Re: [hiprg] Putting HIP on a Diet (Noel Chiappa) Mon, 17 May 2010 17:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2F1A73A6872 for <>; Mon, 17 May 2010 10:33:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.298
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cdWtgearwsFE for <>; Mon, 17 May 2010 10:33:12 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 340AA3A6783 for <>; Mon, 17 May 2010 10:33:05 -0700 (PDT)
Received: by (Postfix, from userid 11178) id 798446BE575; Mon, 17 May 2010 13:32:56 -0400 (EDT)
Message-Id: <>
Date: Mon, 17 May 2010 13:32:56 -0400
X-Mailman-Approved-At: Mon, 17 May 2010 10:41:41 -0700
Subject: Re: [hiprg] Putting HIP on a Diet
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 17 May 2010 17:33:12 -0000

    > From: Robert Moskowitz <>

    > 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

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

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.