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

Tobias Heer <heer@cs.rwth-aachen.de> Thu, 28 July 2011 22:08 UTC

Return-Path: <heer@informatik.rwth-aachen.de>
X-Original-To: hiprg@ietfa.amsl.com
Delivered-To: hiprg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B862811E812A for <hiprg@ietfa.amsl.com>; Thu, 28 Jul 2011 15:08:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Level:
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 61OJh1+I5V+1 for <hiprg@ietfa.amsl.com>; Thu, 28 Jul 2011 15:08:01 -0700 (PDT)
Received: from mta-1.ms.rz.rwth-aachen.de (mta-1.ms.rz.RWTH-Aachen.DE [134.130.7.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6144211E807E for <hiprg@irtf.org>; Thu, 28 Jul 2011 15:08:01 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ironport-out-1.rz.rwth-aachen.de ([134.130.5.40]) by mta-1.ms.rz.RWTH-Aachen.de (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <0LP200D18DHBW470@mta-1.ms.rz.RWTH-Aachen.de> for hiprg@irtf.org; Fri, 29 Jul 2011 00:07:59 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.67,284,1309730400"; d="scan'208";a="127598921"
Received: from relay-auth-2.ms.rz.rwth-aachen.de (HELO relay-auth-2) ([134.130.7.79]) by ironport-in-1.rz.rwth-aachen.de with ESMTP; Fri, 29 Jul 2011 00:07:59 +0200
Received: from [192.168.3.4] ([unknown] [91.179.190.134]) by relay-auth-2.ms.rz.rwth-aachen.de (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <0LP200AP2DHAPN00@relay-auth-2.ms.rz.rwth-aachen.de> for hiprg@irtf.org; Fri, 29 Jul 2011 00:07:59 +0200 (CEST)
From: Tobias Heer <heer@cs.rwth-aachen.de>
Date: Fri, 29 Jul 2011 00:07:58 +0200
Message-id: <48A70FBD-6BF5-458D-9932-0E431938473F@cs.rwth-aachen.de>
To: hiprg@irtf.org
X-Mailer: Apple Mail (2.1084)
Subject: [hiprg] Starting a list of RG topics of importance/interest
X-BeenThere: hiprg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Host Identity Protocol \(HIP\) Research Group" <hiprg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hiprg>, <mailto:hiprg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/hiprg>
List-Post: <mailto:hiprg@irtf.org>
List-Help: <mailto:hiprg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hiprg>, <mailto:hiprg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 22:08:02 -0000

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

* 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


* 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


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

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.

Cheers,
Tobi



 
 
-- 
Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
web: http://www.comsys.rwth-aachen.de/team/tobias-heer/
blog: http://dtobi.wordpress.com/
card: http://card.ly/dtobi
pgp id: AEECA5BF