Re: Working Group Last Call IKEv2
Francis Dupont <Francis.Dupont@enst-bretagne.fr> Mon, 09 June 2003 17:09 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12672 for <ipsec-archive@lists.ietf.org>; Mon, 9 Jun 2003 13:09:02 -0400 (EDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28741 Mon, 9 Jun 2003 11:00:41 -0400 (EDT)
Message-Id: <200306091506.h59F65of003913@givry.rennes.enst-bretagne.fr>
From: Francis Dupont <Francis.Dupont@enst-bretagne.fr>
To: Barbara Fraser <byfraser@cisco.com>
cc: ipsec@lists.tislabs.com, tytso@mit.edu
Subject: Re: Working Group Last Call IKEv2
In-reply-to: Your message of Tue, 03 Jun 2003 10:32:01 PDT. <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com>
Date: Mon, 09 Jun 2003 17:06:05 +0200
X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
In your previous mail you wrote: I have some concerns about the current draft (08), here are the minor concerns: - in section 2.1 (retransmission) we should stress the "messages" are IKE messages, i.e., for instance one can restransmit a request using a different address in the transport header. I propose a very simple improvement, change: For every pair of messages, the Initiator is responsible for to For every pair of IKE messages, the Initiator is responsible for so the reader can refer to section 3 where IKE messages are defined. - nowhere the rule for sending response (reverse the transport stuff) is fully explained. I propose to complete section 2.11 (agility): ... An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. becomes: ... An implementation MUST accept incoming requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received, and from the address and port to which the request was received. note that I suppressed the word "connection" as this stands for every requests. - when CHILD_SAs rekeyed with a CREATE_CHILD_SA using PFS are usable? In IKEv1 these synchro issues are handled by the infamous commit bit and the third message of quick mode... IMHO the companion draft (draft-ietf-ipsec-ikev2-tutorial-xx.txt) should give some hints. BTW I'd like to get the opinion from other implementors because the simplest solution (wait for an initiator->responder packet) is not always available... This can be an occasion to explain what SA to use in rekeying, the new one or the old one until it expires? Regards Francis.Dupont@enst-bretagne.fr
- Working Group Last Call IKEv2 Barbara Fraser
- IPComp editorial comments (Re: Working Group Last… Abraham Shacham
- Re: Working Group Last Call IKEv2 Francis Dupont
- Re: Working Group Last Call IKEv2 Francis Dupont
- Identity protection [Re: Working Group Last Call … Scott G. Kelly
- RE: Identity protection [Re: Working Group Last C… Pagliusi PS