[Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05

<david.black@emc.com> Fri, 25 February 2011 19:08 UTC

Return-Path: <david.black@emc.com>
X-Original-To: hipsec@core3.amsl.com
Delivered-To: hipsec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 6D6303A69F5; Fri, 25 Feb 2011 11:08:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id A6sxKR+VLwPf; Fri, 25 Feb 2011 11:08:24 -0800 (PST)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com []) by core3.amsl.com (Postfix) with ESMTP id 2A2203A67E2; Fri, 25 Feb 2011 11:08:23 -0800 (PST)
Received: from hop04-l1d11-si03.isus.emc.com (HOP04-L1D11-SI03.isus.emc.com []) by mexforward.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJ9DrM012442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2011 14:09:13 -0500
Received: from mailhub.lss.emc.com (mailhub.lss.emc.com []) by hop04-l1d11-si03.isus.emc.com (RSA Interceptor); Fri, 25 Feb 2011 14:09:08 -0500
Received: from mxhub13.corp.emc.com (mxhub13.corp.emc.com []) by mailhub.lss.emc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJ7XZV027722; Fri, 25 Feb 2011 14:07:33 -0500
Received: from mxhub29.corp.emc.com ( by mxhub13.corp.emc.com ( with Microsoft SMTP Server (TLS) id; Fri, 25 Feb 2011 14:07:32 -0500
Received: from mx14a.corp.emc.com ([]) by mxhub29.corp.emc.com ([]) with mapi; Fri, 25 Feb 2011 14:07:32 -0500
From: david.black@emc.com
To: ari.keranen@ericsson.com, ops-dir@ietf.org
Date: Fri, 25 Feb 2011 14:07:31 -0500
Thread-Topic: OPS-DIE review of draft-ietf-hip-over-hip-05
Thread-Index: AcvVH0DX3VV8D/c5RHyKZzzIGzhxzA==
Message-ID: <7C4DFCE962635144B8FAE8CA11D0BF1E03E5B1C06C@MX14A.corp.emc.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sun, 27 Feb 2011 23:57:36 -0800
Cc: hipsec@ietf.org, david.black@emc.com, rdroms.ietf@gmail.com, gonzalo.camarillo@ericsson.com
Subject: [Hipsec] OPS-DIE review of draft-ietf-hip-over-hip-05
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: Fri, 25 Feb 2011 19:08:25 -0000

I have performed an Operations Directorate review of draft-ietf-hip-over-hip-05

Operations directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, and allowing them to focus on documents requiring their attention and spend less time on the trouble-free ones.  Improving the documents is important, but clearly a secondary purpose.  A third purpose is to broaden the OpsDir reviewers' exposure to work going on in other parts of the IETF.

Reviews from OpsDir members do not in and of themselves cause the IESG to raise issue with a document. The reviews may, however, convince individual IESG members to raise concern over a particular document requiring further discussion. The reviews, particularly those conducted in last call and earlier, may also help the document editors improve their documents.


Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.

HIP is in a related functional space to IPsec, and in both cases IETF protocols are not typical means for operation and management (e.g., the IPsec SPD MIB is not widely used for configuring IPsec).  This draft specifies minor extensions to HIP in that it defines two additional HIP transports, so it's not a reasonable vehicle for a general discussion of HIP operations and management.  As a result, this review focuses on operational characteristics of the extensions specified in the draft.

This draft defines two new fully encrypted transports for HIP signaling messages - ESP and ESP over TCP.  The draft includes details on negotiation of these modes as extensions to existing HIP signaling, providing support for incremental deployment, a migration path and backwards compatibility.  While it is probably best to start out with the intended transport (i.e., negotiate it in the HIP base exchange), means are also specified to negotiate a transport change later.  An error report is defined for use when a HIP node policy requires use of one of these fully encrypted transports, but none is offered in negotiation.  Fallback to a non-encrypted transport is specified and recommended (SHOULD) when the encrypted transport fails.

I have one recommendation for change - this draft is somewhat inconsistent about support for a HIP node policy that requires use of an encrypted transport for HIP signaling.  Section 3.3 provides an essential building block, the error signaling mechanism to indicate that an encrypted transport is required and none was proposed.  On the other hand, Section 5 is unclear with respect to this class of policy in that it strongly recommends (SHOULD) fallback to a non-encrypted HIP connection but requires (MUST) that "messages that are intended to be sent only encrypted" not be sent unencrypted.  If the "messages that are intended to be sent only encrypted" are all HIP messages after the base exchange, these two requirements appear to be in conflict.

I suggest adding a short explanation to Section 5 of what would be reasonable vs. unreasonable policy for "messages that are intended to be sent only encrypted", and how to use the Section 3.3 error report when a failed encrypted connection is recovered by attempting to fall back to an unencrypted connection when HIP node policy requires encryption of all signaling after the base exchange.

David L. Black, Distinguished Engineer
EMC Corporation, 176 South St., Hopkinton, MA  01748
+1 (508) 293-7953             FAX: +1 (508) 293-7786
david.black@emc.com        Mobile: +1 (978) 394-7754