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

Pekka Nikander <> Sun, 04 July 2010 07:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 030333A687D for <>; Sun, 4 Jul 2010 00:15:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.301
X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_8BIT_HEADER=0.3]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NdT6QIr+Bpnt for <>; Sun, 4 Jul 2010 00:15:05 -0700 (PDT)
Received: from ( [IPv6:2001:14b8:400:101::2]) by (Postfix) with ESMTP id 7DEC83A67B6 for <>; Sun, 4 Jul 2010 00:15:02 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 989974E6D4; Sun, 4 Jul 2010 10:14:58 +0300 (EEST)
X-Virus-Scanned: amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CLlZGwl8Y8HO; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from ( [IPv6:2001:14b8:400:100::146]) by (Postfix) with ESMTP id E3CD54E6BF; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from (localhost []) by (Postfix) with ESMTP id AC4D4106E84; Sun, 4 Jul 2010 10:14:57 +0300 (EEST)
Received: from [IPv6:::1] ( [IPv6:2001:14b8:400:101::2]) by (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 <>
In-Reply-To: <>
Date: Sun, 04 Jul 2010 10:14:56 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: René Hummen <>
X-Mailer: Apple Mail (2.1081)
X-Virus-Scanned: ClamAV using ClamSMTP
Cc: HIP WG <>
Subject: Re: [Hipsec] Comments on 5201-bis-02
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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