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

Ari Keränen <> Mon, 28 February 2011 13:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 585873A6BF6; Mon, 28 Feb 2011 05:10:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.053
X-Spam-Status: No, score=-5.053 tagged_above=-999 required=5 tests=[AWL=-1.246, BAYES_00=-2.599, FRT_ESTABLISH2=2.492, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7AKk9zZS4EC6; Mon, 28 Feb 2011 05:10:11 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 124863A6BF7; Mon, 28 Feb 2011 05:10:10 -0800 (PST)
X-AuditID: c1b4fb39-b7c6dae0000023f2-b0-4d6b9eee6e3f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 59.AD.09202.EEE9B6D4; Mon, 28 Feb 2011 14:11:10 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Mon, 28 Feb 2011 14:11:10 +0100
Received: from ( []) by (Postfix) with ESMTP id 8D85425C4; Mon, 28 Feb 2011 15:11:09 +0200 (EET)
MIME-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Ari Keränen <>
In-Reply-To: <>
Date: Mon, 28 Feb 2011 15:11:09 +0200
Content-Transfer-Encoding: quoted-printable
Message-ID: <>
References: <>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Mon, 28 Feb 2011 05:16:28 -0800
Subject: Re: [Hipsec] OPS-DIE 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: Mon, 28 Feb 2011 13:10:12 -0000

Hi David,

Thanks for the review!

On Feb 25, 2011, at 9:07 PM, <> <> wrote:
> Summary: This draft is basically ready for publication, but has nits that should be fixed before publication.
> 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.

That's a valid point. A policy that would prevent sending the re-establishing UPDATEs un-encrypted after a failed encrypted connection would be unreasonable since then one could never re-establish such a connection or even close it properly. This is already explicit for the receiving end (MUST accept without encryption), but making it explicit also for the sender makes sense.

The first SHOULD refers to the fact that one may also do something else than re-establish the connection (e.g., close it).

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

If we explicitly prevent a policy that would not allow un-encrypted connection re-establisihing UPDATEs, I think we have this fixed, and we would not need to use error messages for informing about this. I would change the text in section 5 into (added the last sentence and changed the second-to-last one):

   [...] If encryption was
   previously used, hosts SHOULD send outside of the encrypted
   connection only HIP messages that are used to re-establish the
   encrypted connection.  Especially, messages for which the policy is
   to send them only encrypted (e.g., DATA messages using an encrypted
   transport mode) MUST be sent only using the encrypted connection.
   Note that a policy MUST NOT prevent sending un-encrypted UPDATE
   messages used for re-establishing the encrypted connection, since
   that would prevent recovering from failed encrypted connections.