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