Re: API, was: Question re HIP dependency & some architectural considerations

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

> > 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.
>
> Unfortunately, this way we also perpetuate the brokenness of the 
> current
> API philosophy.

Note, Iljitsch, that I was only referring to existing applications.
I didn't say anything about future or modified applications.
That I took as a separate point.

> > 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
>
> I forget what the A and E stand for...

A = Application, i.e., API level and inside applications
E = End-point (in the sense that Noel Chiappa and/or NSRG
    use/used the term)

> > This using of internal EIDs that are not IP addresses
> > in the protocol layer seems to offer an evolution path for the API.
>
> Another level of indirection?

Yes, two layers of indirection, in some sense.  AID -> EID -> IP.
In the initial case, for referrals etc, this is used so that
at the beginning of a multi6 association, AID = IP.  However,
understanding that _conceptually_ AID and IP are different things
paves way to API evolution, allowing one to change the nature
of AIDs as the infrastructure evolves.

> I don't think that's the solution.

I don't know whether that is _the_ solution or not, and I am
not arguing either for or against, in that sense.  However,
AFAIK, Tom et al at Boeing have implemented in their HIP code
that particular strategy, and it works.  Hence, it may
be _a_ solution.  It is to the WG to decide, later, what is
_the_ solution.

> > 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.
>
> Please define "use multihoming".

To me (and I may well be wrong), it looks natural for wedge/layer 3.5
solutions to maintain a host-to-host (or end-point-to-end-point)
state that is relatively independent on transport state.  That is,
such state is probably created on demand on first TCP connection
(or SCTP or UDP or ...) and it stays around some time after all
connections are known to be closed, just in case that there would be
more communication.

But, of course, that does not define "use multi-homing".  With
all respect, I refrain from defining it, as I was using it quite
loosely, on purpose.

> > If so, does the less-than-second delay caused by authenticated D-H 
> > really matter?
>
> Maybe yes, maybe no. I'm also worried about the CPU usage, BTW.

I agree with you that for some busy servers the CPU load might
be a concern.  Otherwise, I wouldn't be too worried.  Anyway, if
you are using authenticated D-H and you are only worried about
the relative security of your current session, you can choose to
use fairly short keys.

> The trouble with doing something right the first time is that nobody
> appreciates how difficult it was. - Walt West

Some people say that there there are two schools in CS in the US.
One is the MIT way, "do the right thing".  The other one is the
UCB way, "just do it".  I don't know whether the saying is true or
not.

In other words, I also see some value on incremental and partial
solutions.  Trying to do it right the first time, in a committee,
may well be pretty impossible.

--Pekka Nikander