Re: [Hipsec] Draft: data transport in HIP
"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Thu, 31 July 2008 17:26 UTC
Return-Path: <hipsec-bounces@ietf.org>
X-Original-To: hip-archive@lists.ietf.org
Delivered-To: ietfarch-hip-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9CFBF28C2A2; Thu, 31 Jul 2008 10:26:20 -0700 (PDT)
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 D1B4628C2A2 for <hipsec@core3.amsl.com>; Thu, 31 Jul 2008 10:26:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Yp9UwVU32ue6 for <hipsec@core3.amsl.com>; Thu, 31 Jul 2008 10:26:19 -0700 (PDT)
Received: from stl-smtpout-01.boeing.com (stl-smtpout-01.boeing.com [130.76.96.56]) by core3.amsl.com (Postfix) with ESMTP id DB35528C23F for <hipsec@ietf.org>; Thu, 31 Jul 2008 10:26:18 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.14.0/8.14.0/8.14.0/SMTPOUT) with ESMTP id m6VHQFbJ016403 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Jul 2008 12:26:20 -0500 (CDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.0/8.14.0/DOWNSTREAM_RELAY) with ESMTP id m6VHQEv4016129; Thu, 31 Jul 2008 10:26:15 -0700 (PDT)
Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.14.0/8.14.0/UPSTREAM_RELAY) with ESMTP id m6VHQ6FO015831; Thu, 31 Jul 2008 10:26:14 -0700 (PDT)
Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 31 Jul 2008 10:26:09 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Thu, 31 Jul 2008 10:26:08 -0700
Message-ID: <77F357662F8BFA4CA7074B0410171B6D07B0B721@XCH-NW-5V1.nw.nos.boeing.com>
In-Reply-To: <4891E56F.2010405@ericsson.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [Hipsec] Draft: data transport in HIP
Thread-Index: AcjzKNv8P+jSsTj5QQCGPRKGMj4+1QABVxUw
References: <48906773.8000501@ericsson.com> <77F357662F8BFA4CA7074B0410171B6D07B0B71D@XCH-NW-5V1.nw.nos.boeing.com> <4891E56F.2010405@ericsson.com>
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
X-OriginalArrivalTime: 31 Jul 2008 17:26:09.0195 (UTC) FILETIME=[8564CFB0:01C8F332]
Cc: "Pekka Nikander (JO/LMF)" <pekka.nikander@ericsson.com>, HIP <hipsec@ietf.org>, Jan Melen <jan.melen@ericsson.com>
Subject: Re: [Hipsec] Draft: data transport in HIP
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/pipermail/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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: hipsec-bounces@ietf.org
Errors-To: hipsec-bounces@ietf.org
> -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com] > Sent: Thursday, July 31, 2008 9:17 AM > To: Henderson, Thomas R > Cc: HIP; Pekka Nikander (JO/LMF); Jan Melen > Subject: Re: [Hipsec] Draft: data transport in HIP > > Hi Tom, > > the idea with this draft is the following: > > o define a HIP DATA packet as discussed in the past. > o discuss the trade offs involved in the use of this packet. We gain > efficiency but lose DoS protection. > o discuss under which circumstances implementations may want > to use DATA > and also under which circumstances an implementation wants to > accept or > reject DATA (e.g., in some cases, an application that is part of a > trusted overlay may want to accept DATA). > o when an implementation does not want to accept DATA (e.g., > because of > DoS concerns), it needs to be able to return an R1 to start a base > exchange instead. > > > The reason why, at this point, the document does not spend > time defining > DATA is because we wanted to stress the importance of the > discussions > on why it is appropriate to use such a mechanism. We will be > introducing > the definition of DATA in future revisions of the draft. I wasn't suggesting to spend time defining DATA now, but to define how the user of DATA perceives the service that DATA provides. The HICCUPS draft briefly states what is the purpose of this service-- to provide carriage of signaling messages between hosts, while solving for the signaling protocol all of the details of NAT traversal, mobility, multihoming. This, to me, would be clearly a nice service to provide, and I don't know how much more you need to justify it. However, there are a lot of details that need to be resolved, such as: - what are the delivery semantics (reliable, unreliable) of such messages? - what are the security semantics? From a server perspective, should application be able to select a listening service that uses base exchange or not, or should that detail be hidden from the signaling application? Can/should applications specify what source HIT should be used? Should applications be able to provide or load their own host identity? Should opportunistic mode be supported, and how is this mode controlled? - can applications use this service by providing a URL or by providing only a destination HIT? - does the application provide hints as to which overlay the destination HIT has stored its bindings? - what kind of other policy can an application flow down to the HIP daemon, and how is it communicated at the API? - do locators (addresses) play any role at the API level? - what kind of error codes are provided back to the signaling applications? I don't think we can fully specify DATA until we understand how the above questions are answered. > > With respect to the API, we decided to wait with the API > draft until the > NAT traversal and overlay work is in a more advanced state so that we > have a clearer picture on the requirements for a HIP API. > Yes, these issues (overlay, native API, HICCUPS) are all bound together, but I think that to move forward on the protocol details, we first have to have a clear vision as to what is the service API we are trying to support. Regards, Tom _______________________________________________ Hipsec mailing list Hipsec@ietf.org https://www.ietf.org/mailman/listinfo/hipsec
- [Hipsec] Draft: data transport in HIP Gonzalo Camarillo
- Re: [Hipsec] Draft: data transport in HIP Henderson, Thomas R
- Re: [Hipsec] Draft: data transport in HIP Gonzalo Camarillo
- Re: [Hipsec] Draft: data transport in HIP Henderson, Thomas R
- Re: [Hipsec] Draft: data transport in HIP Gonzalo Camarillo
- Re: [Hipsec] Draft: data transport in HIP Henderson, Thomas R
- Re: [Hipsec] Draft: data transport in HIP Gonzalo Camarillo