[Hipsec] Overlay work: status and request for input
Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Mon, 20 July 2009 10:54 UTC
Return-Path: <gonzalo.camarillo@ericsson.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81EE3A68FF for <hipsec@core3.amsl.com>; Mon, 20 Jul 2009 03:54:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.099
X-Spam-Level:
X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUzYkcWEDvE3 for <hipsec@core3.amsl.com>; Mon, 20 Jul 2009 03:54:34 -0700 (PDT)
Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 37B793A659B for <hipsec@ietf.org>; Mon, 20 Jul 2009 03:54:33 -0700 (PDT)
X-AuditID: c1b4fb3e-b7bf5ae000000202-48-4a6447e0d74c
Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id C5.40.00514.0E7446A4; Mon, 20 Jul 2009 12:33:04 +0200 (CEST)
Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 12:33:02 +0200
Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 12:33:01 +0200
Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 345502461; Mon, 20 Jul 2009 13:33:01 +0300 (EEST)
Message-ID: <4A6447DC.7070005@ericsson.com>
Date: Mon, 20 Jul 2009 13:33:00 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: HIP <hipsec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 20 Jul 2009 10:33:01.0559 (UTC) FILETIME=[750B3870:01CA0925]
X-Brightmail-Tracker: AAAAAA==
Subject: [Hipsec] Overlay work: status and request for input
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Jul 2009 10:54:35 -0000
Folks, here you have a summary of the status of the overlay work. Additionally, we have some questions for the WG related to our milestones and their related charter items. Your input on those questions is very welcome. 1) We have the following milestone: "Specify a framework to build HIP-based overlays. This framework will describe how HIP can perform some of the tasks needed to build an overlay and how technologies developed somewhere else (e.g., a peer protocol developed in the P2PSIP WG) can complement HIP by performing the tasks HIP was not designed to perform." The WG item for this milestone is the following draft, which should be ready for WGLC: http://tools.ietf.org/id/draft-ietf-hip-bone-02.txt This draft defines a high-level framework to build HIP-based overlays. Additionally, its previous version defined how to build a HIP-based overlay using RELOAD. The authors have chosen to move this definition to a separate document because while the high-level framework is informational in nature, the definition makes use of normative language. The resulting document is the draft below. We would like to ask the WG if it is OK to split our current milestone in two so that they cover the high-level framework and the definition in separate documents. http://tools.ietf.org/internet-drafts/draft-keranen-hip-reload-instance-00.txt Additionally, we would like to ask the WG if we should take the draft above as the WG item associated to the milestone for the definition. 2) We have the following milestone: "Specify how to carry upper-layer data over specified HIP packets. These include some of the existing HIP packets and possibly new HIP packets (e.g., a HIP packet that occurs outside a HIP base exchange)." We still do not have a WG item for it but the following draft has been around for some time. We would like to ask the WG if we should adopt the following draft as the WG item for this milestone. http://tools.ietf.org/internet-drafts/draft-nikander-hip-hiccups-02.txt Revision 02 of the draft above is identical to 01 (the only changes are the date and the new copyright). The authors intend to address the comments received on the list shortly. 3) In order to be able to support the functionality provided by RELOAD, HIP needs to support multi-hop routing. Instead of specifying it in the HIP BONE draft, having a separate draft seem to make more sense given that this functionality has a more general applicability than overlays. We would like to ask the WG if we should spin off a new milestone from our original milestone for overlays that covers multihop routing in HIP. The following draft takes a stab at specifying multihop routing in HIP. We would like to ask the WG if we should adopt it as a WG item for the milestone above (assuming we decide to create the milestone). http://tools.ietf.org/internet-drafts/draft-camarillo-hip-via-00.txt 4) We have the following milestone: "Specify how to generate ORCHIDs from other node identifiers including both cryptographic ones (leading to cryptographic delegation) and non-cryptographic ones (e.g., identifiers defined by a peer protocol)." When we created that milestone, we expected to have a generic mechanism to transform node IDs into ORCHIDs. However, at this point, it seems that such transformation will be done in different ways depending on the peer protocol used in a particular overlay. For example, the instance specification for RELOAD draft defines such transformation for RELOAD peer identifiers. The fact that nobody has submitted a draft for that milestone seems to confirm the previous impression. We would like to ask the WG if we should remove that milestone from our charter. Thanks, Gonzalo HIP co-chair
- [Hipsec] Overlay work: status and request for inp… Gonzalo Camarillo
- Re: [Hipsec] Overlay work: status and request for… Henderson, Thomas R
- Re: [Hipsec] Overlay work: status and request for… Gonzalo Camarillo
- [Hipsec] Comments on the HIP-BONE draft Gonzalo Camarillo
- Re: [Hipsec] Comments on the HIP-BONE draft Henderson, Thomas R
- Re: [Hipsec] Overlay work: status and request for… Ari Keranen
- Re: [Hipsec] Comments on the HIP-BONE draft wangjun
- Re: [Hipsec] Comments on the HIP-BONE draft Ari Keranen
- Re: [Hipsec] Comments on the HIP-BONE draft Ari Keranen
- Re: [Hipsec] Comments on the HIP-BONE draft wang.jun17
- Re: [Hipsec] Comments on the HIP-BONE draft Henderson, Thomas R
- Re: [Hipsec] Overlay work: status and request for… Petri Jokela
- Re: [Hipsec] Comments on the HIP-BONE draft Ari Keranen
- Re: [Hipsec] Comments on the HIP-BONE draft Ari Keranen
- Re: [Hipsec] Overlay work: status and request for… Tobias Heer
- Re: [Hipsec] Overlay work: status and request for… Miika Komu
- Re: [Hipsec] Overlay work: status and request for… Varjonen Samu
- Re: [Hipsec] Overlay work: status and request for… Miika Komu
- Re: [Hipsec] Overlay work: status and request for… Jan Melen
- Re: [Hipsec] Overlay work: status and request for… Varjonen Samu