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

Pekka Nikander <pekka.nikander@nomadiclab.com> Sun, 04 July 2010 07:15 UTC

Return-Path: <pekka.nikander@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 030333A687D for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 00:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Level:
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
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 NdT6QIr+Bpnt for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 00:15:05 -0700 (PDT)
Received: from gw.nomadiclab.com (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by core3.amsl.com (Postfix) with ESMTP id 7DEC83A67B6 for <hipsec@ietf.org>; Sun, 4 Jul 2010 00:15:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by gw.nomadiclab.com (Postfix) with ESMTP id 989974E6D4; Sun, 4 Jul 2010 10:14:58 +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 CLlZGwl8Y8HO; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from smtp.nomadiclab.com (d146.nomadiclab.com [IPv6:2001:14b8:400:100::146]) by gw.nomadiclab.com (Postfix) with ESMTP id E3CD54E6BF; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from smtp.nomadiclab.com (localhost [127.0.0.1]) by smtp.nomadiclab.com (Postfix) with ESMTP id AC4D4106E84; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from [IPv6:::1] (n2.nomadiclab.com [IPv6:2001:14b8:400:101::2]) by smtp.nomadiclab.com (Postfix) with ESMTP id 5D56A106E83; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Pekka Nikander <pekka.nikander@nomadiclab.com>
In-Reply-To: <F303C95A-64E6-4383-8A5C-27F5CD0A23B5@cs.rwth-aachen.de>
Date: Sun, 04 Jul 2010 10:14:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <1D9D7008-6B0F-49C2-AA3F-2A7B067AED94@nomadiclab.com>
References: <F303C95A-64E6-4383-8A5C-27F5CD0A23B5@cs.rwth-aachen.de>
To: René Hummen <rene.hummen@cs.rwth-aachen.de>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: HIP WG <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: Sun, 04 Jul 2010 07:15:07 -0000

> - 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

--Pekka