[Hipsec-rg] reverse DNS lookups of HITs

[miika.komu at hiit.fi (Miika Komu)]

Andrew McGregor wrote:

Hi,

> On 13/01/2009, at 11:21 PM, Oleg Ponomarev wrote:
> 
>> Hi! On Tue, 13 Jan 2009, Andrew McGregor wrote:
>>
>>>> I might have a mistaken view, but usually we only check the presence 
>>>> of the key in the list of authorized/known keys, so we do not need 
>>>> such a lookup.
>>>
>>> I think that was exactly the point... we don't need such lookups.
>>
>> ... for the SSH keys, when we have complete list of them in a file. 
>> This may be not the case for millions of host identities.
>>
>>> Personally, I think there is no need for reverse lookups.
>>
>> How many hosts use HIP in your network? I implemented this because I 
>> was irritated by [trimmed] hex sequences in the netstat output (for 
>> example). I prefer understandable names and also had reverse zones 
>> (locally) for RFC1918 addresses in another network with thousands of 
>> hosts which nobody could remember by heart.
> 
> Yes, that is a point.  However, it's also an implementation 
> limitation... if, for instance, your HIP implementation knows about 
> FQDNs sent by the other end, or certificate fields, it can arrange that 
> your reverse resolver library will say something sensible about the 
> host.  The resolver doesn't HAVE to use DNS to supply that information, 
> and given that HIP is a security binding protocol anyway, it makes more 
> sense to get this information from the current state of the bindings, 
> rather than by another insecure protocol outside of the current security 
> binding state.

(assuming I understood you correctly), there may be no HIP associations 
available that contain HIT-to-IP mapping information. So we can't always 
rely on that and I am not sure if it is a good idea to store the 
mappings permanently on disk available to the HIP daemon.