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

Ari Keränen <> Tue, 01 March 2011 15:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C49613A6975; Tue, 1 Mar 2011 07:42:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.884
X-Spam-Status: No, score=-5.884 tagged_above=-999 required=5 tests=[AWL=0.415, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j5d7tqArgkNu; Tue, 1 Mar 2011 07:42:29 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 5C5CF3A695A; Tue, 1 Mar 2011 07:42:28 -0800 (PST)
X-AuditID: c1b4fb39-b7c6dae0000023f2-e4-4d6d141f68ff
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 72.3E.09202.F141D6D4; Tue, 1 Mar 2011 16:43:27 +0100 (CET)
Received: from ( by ( with Microsoft SMTP Server id; Tue, 1 Mar 2011 16:43:26 +0100
Received: from ( []) by (Postfix) with ESMTP id 56C4A2868; Tue, 1 Mar 2011 17:43:26 +0200 (EET)
MIME-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/signed; boundary="Apple-Mail-95-711942887"; protocol="application/pkcs7-signature"; micalg="sha1"
From: Ari Keränen <>
In-Reply-To: <>
Date: Tue, 01 Mar 2011 17:43:26 +0200
Message-ID: <>
References: <> <> <>
X-Mailer: Apple Mail (2.1082)
X-Brightmail-Tracker: AAAAAA==
X-Mailman-Approved-At: Wed, 02 Mar 2011 01:24:35 -0800
Cc: "" <>, "" <>, "" <>, Gonzalo Camarillo <>
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: Tue, 01 Mar 2011 15:42:29 -0000

Hi David,

On Mar 1, 2011, at 4:44 PM, wrote:
>> If we explicitly prevent a policy that would not allow un-encrypted connection re-establishing
>> 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.
> That proposed change looks good to me, as the immediately following sentence in Section 5 points back to Section 3.2 for the re-negotiation, from which the reader will proceed to Section 3.3 on handling the error that occurs if the re-negotiation fails to propose an encrypted HIP transport.

Thanks! I'll use that text in the next revision.

> Please wait to hear from Ralph (AD) before submitting a revised draft, as an RFC Editor Note may suffice to make this change.

OK, although there will be at least one more change due to Lars' review, so it probably makes sense to submit a revised version after I've fixed all the comments and discusses.