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

[[e-mail] (Andrew McGregor)]

--On Wednesday, 18 August 2004 12:25 a.m. +0300 Miika Komu 
<[e-mail]> wrote:

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

Think about a wireless host that is doing mesh routing on several 
interfaces.  Route persistence will be very short, and sometimes a 
neighbour will change adjacency.  Therefore the outgoing interface is going 
to change.  Often.  Like, perhaps every couple of seconds.

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

Interfaces can be transient, for instance I have a system that brings up 
and tears down tunnels on a regular basis.  At least most of the time, the 
default route is over one of those tunnels.  To which do I bind by default?

As well, the subnet containing the other endpoint of those tunnels is host 
routed by AODV and the routes get updated frequently (sometimes route 
persistence is only a couple of seconds).  The outgoing interface may 
change.  To which interface do I bind now?

Binding (either in the bind() sense or in the associate sense) to an 
interface just does not make sense.  An endpoint descriptor should be 
associated with either an IP address (in which case we presume that it is 
short lived, static, being handled by tunneling or MobileIP, or in another 
way not a problem) or an HI (in which case it is not a problem either).

A system process, not necessarily the resolver, should then maintain the 
HI/locator associations.  This requires an API of its own, one that an 
application should be permitted to use in the (hopefully rare) case that it 
needs to.

<snip>

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

My point was specifically about maintenance of HI to IP mappings, and Miika 
answered it fine.  I'd like to add: applications should be allowed to 
assert their own mappings (especially diagnostic tools, but things like web 
servers will frequently want to do this for application security reasons, 
just like they do with IP addresses now).

Andrew