[Hipsec-rg] Re: Native HIP API questions in the hipsec-rg meeting

[[e-mail] (Miika Komu)]

On Mon, 16 Aug 2004, Lars Eggert wrote:

> Miika,
>
> Miika Komu wrote:
> >>
> >>Lars Eggert:  Why are you binding to a src interface rather than
> >>address?
> >>
> >>Joe Touch:  Binding to interfaces doesn't make sense.  Interfaces have
> >>multiple IP addresses.  A single host identity must be able to bind to a
> >>particular IP address, for policy reasons.
> >
> > Actually, the binding is done on the source endpoint descriptor. The
> > resolver communicates the descriptor to the HIP module and associates it
> > with a (given) interface.
> >
> > The main motivation for preferring IP addresses instead of interfaces is
> > related to the probable life time of the identifiers. IP addresses are
> > more unstable than interfaces, so interfaces were preferred. It is still
> > possible to use a specific IP address by specifying the protocol family
> > (and prefix) of the IP address to the resolver.
> >
> > (Btw, usually client apps do not bind explicitly and server applications
> > bind to INADDR_ANY or IN6ADDR_ANY, so this question may not be so
> > important.)
> >
> > Other opinions? Does anyone think that using interfaces instead of
> > IP-addresses is a better approach? Or a no-go?
>
> now I'm confused. The slides in San Diego showed a binding from HITs to
> interfaces. Yet this email talks about binding HITs to IP addresses.
> Which is it? Were the slides in San Diego wrong?

Ah, you were not talking about binding to a socket (as in the bind system
call). But yes, the source HI is associated (bound) to an interface.

> The issue we raised in San Diego was that *nothing* in the current
> sockets API ever binds to interfaces. Everything binds to IP addresses.
> Even INADDR_ANY just means "any IP address."

Agree, but we're extending the sockets API anyway by introducing a
new namespace and a new layer. Why not go a step even further?

> A HIP API would do well to follow this approach. The reason is that an
> outgoing interface is determined for each packet independently based on
> a routing lookup at transmission time. Which means that when the routing
> table changes, implementations don't have to go through all bindings to
> change their interfaces.

Could you elaborate the last sentence (with an example perhaps)?

> Additionally, as Joe pointed out, interfaces can have aliases, and
> furthermore, those aliases may move from one interface to another during
> the lifetime of a connection. Binding to IP addresses instead of
> interfaces avoids all this update mess.

I have to admit that I haven't thought about interface aliases. Still, if
the interface alias changes, it creates an event that can be detected in
the HIP module. The HIP module can sort out the "mess".

But is it really a mess? By changing the alias, you could signal that "I
want to take all of my HIP connections from wlan0 to eth0 to get faster
connectivity". Can you provide a counter example?

> > Another question to all: do you prefer "endpoint descriptors" instead
> > of HITs as the AID and why?
>
> Are there other kinds of endpoint descriptors than HITs? If yes, use the
> generic term. If no, just use "HITs" to be clear. (My two cents.)

Yes there is in native HIP API proposal. The endpoint descriptor is the
userspace AID and it acts like a "handle" or "reference" to the
corresponding HI. For the application, the descriptor seems like a random
number, but the HIP module knows the mapping from the descriptor value to
the HI.

One motivation for the endpoint descriptor is to separate application
layer identifiers from the transport layer identifiers. Seems like reusing
the same identifiers in each layer gets us into trouble always when the
networking requirements change; recall that HIP is trying to solve the
problem where the transport layer reuses the network layer identifiers
thus making mobility/multihoming difficult to achieve. Native HIP API
tries to avoid falling into the same pitfall.

See sections 4.1.1-4.1.4 from the API design chapter:

http://hipl.hiit.fi/hipl/hip-native-api-snapshot-20040708.pdf

> >>Andrew McGregor:  Agree about not binding to an interface.  You may want
> >>to bind to a HIT and use a setsockopt() to associate a locator with it.
> >
> > Resolver does the setsockopt() on the behalf of the user. The difference
> > is that the HI-to-IP mapping is "global" instead of socket specific. The
> > security issues are dealt by tagging the mapping with the UID and GID.
>
> I don't recall Andrew's exact question, and the above doesn't mean
> anything to me. Could you please elaborate?

Hmm... maybe Andrew misunderstood too the bind() vs. association. I was
not in the meeting, so I was guessing Andrew's thoughts... Andrew?

-- 
Miika Komu              [e-mail]          http://www.iki.fi/miika/