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

[[e-mail] (Miika Komu)]

Some question were raised in the hipsec-rg meeting in San Diego and I'd
like comment them briefly:

> 2.  HIP Native API (Julien Laganier)
>
> Lars Eggert:  Why are you binding to a src interface rather than
> address?
>
> Julien:  Ask Miika for motivation.
>
> 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?

Another question to all: do you prefer "endpoint descriptors" instead
of HITs as the AID and why?

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

> Tim Shepard:  What if no DNS?  Nervous about building in dependencies on
> DNS.
>
> Julien:  use /etc/hosts.  Can fall back to opportunistic mode too.

The other alternative for DNS is the DHT, but it remains to be seen if we
ever get there. In the mean time, we should rely on DNS, as there are no
real alternatives currently available.

Maybe the resolver should should support DHT queries too. With a new
resolver, this should not be a problem. I'll have to look at this topic
when I get my hands on a DHT DNS replacement implementation...

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