Subject: Re: [hiprg] Putting HIP on a Diet

From: [email-masked] (Noel Chiappa)
Date: Mon, 17 May 2010 13:32:56 -0400 (EDT)

> From: Robert Moskowitz <[email-masked]>

    > 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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 18 May 2010 10:31:26 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Noel Chiappa
> Sent: Monday, May 17, 2010 10:33 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [hiprg] Putting HIP on a Diet
>

I agree, and while it would be fine to work the protocol specifics in the research group (since the proposed WG charter doesn't include this for now), I think that the basic question above should be covered in RFC4423bis.  I would support the latter interpretation (that HIP is (potentially) a protocol family built around the concept of a namespace for IP stacks).

- Tom

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 18 May 2010 13:53:55 -0400

On 05/18/2010 01:31 PM, Henderson, Thomas R wrote:
>>      >  From: Robert Moskowitz<[email-masked]>
>>

I will move HIP DEX discussions over to HIP-RG.

Drat it :)