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

On 26-jul-04, at 12:38, Pekka Nikander wrote:

> b) Secondly, it starts to look like that we really should start to
> think about the API issues more seriously.

Yes. Hence the call for apps feedback earlier.

> 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.

What I'd like to see is a dual track approach: we do what we can to 
support multihoming for existing IPv6 applications, and we also create 
new, less limited ways to do the same and more.

By also allowing identifiers that aren't routable IPv6 addresses, our 
stuff is much more powerful and futureproof. This means we need some 
more type fields and make some more stuff variable length, but that's 
not very hard. However, security is harder for nonroutable identifiers. 
I don't think we necessarily want to solve that, but if we can create 
hooks for solving this in user space then this is quite easy to add 
later on. (The same way that IPsec needs kernel support for some of its 
stuff but the Racoon IKE daemon is basically a user-level process.)

> 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...

> 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?

I don't think that's the solution. The problem is that applications see 
values that they think are IP adddresses. The first order of business 
is removing the assumption that these are actual IP addresses. This 
can't be done by adding stuff lower in the stack.

> 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". If this means once when ISPs are 
connected or once a day or something like that, that's very different 
from having to do it for every TCP session.

> 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?

The users want to control multihoming, having the application 
specifically ask for it is probably unworkable.

> 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.

At this juncture, I'll observe that we have T/TCP (TCP for 
transactions) which pretty much eliminates the delay caused by the TCP 
three way handshake, but T/TCP is often badly implemented, and, as far 
as I can tell, extremely rarely used. Same goes for HTTP session 
keepalive/reuse.

> 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.

I'm not worried about this kind of "complexity". Having a bunch of 
simple things is "complex" but workable. It's having a single thing 
that is hard to understand, or a buch of things that interact in 
complex ways that cause problems.

> 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?

How many different implementations of this kind of stuff are there 
going to be? 10? 25? 100? And how much time is the human race going to 
lose by having to wait for 50 ms for EVERY new session on EVERY 
computer for the next 20 years?

It seems to be in vogue to publish half baked products and then clean 
up the mess later, but nobody ever got fired for getting it right the 
first time...

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