Re: [hiprg] Putting HIP on a Diet

[[e-mail] (Noel Chiappa)]

    > From: Robert Moskowitz <[e-mail]>

    > 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