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

[René Hummen <[e-mail]>]

Hi,

thanks for the already extensive list of research questions. I'll write down my thoughts inline.

On 29.07.2011, at 00:07, Tobias Heer wrote:
> * 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.

HIP was designed to be middlebox friendly. However, some aspects (such as draft-heer-hip-middle-auth) are still required for this statement to be true. Furthermore, there are still some interesting things that HIP can do for middleboxes. One rather obvious example is inbound connection establishment through HIP-aware NATs. Still, I have only found "draft-nikander-hip-nat-00 (to be issued)" with a quick Google search regarding this topic.

> Drafts on my mind are:
> - draft-lagutin-hip-pla
> - draft-heer-hip-middle-auth But there is other research in this are as well

IMO, some spec about secure state establishment for middleboxes is essential when talking about HIP-aware middleboxes. So, this is important to follow up on.

> - (Rene Hummen is working on related topics).

I am working on end-to-middle signaling mechanisms to improve middlebox services. The inbound NAT described above is a simple use case for these signaling mechanisms.

> - The femtocell presentation today also used HIP middleboxes as specified in
> draft-heer-hip-middle-auth

- HIP mobility with focus on middleboxes would be another important area. One question to ask here: How middlebox-friendly is the update process when NATs are located on the communication path?

> * 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 agree that these are very useful and interesting use cases for HIP. One thing that would be important to have, though, would be a sound analysis of the benefits of these approaches compared to existing solutions.

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

Seeing that HIP will probably not be the next big thing in the Internet, I think the right way to go is find niche markets for HIP. HIP in the infrastructure surely is one of these niches. Another one might be the embedded domain. So I strongly agree with this.

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

This is definitely worth following up on. I would also like to see some numbers in such a best-practices document, e.g., "If you want to use RSA certs with 2048 bit keys, you can only add them to R2 due to excessive size", etc. As we do not have a single "use certificates this way" document, we should avoid that we have to evaluate these numbers for each use case again.

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

I am missing one research area in your list, but I am not exactly sure which category it would belong to: draft-cao-hiprg-flow-mobility-00. This draft was presented by Zhen Cao in Prague. With flow mobility, end-hosts can decide which locators to use for communication on a per-flow instead of a per-association basis. Flow mobility could be generalized to hip-on-packet-flows (something I have been working on as well).

BR,
René



--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: [phone]
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/