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

Jan Melen <jan.melen@nomadiclab.com> Tue, 06 July 2010 13:37 UTC

Return-Path: <jan.melen@nomadiclab.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 A69183A690C for <hipsec@core3.amsl.com>; Tue, 6 Jul 2010 06:37:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 b+AHL62kw6Ga for <hipsec@core3.amsl.com>; Tue, 6 Jul 2010 06:37:52 -0700 (PDT)
Received: from gw.nomadiclab.com (unknown [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 4C96B3A68FA for <hipsec@ietf.org>; Tue, 6 Jul 2010 06:37:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 161EC4E6E4; Tue, 6 Jul 2010 16:37:51 +0300 (EEST)
X-Virus-Scanned: amavisd-new at nomadiclab.com
Received: from gw.nomadiclab.com ([127.0.0.1]) by localhost (inside.nomadiclab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hP0huvsi6t8Q; Tue, 6 Jul 2010 16:37:49 +0300 (EEST)
Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id 26B654E6C8; Tue, 6 Jul 2010 16:37:49 +0300 (EEST)
Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id DCBF3106E84; Tue, 6 Jul 2010 16:37:48 +0300 (EEST)
Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id A2CED106E83; Tue, 6 Jul 2010 16:37:48 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="iso-8859-1"
From: Jan Melen <jan.melen@nomadiclab.com>
In-Reply-To: <4C318090.7080507@cs.hut.fi>
Date: Tue, 06 Jul 2010 16:37:47 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <A5278048-AB39-486D-BB13-B1C13A4FD6A3@nomadiclab.com>
References: <F303C95A-64E6-4383-8A5C-27F5CD0A23B5@cs.rwth-aachen.de> <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com> <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com> <4C318090.7080507@cs.hut.fi>
To: Miika Komu <mkomu@cs.hut.fi>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: hipsec@ietf.org
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: Tue, 06 Jul 2010 13:37:54 -0000

On Jul 5, 2010, at 9:49 AM, Miika Komu wrote:

> On 07/05/2010 07:07 AM, Henderson, Thomas R wrote:
> 
> Hi Tom,
> 
>>> -----Original Message-----
>>> From: hipsec-bounces@ietf.org
>>> [mailto:hipsec-bounces@ietf.org] On Behalf Of Pekka Nikander
>>> Sent: Sunday, July 04, 2010 12:15 AM
>>> To: René Hummen
>>> Cc: HIP WG
>>> Subject: Re: [Hipsec] Comments on 5201-bis-02
>>> 
>>>> - 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
>>> 
>> 
>> I tend to agree with Rene's observations and think it would be worthwhile to examine his proposal in the new protocol version.  I am curious how often the implementations actually couple the rekeying with address change notifications in practice.
> 
> this hasn't been the case at least in HIPL.


And the opposite, that has been the case for HIP4inter.net. :-)

    Jan