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

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
>
>     > 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 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 :)

---

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

> 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 b…

I am working on this wording being added to 4423-bis. I really think it 
captures my thoughts over the past 2 years on work being done with HIP 
RFID and HIP IOT. And now HIP DEX.

---

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

> From: Robert Moskowitz [mailto:[email-masked]]
> Sent: Tuesday, May 18, 2010 10:56 AM
> To: Henderson, Thomas R
> Cc: 'Noel Chiappa'; [email-masked]
> > 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).
>

I reread the intro to 4423(bis) just now and found myself thinking that it is really the discussion about the independent namespace for IP stacks, rather than the protocol exchange itself, that captures the essence of HIP.  For instance, section 4.1 of 4423 (now 3.1 of 4423-bis).  What aspects, if any, of this description of the namespace do not generally hold?  I might relax some text in the very last paragraph such as "Using Host Identities requires its own protocol layer, the Host Identity Protocol..." and "The names are based on public-key cryptography.." to instead read something like "One implementation of these ideas is based on the use of public/private key pairs as names and on a key management protocol called the Host Identity Protocol, but other implementations with the above properties may be possible..."

- Tom

---

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

> What is HIP? Is HIP the exchange we have now have and only that? Or is
    > 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