[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