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

Miika Komu <mkomu@cs.hut.fi> Mon, 05 July 2010 06:49 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 129CE3A6902 for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 23:49:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.749
X-Spam-Level:
X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.850, 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 B8zOoWwyjh-A for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 23:49:52 -0700 (PDT)
Received: from hutcs.cs.hut.fi (hutcs.cs.hut.fi [130.233.192.7]) by core3.amsl.com (Postfix) with ESMTP id 322D83A6905 for <hipsec@ietf.org>; Sun, 4 Jul 2010 23:49:52 -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 1OVfV2-0003WW-PC for hipsec@ietf.org; Mon, 05 Jul 2010 09:49:52 +0300
Message-ID: <4C318090.7080507@cs.hut.fi>
Date: Mon, 05 Jul 2010 09:49:52 +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> <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com>
In-Reply-To: <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Mon, 05 Jul 2010 06:49:53 -0000

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.