Re: [hiprg] Starting a list of RG topics of importance/interest

Miika Komu <> Mon, 01 August 2011 06:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F0921F8557 for <>; Sun, 31 Jul 2011 23:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.205
X-Spam-Status: No, score=-5.205 tagged_above=-999 required=5 tests=[AWL=1.395, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id uBFwP5D5Ui5O for <>; Sun, 31 Jul 2011 23:04:18 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BBFBC21F8556 for <>; Sun, 31 Jul 2011 23:04:17 -0700 (PDT)
Received: from ([] helo=[]) by with esmtp (Exim 4.54) id 1Qnlbx-0001Ot-7p for; Mon, 01 Aug 2011 09:04:21 +0300
Message-ID: <>
Date: Mon, 01 Aug 2011 09:04:32 +0300
From: Miika Komu <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110617 Thunderbird/3.1.11
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [hiprg] Starting a list of RG topics of importance/interest
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Aug 2011 06:04:18 -0000


On 07/29/2011 01:07 AM, Tobias Heer wrote:
> Hi.
> Lars raised the question whether there are still enough research questions left
> to justify a rechartering of the HIPRG. I took this as a reason to classify
> some of the _ongoing_ efforts into four different research areas. These
> research areas have been explored partially but by individual problem solutions.
> There were drafts within each area but none was adopted as RG item because at
> the time being there were already other issues (RG items) to be addressed. Maybe
> this description can be the basis for formulating a future research agenda. If
> not it may at least show current research efforts in the context of HIP. This
> collection is just an initial proposal. Add your own topics of interest to it or
> change and extend this list in a reply to the list.
> * HIP interaction with middleboxes
> HIP can be a burden or a big advantage for middleboxes. In the last 2 years
> we've seen quite some proposals to enable secure signaling to middleboxes and
> inclusion of middleboxes in the HIP communication flow to enable different goals
> ranging from security to mobility and ease of deployment. With stronger focus
> on these things, the RG could help to channel the individual efforts into a
> coherent and complete analysis and could foster the creation of comprehensive
> solutions.
> Drafts on my mind are:
> - draft-lagutin-hip-pla

I have to ask Lagutin of his interest in continuing this work. Samu has 
had earlier some interest in finishing an implementation of this.

> - draft-heer-hip-middle-auth But there is other research in this are as well
> - (Rene Hummen is working on related topics).
> - The femtocell presentation today also used HIP middleboxes as specified in
>    draft-heer-hip-middle-auth

I believe this is important. +1

> * HIP as part of the infrastructure
> There are a number of drafts and papers that use HIP within the network to
> connect different networks and to create VPN-like network overlays. People have
> presented quite some ideas within the RG and the RG could be a place to moderate
> and align these efforts.
> Ongoing work in this area:
> - draft-henderson-hip-vpls
> - HIP and femtocell technology
> - We have a similar solutions under development at RWTH in the context of the
>    Mobile ACcess project (there were presentations in Beijing and Anaheim)
> - I guess Mobile Router would also fit in here

I believe the VPLS is a nice use scenario of HIP. +1

I have to check the femtocell presentation, sounds interesting too.

> * HIP derivates for application specific use cases
> The RFID and the DEX documents are two siblings or offsprings of HIP that target
> specific scenarios. Nevertheless, these protocols share a common set of
> features and ideas. Right now these protocols are completely separate but I had
> discussions with Bob and Pascal and we agreed that some sort of interoperability
> would be good or even required. However, creating interoperability of these
> protocols is more than just defining conversion rules because some essential
> differences remain. An interesting question for me is how we can create that
> _family_ of interoperable HIP protocols that Bob envisioned. What are the
> requirements for new family members?  Which mechanisms (in standardization and
> protocol design) are required to achieve a maintainable and evolvable set of
> protocols.
> Documents:
> - draft-moskowitz-hip-rg-dex
> - draft-irtf-hiprg-rfid
> - current efforts with the IEEE and IoT-related groups

+1 for the interoperability concerns. I think some small things could be 
adopted to RFC5201bis as well if it makes the protocol more flexible.

> * HIT and ORCHID design.
> How can we enable hierarchies within the flat HIP namespace to make things like
> revocation and HIP/IP resolution simpler. This may sound easy at a first glance
> but there are some tough decisions to make: How many bits can we sacrifice to
> encode a hierarchy in a HIT. Are there smart ways of avoiding security
> penalties?  Can we use techniques to strengthen the security of the HIT (e.g.,
> similar to CGAs). Are we even moving towards CGAs?  How do hierarchies affect
> other mechanisms in HIP (e.g., cipher negotiation in RFC5201-bis)? How can we
> manage and use these hierarchies?
> Related documents:
> -draft-xu-hip-hierarchical

While I believe its feasible for HIP to co-exist without hierarchies, I 
think this is important as well. Interoperability (and cryptoagility?) 
needs to be considered again because now there's hierarchical and 
non-hierarchical HITs.

> * Use cases for HIP certificates
> The definition of HIP certificates deliberately excludes the specification of
> specific use cases. However the certificates were mentioned in quite many
> presentations in the past. Hence, scenario dependent and scenario independent
> methods to generate and handle certificates are still largely undefined and
> unaligned. It would be great if the RG could collect different use cases and
> condense these in a "best-practices" or "use-cases" document. In addition,
> mechanisms to signal that certificates are required need to be defined. As
> these are not part of the minimal set of features required for HIP, I assume
> that the RG is a good place to bootstrap such work.
> - draft-heer-hip-service
> - draft-henderson-hip-vpls
> - draft-pellikka-hiprg-certreq
> - HIP and femtocell technology
> - I have seen certificates pop up in some other places here and there


> There may be more research and problem areas that I missed. There may also be
> additional documents, papers and drafts that I did not mention here. If so, it
> would be great if people could extend this list.