Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05

<> Fri, 25 February 2011 19:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 72D9F3A67E2; Fri, 25 Feb 2011 11:17:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -106.539
X-Spam-Status: No, score=-106.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bePTEtOZ-M6N; Fri, 25 Feb 2011 11:17:01 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 571D73A67D2; Fri, 25 Feb 2011 11:17:01 -0800 (PST)
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJHptH027593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 25 Feb 2011 14:17:51 -0500
Received: from ( []) by (RSA Interceptor); Fri, 25 Feb 2011 14:17:42 -0500
Received: from ( []) by (Switch-3.4.3/Switch-3.4.3) with ESMTP id p1PJERs4027785; Fri, 25 Feb 2011 14:14:27 -0500
Received: from ([]) by ([]) with mapi; Fri, 25 Feb 2011 14:14:26 -0500
Date: Fri, 25 Feb 2011 14:14:26 -0500
Thread-Topic: OPS-DIR review of draft-ietf-hip-over-hip-05
Thread-Index: AcvVH0DX3VV8D/c5RHyKZzzIGzhxzAAAOkNA
Message-ID: <>
References: <>
In-Reply-To: <>
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
Subject: Re: [Hipsec] OPS-DIR review of draft-ietf-hip-over-hip-05
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: Fri, 25 Feb 2011 19:17:02 -0000

Freudian slip - that should be OPS-DI*R* in the subject line ...


> -----Original Message-----
> From: Black, David
> Sent: Friday, February 25, 2011 2:08 PM
> To:; ''
> Cc: Black, David; David Ward; Gonzalo Camarillo; Ralph Droms;
> Subject: OPS-DIE review of draft-ietf-hip-over-hip-05
> 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.
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
>        Mobile: +1 (978) 394-7754
> ----------------------------------------------------