Re: [Hipsec] Status of our milestones

Miika Komu <> Sun, 04 September 2011 10:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AC14F21F86EA for <>; Sun, 4 Sep 2011 03:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.902
X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vob7nXJh0G1q for <>; Sun, 4 Sep 2011 03:53:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EC4E321F85EC for <>; Sun, 4 Sep 2011 03:53:34 -0700 (PDT)
Received: from ([] helo=[]) by with esmtp (Exim 4.54) id 1R0AM6-0001ys-9u for; Sun, 04 Sep 2011 13:55:14 +0300
Message-ID: <>
Date: Sun, 04 Sep 2011 13:55:13 +0300
From: Miika Komu <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] Status of our milestones
X-Mailman-Version: 2.1.12
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: Sun, 04 Sep 2011 10:53:35 -0000

Hi Tobias,

your suggestions seem reasonable to me.

On 09/01/2011 10:35 AM, Tobias Heer wrote:
> Hello,
> after having put my major personal roadblock aside, I'd like to get back to RFC5201-bis and get the last issues resolved.
> There are still some (few) open issues we need to address. Not all of them can be addressed without any discussion.
> Therefore I'd like to ask for some opinions here. All tickets can be found in the ticket system.
> I'll start with two of the easier ones:
> Ticket 22: R1_COUNTER inclusion in I2
> -------------------------------------
> RFC 5201 makes it optional to echo the R1 counter in the !I2!. However, when its
> optional, its hard to implement because you have to account for the case that
> the counter is present or missing in the I2. Skipping the counter all together
> is not an option because the Initiator uses it to sort out old R1s - so we need
> it in the R1. Alternatively, we could leave it out of the !I2! and the Responder
> could encode the required generation information into the R1 ECHO_REQUEST. It
> would get back the information in any case because the ECHO_RESPONSE in the !I2! is a MUST.
> However, we'd have some redundancy with the R1_COUNTER in the R1 then (which we
> can't remove because of the reasons stated above).
> My conclusion: I'd make it a MUST. Any comments on this?
> Ticket 27: IESG: allow negotiation of KDF
> -----------------------------------------
> The IESG commented that the key distribution function should be negotiable. We
> defined a new and better KDF. Are we done now?  I guess not. We have two
> options. Tie the KDF to the Diffie Hellman Group and negotiate it together with
> the DH group in the DH group list (my preferred option) OR negotiate it
> separately. As I view it, changing the KDF should only happen a) if something
> goes horribly wrong and the current KDF becomes insecure or b) if you want to
> change the scenario in which you want to apply HIP radically (e.g., if you move
> towards embedded systems). I think both cases will not demand high flexibility
> in the choice of the KDF (you don't pick another KDF just because you can).
> Moreover, we still have plenty of available DH_GROUP IDs left. I would opt for
> making the KDF exchangeable but to fix it to the DH group ID.
> Any objections?
> I'm looking forward to your feedback.
> Tobias
> Am 08.08.2011 um 09:55 schrieb Gonzalo Camarillo:
>> Folks,
>> please, have a look at the dates of our milestones and note that we are
>> already a few months behind.
>> It's time to put some more energy into the bis drafts.
>> With respect to the native NAT traversal draft and the RELOAD instance
>> draft, they are waiting for the bis drafts and the RELOAD draft to be
>> more mature, respectively. The good news is that the RELOAD draft is
>> already being reviewed by the IESG and will likely be published shortly.
>> Cheers,
>> Gonzalo
>> _______________________________________________
>> Hipsec mailing list