Re: draft-ietf-ipsec-ikev2-01.txt
"Jin Zhang" <jzhang@elmic.com> Thu, 28 February 2002 20:23 UTC
Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g1SKNZi16681; Thu, 28 Feb 2002 12:23:35 -0800 (PST)
Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05608 Thu, 28 Feb 2002 14:47:15 -0500 (EST)
Message-ID: <005b01c1c092$6060cf40$4a2c12ce@riverside>
From: Jin Zhang <jzhang@elmic.com>
To: ipsec@lists.tislabs.com, Dan Harkins <dharkins@tibernian.com>
References: <200202272128.g1RLS1K01222@fatty.lounge.org>
Subject: Re: draft-ietf-ipsec-ikev2-01.txt
Date: Thu, 28 Feb 2002 11:59:04 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk
my 2 cents: 1) Page 7, sec 2.2 Use of sequence number for message id. AH and ESP both has a sequence number begins with 1, why IKE will begin with 0? Somebody may forget to set the sequence number but still sends out a valid sequence number, personally think 1 is better. 2) Page 4, Section 1.2 Change history. How about most recently first? 3) Page 4 para 5, "If the Responder feels it is under attack,..." To implement the 'FEELS' is much more difficult than 'If the Responder's local policy requires anti-attack...' Anyway, maybe how to implement is not under consideration. 4) The IKEv1 has a seperate RFC regarding OAKLEY/ISAKMP, and IKEv2 combines them together. However, the sequence should be kept consistant. It is maybe better to have section 7 'The IKE Header" moved to an earlier position, in order to avoid situation like that we have HDRs, payloads everywhere before we have a formal introduction to them. 5) Maybe too picky for this one. Page 14 para 3. " To negotiate an SA that does ESP, IPcomp, and AH, ...three proposals... one proposing ESP, ... one proposing AH... and one proposing IPcomp". It should have consistant sequence, say, "ESP, AH and IPcomp" 6) Page 11. Section 2.6 Cookies. " ..the SA is uniquely defined by the recipient's SA identifier ..." From the context, the recipient's SA identifier means the Recipient's SPI (responder cookie). How this value can uniquely define the IKE-SA? You mean <SPI, recipient IP>? or <SPI, recipient identity>? If so, we still need a hash, there seems no way to be "convenient for the IKE-SA identifier to be an index into a table". I must have missed something? Thanks, Jin ----- Original Message ----- From: "Dan Harkins" <dharkins@tibernian.com> To: <ipsec@lists.tislabs.com> Sent: Wednesday, February 27, 2002 1:28 PM Subject: draft-ietf-ipsec-ikev2-01.txt > An updated IKEv2 draft has been submitted to the I-D editor. Due to > the last second rush it might be a while before it appears in the > repository. So in the interest of giving everyone a few more days to > read and comment I've posted it at: > > http://www.lounge.org/draft-ietf-ipsec-ikev2-01.txt > > Comments to the list, please. > > Enjoy! > > Dan. > >
- draft-ietf-ipsec-ikev2-01.txt Dan Harkins
- RE: draft-ietf-ipsec-ikev2-01.txt Andrew Krywaniuk
- Re: draft-ietf-ipsec-ikev2-01.txt Tero Kivinen
- RE: draft-ietf-ipsec-ikev2-01.txt Andrew Krywaniuk
- RE: draft-ietf-ipsec-ikev2-01.txt Tero Kivinen
- RE: draft-ietf-ipsec-ikev2-01.txt andrew.krywaniuk
- Re: draft-ietf-ipsec-ikev2-01.txt Jin Zhang
- Re: draft-ietf-ipsec-ikev2-01.txt Radia Perlman - Boston Center for Networking
- RE: draft-ietf-ipsec-ikev2-01.txt Takaoka Takayoshi
- Re: draft-ietf-ipsec-ikev2-01.txt Catherine A. Meadows