Re: [Hipsec] Status of our milestones

Tobias Heer <> Thu, 01 September 2011 07:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5E8BC21F8AF2 for <>; Thu, 1 Sep 2011 00:33:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.801
X-Spam-Status: No, score=-4.801 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, HELO_MISMATCH_DE=1.448, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id I3FRq+rM8diu for <>; Thu, 1 Sep 2011 00:33:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 41A4021F8AD9 for <>; Thu, 1 Sep 2011 00:33:31 -0700 (PDT)
MIME-version: 1.0
Content-transfer-encoding: 7bit
Content-type: text/plain; charset="us-ascii"
Received: from ([]) by (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008)) with ESMTP id <> for; Thu, 01 Sep 2011 09:35:02 +0200 (CEST)
X-IronPort-AV: E=Sophos;i="4.68,312,1312149600"; d="scan'208";a="62794379"
Received: from (HELO relay-auth-1) ([]) by with ESMTP; Thu, 01 Sep 2011 09:35:03 +0200
Received: from [] ([unknown] []) by (Sun Java(tm) System Messaging Server 7.0-3.01 64bit (built Dec 9 2008)) with ESMTPA id <> for; Thu, 01 Sep 2011 09:35:02 +0200 (CEST)
From: Tobias Heer <>
In-reply-to: <>
Date: Thu, 01 Sep 2011 09:35:04 +0200
Message-id: <>
References: <>
To: HIP <>
X-Mailer: Apple Mail (2.1084)
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: Thu, 01 Sep 2011 07:33:32 -0000


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.


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

Dipl.-Inform. Tobias Heer, Ph.D. Student
Chair of Communication and Distributed Systems - comsys
RWTH Aachen University, Germany
tel: +49 241 80 207 76
pgp id: AEECA5BF