Re: [Hipsec] Status of our milestones

Miika Komu <mkomu@cs.hut.fi> Sun, 04 September 2011 10:53 UTC

Return-Path: <mkomu@cs.hut.fi>
X-Original-To: hipsec@ietfa.amsl.com
Delivered-To: hipsec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC14F21F86EA for <hipsec@ietfa.amsl.com>; Sun, 4 Sep 2011 03:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.902
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vob7nXJh0G1q for <hipsec@ietfa.amsl.com>; Sun, 4 Sep 2011 03:53:35 -0700 (PDT)
Received: from mail.cs.hut.fi (mail.cs.hut.fi [130.233.192.7]) by ietfa.amsl.com (Postfix) with ESMTP id EC4E321F85EC for <hipsec@ietf.org>; Sun, 4 Sep 2011 03:53:34 -0700 (PDT)
Received: from hutcs.cs.hut.fi ([130.233.192.10] helo=[127.0.0.1]) by mail.cs.hut.fi with esmtp (Exim 4.54) id 1R0AM6-0001ys-9u for hipsec@ietf.org; Sun, 04 Sep 2011 13:55:14 +0300
Message-ID: <4E635911.2040607@cs.hut.fi>
Date: Sun, 04 Sep 2011 13:55:13 +0300
From: Miika Komu <mkomu@cs.hut.fi>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: hipsec@ietf.org
References: <4E3F966C.2040202@ericsson.com> <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de>
In-Reply-To: <10A0000D-1B75-4991-A39C-AE6B6AC37C70@cs.rwth-aachen.de>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [Hipsec] Status of our milestones
X-BeenThere: hipsec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the official IETF Mailing List for the HIP Working Group." <hipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/hipsec>, <mailto:hipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hipsec>
List-Post: <mailto:hipsec@ietf.org>
List-Help: <mailto:hipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hipsec>, <mailto:hipsec-request@ietf.org?subject=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
> -------------------------------------
> http://trac.tools.ietf.org/wg/hip/trac/ticket/22
>
> 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.
>>
>> https://datatracker.ietf.org/wg/hip/charter/
>>
>> 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
>> Hipsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/hipsec
>