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 >
- [Hipsec] Status of our milestones Gonzalo Camarillo
- Re: [Hipsec] Status of our milestones Tobias Heer
- Re: [Hipsec] Status of our milestones Miika Komu
- Re: [Hipsec] Status of our milestones Henderson, Thomas R
- [Hipsec] Resolution of Ticket 22 Tobias Heer
- [Hipsec] Status of our milestones Gonzalo Camarillo