[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