Re: sockets APIs extensions for Host Identity Protocol

[Keith Moore <[e-mail]>]

>> 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?
yes, I think that would be appropriate.
>>>> 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
>

thanks, I'll take a look.
>>> 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.
yes, I think that's the term that was being used last time I heard it
mentioned.
>> 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.) 
if the sockaddr_hit structure contains only the HIT, how is the kernel
going to know where it can contact that peer?  It has to get one or more
IP addresses from somewhere. 

Keith