Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Fri, 11 May 2007, Keith Moore wrote:

Hi Keith,

>>> offhand, I think you need to support both.  HITs aren't very useful to
>>> apps unless they are visible to them and globally-scoped.  HIP is still
>>> useful without HIT visibility, but less useful.
>>
>> It does not mean that the HIT fingerprint, or preferably even the
>> corresponding public key, are completely invisible to the application
>> with locally-scoped identifiers. It is just a question of an extra
>> function call that translates the local-scope identifier to the
>> desired format (HIT or public key).
>
> It strikes me that if I'm using opportunistic HIP, then I probably want
> to use normal sockaddr_in* structures and do a setsockopt() that says
> "give me HIP if both ends support it" before doing connect() or
> listen().  In that case I'd want getpeername() to still return the
> peer's (current) IP address, but I'd want additional functions to return
> the peer's HIT.  In that case I don't see any real value in having
> locally-scoped pseudo-HITs.  The reason for doing things this way is
> that it would require fewer changes to legacy code to support
> opportunistic HIP.

We have implemented opportunistic mode in the HIPL implementation in the 
way you described. It required some tricks under the sockets API hood to 
get it working, but it is great for legacy apps. Even referrals work, 
assuming that you are behind a NAT or a firewall :)

What about "native" HIP applications that are aware of HIP? The whole 
point of the locally scoped identifier was to provide single, unified 
end-point token to applications. Is it acceptable to handle both 
sockaddr_in and sockaddr_hip structures in HIP aware apps? I think a 
single identifier type would be simpler.

> OTOH, if I'm doing "real" HIP then I want to use something like a
> sockaddr_hip structure that lets me specify both the HIT (as the
> "address") and a variable number of IP addresses (including both IPv4
> and IPv6 addresses) at which the peer named by the HIT might be
> reachable (or at which a redirect to the actual peer might be
> obtainable).

The is certainly possible. One could also implement opportunistic mode by 
leaving out the HIT from sockaddr_hip and by specifying only the IP. 
However, there is an inherent problem with this approach as described 
below.

> And then you probably want a HIP-specific replacement for
> getaddrinfo() that will return not only addresses but also the HIT
> associated with a DNS name and whatever other information is useful in a
> form that's easily stuffed into a sockaddr_hip.

Why this can't be done in the current resolver by specifying a flag?

> really you want to be able to map a DNS name into multiple HITs, each of
> which can have zero or more IPv* addresses associated with it.... and
> you want a standard data structure that consists of a HIT + IP addresses
> that can be passed around in referrals.

The problem with this approach is that it will encourage developers to use 
the IP address directly from the socket address structure. The host 
corresponding to the HIT may have changed it's IP address at that point 
(independently of whether the structure describes the local or remote 
host). I believe that it is be much better to "force" the developer to 
obtain a valid IP address using a separate function call (see 
draft-ietf-shim6-multihome-shim-api). An extra call should not be a 
problem in a HIP aware application.

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