Re: [Hipsec] RFC5201-bis and RFC5202-bis status

Tom Henderson <> Tue, 28 October 2014 16:50 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9096C1A9039 for <>; Tue, 28 Oct 2014 09:50:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.033
X-Spam-Level: *
X-Spam-Status: No, score=1.033 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NVqqyBT7ABZB for <>; Tue, 28 Oct 2014 09:50:10 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id C0BEB1A90C9 for <>; Tue, 28 Oct 2014 09:44:52 -0700 (PDT)
Received: (qmail 16692 invoked by uid 0); 28 Oct 2014 16:44:51 -0000
Received: from unknown (HELO cmgw2) ( by with SMTP; 28 Oct 2014 16:44:51 -0000
Received: from ([]) by cmgw2 with id 8gkT1p01W2molgS01gkW79; Tue, 28 Oct 2014 10:44:34 -0600
X-Authority-Analysis: v=2.1 cv=e5mVF8Z/ c=1 sm=1 tr=0 a=K/474su/0lCI2gKrDs9DLw==:117 a=K/474su/0lCI2gKrDs9DLw==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ZSdzdHkL1-cA:10 a=N659UExz7-8A:10 a=HYWc1YUsAAAA:8 a=IA_2sfgTpx8A:10 a=rREcAdlOb-AA:10 a=48vgC7mUAAAA:8 a=3AAdyg3TLApRQK_I-MYA:9 a=pILNOxqGKmIA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=yabL5EhXHevUx/n/EAvLDvOslDJvHu5u2f28er8Icnw=; b=WayWGoqf4xJ4BwHyGgtXKztUa6emRRGy7cMcq919l/lAR0AvEh2fbuZp7AuXIsmom079plTlXidqrwFYlBcg743PeIFtPbboRo7JiXVuCpY2LGx1BAmce0FbmJgCdODu;
Received: from [] (port=38218 helo=[]) by with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82) (envelope-from <>) id 1Xj9si-0005TB-NF; Tue, 28 Oct 2014 10:44:28 -0600
Message-ID: <>
Date: Tue, 28 Oct 2014 09:44:25 -0700
From: Tom Henderson <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Miika Komu <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Identified-User: {} {sentby:smtp auth authed with}
Subject: Re: [Hipsec] RFC5201-bis and RFC5202-bis status
X-Mailman-Version: 2.1.15
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, 28 Oct 2014 16:50:12 -0000

On 10/28/2014 07:00 AM, Miika Komu wrote:

> I wrote a checksum generator, and I have independently verified that the
> checksums in RFC5201-bis are correct.

Miika, thank you for checking this.

This leaves one open issue, regarding the clarifications to 
HIT_SUITE_LIST.  I originally put a diff proposal here:

This proposal drew one review on the list from Rene, who suggested the 

1) swap the encoding of the HIT Suite IDs to use the lower four-order 
bits instead of the higher four-order bits

2) fix an editorial reference to “HMAC parameter” -> “HIP_MAC and 
HIP_MAC_2 parameters” (or RHASH function).

3) change one of the proposed 'should' words to 'SHOULD'

While I am sympathetic to Rene's argument in 1), no one else has 
supported this change on the list, so given the late stage of this 
document, I would suggest to keep the encoding as is.  The changes 
proposed in 2) and 3) are editorial, in my view, so I don't see a 
problem to accept them.

I regenerated the diff according to Rene's suggestions, and posted it here:

So in summary, I would like to now convey to our AD that we have a diff 
to the version -19 draft that is editorial/clarification in nature, and 
ask whether and how it can be handled procedurally, such as:

- publish a -20 and revisit some of the reviews (since version -19 was 
officially reviewed and approved, I don't know what it means to now post 
a -20 version)
- avoid publishing a -20 and handle these changes similar to AUTH48 changes
- scrap the diff and just publish version -19

Our AD can let us know how he prefers to handle it.

- Tom