Re: [Hipsec] Comments on 5201-bis-02

Miika Komu <mkomu@cs.hut.fi> Sun, 04 July 2010 10:12 UTC

Return-Path: <mkomu@cs.hut.fi>
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 B0FBD3A688D for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 03:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level:
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 ReGxFQQi8Oad for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 03:12:30 -0700 (PDT)
Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 70B333A67CF for <hipsec@ietf.org>; Sun, 4 Jul 2010 03:12:30 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.7] helo=[127.0.0.1]) by hutcs.cs.hut.fi with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.54) id 1OVMBY-00077p-MG for hipsec@ietf.org; Sun, 04 Jul 2010 13:12:29 +0300
Message-ID: <4C305E89.10208@cs.hut.fi>
Date: Sun, 04 Jul 2010 13:12:25 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.10pre) Gecko/20100422 Shredder/3.0.5pre
MIME-Version: 1.0
To: hipsec@ietf.org
References: <F303C95A-64E6-4383-8A5C-27F5CD0A23B5@cs.rwth-aachen.de> <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com>
In-Reply-To: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] Comments on 5201-bis-02
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: Sun, 04 Jul 2010 10:12:31 -0000

On 07/04/2010 10:14 AM, Pekka Nikander wrote:

Hi Pekka and Rene,

>> - 5.3.5 UPDATE
>> Since working on HIPL I am wondering why HIP only defines a single UPDATE packet. From the perspective of 5201, I can see a conceptually compelling argument behind this approach, as it allows for a general purpose packet for the transmission of maintenance information. However, most extensions using UPDATE that I know of (most noteworthy, ESP rekeying and mobility and multi-homing) require a 3-way message exchange to complete their corresponding task. The packets thereby have a specific order and each of them has specific semantics. Let's take mobility as an example:
>> 	(1) notify the peer of an address change,
>> 	(2) challenge the peer to confirm his new address, and
>> 	(3) satisfy the challenge.
>> Still, with the current specifications protocol developers are forced to distinguish between these 3 packets by checking the contained parameter combinations. This is, in my opinion, more complex than necessary and error-prone, especially, with respect to the extensibility of the HIP parameters that can be included in UPDATE packets. So, is there a reason that prevents us from specifying different maintenance packet types instead of a single one?
>
> The original idea was that UPDATEs would just be a "carrier" for upper level protocols, allowing upper level protocols to be mixed and matched on individual packets.  E.g. so that you could run a mobility exchange and ESP rekeying at the same time, with the same packets.  E.g.
>
>      A->B:  Notify address change
>      B->A:  Challenge address; Initiate ESP rekeying
>      A->B:  Send the challenge response; Continue ESP rekeying
>             etc.
>
> But since I haven't been involved in implementation efforts for the last N years, I don't know if the current implementations support such behaviour

the carrier statement is still valid but UPDATE but I doubt if it's 
utilized much. I think relabeling the UPDATE control headers would be ok 
even with simultaneous rekeying but please correct if I'm wrong. Seems 
like registration as defined in RFC5203 would work still nicely with 
relabeled UPDATEs.