Re: sockets APIs extensions for Host Identity Protocol

[Miika Komu <[e-mail]>]

On Thu, 10 May 2007, Keith Moore wrote:

>> My exact question is that what to put into the socket address
>> structures when we have HIP-aware applications. Based on the
>> discussion, I think we can leave socket address structures based on
>> DNS names out of the scope and concentrate on two alternatives:
>> globally scoped HITs and locally scoped idenfiers (endpoint descriptors).
>>
>> The use of globally-scoped HITs has the following trade-offs:
>> + No extra translation step from local id to global id
>> + Smaller transition step to convert a legacy app to a HIP aware app?
>> - Opportunistic HIP mode, where the server's HIT is not known before
>> hand,
>>   will require a locally-scoped identifier anyway. This is similar to
>>   IN6ADDR_ANY, but it is used for the remote host, i.e.,
>>   connect(UNKOWN_HIT) where only the locator is known.
>> - No future proofing against the HIT size
>>
>> Locally-scoped identifiers have the reverse properties:
>> - Extra translation step from local id to global id
>> - Bigger transition step to convert a legacy app to a HIP aware app?
>> + All identifiers are of the same type (also in opportunistic HIP mode)
>> + Future proofing against changes in the HIT size
>>
>> If you had to choose between these two, what would you choose and why?
>> Do the proposed trade-offs make sense and would have something to add?
>
> 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).

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