[Hipsec-rg] Forward Confirmed reverse DNS & HIP dns proxy

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

Oleg Ponomarev wrote:

Hi,

> Hi!
> 
> It is not implementation-specific, so I move the discussion to this 
> mailing list? We stumbled across such a question: if a host has both HIP 
> and non-HIP connections and uses a HIP DNS proxy for the legacy 
> applications.
> 
> There is an incoming connection from 2001:708:140:220::2, it is resolved 
> to hipl.infrahip.net, then hipl.infrahip.net has a HIP RR and gets 
> resolved to 2001:19:c0ff:5d7e:d547:ec9b:37c3:44c6 (via DNS proxy) 
> instead of 2001:708:140:220::2. The forward-confirmation is broken and 
> there are warnings about possible attacks and so on.
> 
> Has this trouble been discussed before? Do you have any ideas?
> 
> One way would be to resolve:
> 
> 2001:708:140:220::2 -> hipl.infrahip.net.NOHIP.
> hipl.infrahip.net.NOHIP. -> 2001:708:140:220::2 hipl.infrahip.net. -> 
> 2001:19:c0ff:5d7e:d547:ec9b:37c3:44c6
> 
> There would be no warning about FCrDNS, but an ACL for 
> hipl.infrahip.net. would not apply either.

"how to solve this" is a good question. Another question is "what's the 
impact". The constraints that limit the impact are i) the hosts have 
both HIP and non-HIP connections to each other and ii) both hosts 
establish connections to each other. It would be interesting to try to 
list applications that behave in such manner.

Alternative solutions to the problem is to track pid numbers (or some 
other DNS query related numbers) or use timeouts (exclude hits after n 
milliseconds after the reverse query). However, such approaches are not 
reliable and I like your suggestion better.