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

"Henderson, Thomas R" <thomas.r.henderson@boeing.com> Mon, 05 July 2010 04:08 UTC

Return-Path: <thomas.r.henderson@boeing.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 3EF213A687C for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 21:08:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.305
X-Spam-Level:
X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=0.994, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 89xbSkRqcj3a for <hipsec@core3.amsl.com>; Sun, 4 Jul 2010 21:08:06 -0700 (PDT)
Received: from blv-smtpout-01.boeing.com (blv-smtpout-01.boeing.com [130.76.32.69]) by core3.amsl.com (Postfix) with ESMTP id 60E163A687B for <hipsec@ietf.org>; Sun, 4 Jul 2010 21:08:06 -0700 (PDT)
Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.14.4/8.14.4/8.14.4/SMTPOUT) with ESMTP id o6548028001750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 4 Jul 2010 21:08:01 -0700 (PDT)
Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.14.4/8.14.4/DOWNSTREAM_RELAY) with ESMTP id o65480dn001872; Sun, 4 Jul 2010 21:08:00 -0700 (PDT)
Received: from XCH-NWHT-07.nw.nos.boeing.com (xch-nwht-07.nw.nos.boeing.com [130.247.25.111]) by slb-av-01.boeing.com (8.14.4/8.14.4/UPSTREAM_RELAY) with ESMTP id o6547xQT001863 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=OK); Sun, 4 Jul 2010 21:07:59 -0700 (PDT)
Received: from XCH-NW-10V.nw.nos.boeing.com ([130.247.25.83]) by XCH-NWHT-07.nw.nos.boeing.com ([130.247.25.111]) with mapi; Sun, 4 Jul 2010 21:07:59 -0700
From: "Henderson, Thomas R" <thomas.r.henderson@boeing.com>
To: 'Pekka Nikander' <pekka.nikander@nomadiclab.com>, René Hummen <rene.hummen@cs.rwth-aachen.de>
Date: Sun, 04 Jul 2010 21:07:57 -0700
Thread-Topic: [Hipsec] Comments on 5201-bis-02
Thread-Index: AcsbSKRoiJY6LKuIRe2JdRrGxm1cmgArpEQQ
Message-ID: <7CC566635CFE364D87DC5803D4712A6C4CE97163BB@XCH-NW-10V.nw.nos.boeing.com>
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>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 05 Jul 2010 04:08:07 -0000

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

- Tom