Re: Question re HIP dependency & some architectural considerations

[Catching up e-mail]

Brian and others,

>> Some discussion on this thread refers to dependency on HIP.
>> Question to the WG: given the current state of HIP, do we
>> want to consider dependency on HIP as
>> a) acceptable
>> b) unacceptable?
>>   Brian (co-chair hat on)
>
> There really wasn't much response to this one, but my reading of the
> sparse consensus was against solutions that depend on the deployment
> of HIP (but that does not exclude taking ideas or components of HIP).

Personally, and as far as I understand the goals for multi6, I don't
think that HIP -- as it is currently being defined -- fulfils the
multi6 goals.  (Some people claim that none of the other solutions on
the table do that either; I refrain to comment since I am too far back
in reading the drafts.)  But anyway, if I do understand your question
correctly, IMHO it is "unacceptable" to "depend" on HIP.

However, I do believe that HIP has a number of components and ideas
that could, if so desired, be reused for the multi6 solution.  I also do
believe that it is possible, again if so desired, to make the eventual
multi6 solution "forward compatible" with HIP.  The latter would
probably required some changes to HIP, but I don't see that as a 
problem.
Anyway, I believe that HIP will necessarily undergo a number of 
incompatible
changes from Experimental to PS, if it ever gets that far.

More importantly, there are a number of important architectural issues
lurking here behind.  These relate to
   a) the nature of EIDs
   b) API evolution
   c) performance penalty and nature of multi-homed applications

a) Firstly, HIP is not only about id/loc split, and
thereby facilitating end-host mobility and multi-homing.  It is also
about moving from using "ordinary" non-crypto-based identifiers towards
using cryptographically strong identifiers, i.e., public keys.
 From an architectural point of view, one can consider this as a
potentially far more important change than moving from IPv4 to IPv6.
This is one of the primary reasons why I do believe that HIP warrants
development of its own, independent of multi6, mobike, etc.

b) Secondly, it starts to look like that we really should start to
think about the API issues more seriously.  As an example, HIP does
support multiple different APIs (IPv4 LSI and IPv6 HIT based currently,
native HIP fairly soon).  Furthermore, it does support (limited)
application interoperability, i.e., simple applications can talk to
each other independent of the API they use.  At the HIP list, we have
been discussing about adding support for IPv6 non-HIT based API to this
list, but a security analysis of that solution is still to be seen.

Looking at the multi6 goals and recent discussion, it looks like that
any acceptable solutions MUST support unmodified IPv6 API, using
routable IPv6 addresses as API level identifiers.  Only that way we
can fully support all existing applications.

To me, it remains an interesting question how to support API evolution.
One architectural possibility would be to use HIP as an example:
  - convert AIDs into EIDs at the API level
  - use EIDs to establish the end-to-end context
  - map EIDs to IP addresses when sending packets out
and, of course, vice versa at the receiving end.  This using of internal
EIDs that are not IP addresses in the protocol layer seems to
offer an evolution path for the API.  (See also the HIP architecture
draft, draft-moskowitz-hip-arch-06.txt, Section 4.1.  Badly formatted,
sorry, but I was in hurry when submitting -06, and xml2rfc was changed.)

c) Thirdly, but perhaps less importantly, it looks like that we should
also take an architectural stance at the performance implications.
Some people seem to have an opinion that requiring one to perform an
authenticating D-H exchange each and every time one wants to use
multi-homing is unacceptable.  But is it really so?  If your application
needs the multi-homing benefits, doesn't that usually mean that it
expects to continue  communication over some time span?  If so, does the
less-than-second delay caused by authenticated D-H really matter?

Related to this, it does look like that we could develop a protocol
where the hosts have a very light weight piggybacked exchange
initially, with reasonable initial security and the possibility to
"upgrade" the context security into authenticated D-H level.  However,
such a protocol is inherently more complex than one where one
always performs authenticated D-H initially.

Hence, to me the question is whether the performance benefit from
the delayed state set up is really worth the added complexity, taking
the nature of multi-homed applications into consideration?

----

Just looking at the multi6 goals and things to think about is of
course right in the multi6 context.  However, to me the "larger"
questions about EID nature and API evolution are perhaps more
important.

--Pekka Nikander