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

[Miika Komu <[e-mail]>]

Hi,

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

+1

> 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.