Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Fri, 11 May 2007, Keith Moore wrote:

>
>>> I don't know why a HIP-aware app would use sockaddr_in* for any socket
>>> on which it wanted to use HIP.  Such an app might want to use
>>> sockaddr_in for some sockets if it had a reason to not use HIP on
>>> specific sockets.  (say for diagnostic purposes)
>>
>> Sorry, I meant sockaddr_in6 in this case.
>
> the same argument applies.  If I want to specify that I'm connecting to
> a HIT, I don't want to use a sockaddr_in6 structure to do that and have
> it somehow magically know the difference between a HIT and an IPv6
> address.  I want to use a sockaddr_hit structure for that.  That way, I
> get a clean separation of layers, with all that that implies - better
> ability to distinguish errors from different layers and handle each
> appropriately, clearer visibility to the programmer as to what's
> happening underneath the API, etc.

Ok. Would you be fine with having a new address family (AF_HIP) to 
separate between sockaddr_hip and sockaddr_in6?

>>> I must have missed the point of locally-scoped identifiers.  I thought
>>> it was so that you could fit a pseudo-HIT into 32 bits and pretend it
>>> was an IPv4 address for the sake of backward compatibility.
>>
>> Yes. There can be two types of "pseudo-HITs":
>>
>> Local Scope Identifier (HIP legacy apps draft):
>> * Looks like an IPv4 address
>> * Might even have a locally configured prefix to separate between a LSI
>>   and non-LSI address
>>
>> Endpoint descriptor (HIP native apps draft):
>> * Looks more like a FD (increasing or random number)
>> * No prefix
>
> I don't immediately see the purpose of the latter type of pseudo-HIT?
> (guess I should go dig up the draft...)

I don't see any reason to give HIP aware applications LSIs that 
look like IPv4 addresses but are actually presenting HITs. Here's also a 
couple of short slide sets:

http://www3.ietf.org/proceedings/05aug/slides/apparea-3.pdf
http://www3.ietf.org/proceedings/06jul/slides/hip-2.pdf

And some future research extensions for the endpoint descriptors:

http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Abstract.txt
http://kathrin.dagstuhl.de/files/Materials/06/06441/06441.KomuMiika.Slides.pdf

>>> But if your application was written to be HIP-aware, it would be
>>> cleaner to use HIP-specific sockaddrs.  And in that case, why use a
>>> locally-scoped identifier when you can use a globally-scoped one?
>>> (and if your application wasn't originally written to use HIP it's
>>> probably the case that the best you can hope for with small mods to
>>> your code is opportunistic HIP anyway.)
>>
>> Yes, but how to do opportunistic mode in a new application that wants
>> to use opportunistic mode for some connections and normal mode for
>> others?
>
> well, the setsockopt() mechanism for enabling opportunistic HIP that
> would be useful for modifying legacy apps could also be used for new apps.
>
> if you wanted to have a mechanism to do the same thing with
> sockaddr_hit, say by setting the HIT field to HIT_UNKNOWN or some such,
> that could be defined also.  though the details would be interesting to
> work out.

Ok.

>> One of reasons for the local-scope identifier was to hide the "which
>> HIT maps to which IP" complexity from the application. This does not
>> prevent the application rearranging the identifiers behind the
>> locally-scoped
>> identifiers using a separate function call.
>
> at this level of API, hiding the "which HIT maps to which IP" complexity
> seems misguided.   let the high-level API do that.  you need an API that
> exposes this stuff.

Right.

>> What kind of redirect servers are we talking about?
>
> I haven't keep track of the HIP discussions on this topic, so I don't
> know what they're being called.  but at one time there was an idea that
> you could have a server that could be associated with a HIT that would
> securely be updated with current IP addresses for that HIT, and which
> could securely tell peers of that HIT when the host associated with the
> HIT had moved.  (those servers would need to be located at relatively
> stable addresses).  you'd want to be able to discover those servers
> through DNS or a similar mechanism.

I think you are talking about rendezvous server that are similar to the 
home agents in MobileIP.

> we're a very long way from being able to trust a kernel to make
> effective address selection across a wide variety of network
> environments and application requirements.  until we get there, the
> addresses need to be exposed to the application, and the application
> needs to be able to specify which addresses are allowed to be used.  if
> nothing else, you're going to need that for diagnostics.  if some user
> tells his sysadmin that his program can't connect to HIT xxxx, the
> sysadmin has no way to know how to debug the problem.  if instead the
> message is "cannot connect to HIT xxxx at address yyyy", a traceroute to
> yyyy might yield some useful information.
>
> granted, however, that the sockaddr_hit structure can only communicate
> the IP addresses at which the peer with that HIT might initially be
> found.   once the connection is established, all assumptions about the
> HIT-to-IP bindings that were established in sockaddr_hit are invalid.

Are you fine with a sockaddr_hit structure that contains only the HIT and 
letting a getsockopt() call to figure out the IP addresses in the context 
of HIP aware applications? (I think getsockname and getpeername should 
return the HITs.)

-- 
Miika Komu                                       http://www.iki.fi/miika/