Subject: [Hipsec-rg] Hope to get your comments
From: zhangdacheng at huawei.com (Zhang Dacheng)
Date: Sun, 31 May 2009 22:46:25 +0800

Hello everyone:
 
I amd Dacheng, from huawei ltd. I and my colleague, Xiaohu Xu, propose two
drafts in HIP. The details are listed as follows:
 
Filename:  draft-zhang-hip-hi-revocation
Revision:  00
Title:   Host Identifier Revocation in HIP
Creation_date:  2009-05-27
WG ID:   Independent Submission
Number_of_pages: 8
 
Abstract:
This document mainly analyzes the key revocation issue with host identities
(HI) in the Host Identity Protocol (HIP), which has not attracted enough
attention from HIP community yet. As a core component of key management
mechanism, key revocation is critical for security systems especially which
are expected to execute for a long period. Apart from that, this document
also discusses the possible challenges that the designers of HI revocation
mechanisms have to face and introduces several possible solutions.
 
http://www.ietf.org/internet-drafts/draft-zhang-hip-hi-revocation-00.txt
 
Filename:  draft-zhang-hip-hierarchical-parameter
Revision:  00
Title:   Extensions of Host Identity Protocol (HIP) with Hierarchical
Information
Creation_date:  2009-05-27
WG ID:   Independent Submission
Number_of_pages: 10
 
Abstract:
This document briefly introduces the benefits brought by extending the Host
Identity Protocol (HIP) with hierarchical information. In addition, two
hierarchical extensions of HIP are introduced. The first one aims to
transport hierarchical information in a parameter of the HIP header, while
the second one extends DNS resource records in order to contain hierarchical
information.  
 
http://www.ietf.org/internet-drafts/draft-zhang-hip-hierarchical-parameter-0
0.txt

 
It will be very nice if we can get your kindly comments, and looking forward
to your replies.
 
Best Regards
 
Dacheng Zhang

From: miika.komu at hiit.fi (Miika Komu)
Date: Fri, 08 May 2009 22:11:36 +0300
Subject: [Hipsec-rg] Forward Confirmed reverse DNS & HIP dns proxy
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Message-ID: <[email-masked]>

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.