Re: [Ipsec] Two IKEv2 issues from the IESG

Tero Kivinen <kivinen@iki.fi> Fri, 03 September 2004 09:04 UTC

Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08791 for <ipsec-archive@lists.ietf.org>; Fri, 3 Sep 2004 05:04:30 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39rU-0002Z5-5k; Fri, 03 Sep 2004 04:56:00 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1C39S8-000420-9z for ipsec@megatron.ietf.org; Fri, 03 Sep 2004 04:29:50 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07212 for <ipsec@ietf.org>; Fri, 3 Sep 2004 04:29:46 -0400 (EDT)
Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1C39Ug-0002Zn-6V for ipsec@ietf.org; Fri, 03 Sep 2004 04:32:27 -0400
Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id i838TaNw002630 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 3 Sep 2004 11:29:36 +0300 (EEST)
Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id i838TVP6002627; Fri, 3 Sep 2004 11:29:32 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <16696.11115.789768.114922@fireball.kivinen.iki.fi>
Date: Fri, 03 Sep 2004 11:29:31 +0300
From: Tero Kivinen <kivinen@iki.fi>
To: Michael Richardson <mcr@sandelman.ottawa.on.ca>
Subject: Re: [Ipsec] Two IKEv2 issues from the IESG
In-Reply-To: <29377.1094137368@marajade.sandelman.ottawa.on.ca>
References: <6.1.1.1.2.20040902090413.05449ec0@mail.binhost.com> <29377.1094137368@marajade.sandelman.ottawa.on.ca>
X-Mailer: VM 7.17 under Emacs 21.3.1
X-Edit-Time: 6 min
X-Total-Time: 7 min
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org, margaret@thingmagic.com, Russ Housley <housley@vigilsec.com>, narten@us.ibm.com
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Security <ipsec.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org
Content-Transfer-Encoding: 7bit

Michael Richardson writes:
>   I think that you mean "datagram" -- seeing as a 3000 byte datagram would
> exceed common MTU, it must have been fragmented into multiple frames to
> have been received.
> 
>   The above (corrected) statement also implies to me that an IKEv2 and
> host must be prepared to re-assemble at least 3000 bytes bytes worth of
> fragment.

Yes. That was my intention, meaning that all implementations of IKEv2
SHOULD also supoprt IP fragmentation in their end. There might be
nodes between which make it impossible to use fragmentation (firewalls
/ NATs etc), but I think we should require that our own end is working
in this case. I have seen IKEv1 implementation which implemented their
own IP / UDP code which didn't include any reassembly at all. I do not
want to that happen in the IKEv2. 

>     Russ> I suggest the removal of the elliptic curve groups from
>     Russ> Appendix B.
> 
>   I don't object.

Same here. It really does not matter if they are there or not. If they
are there, then it might be easier for people to define more of them
later, as the document also describes what to put in the KE payload,
so if we remove the groups, do we also remove this text from
draft-ietf-ipsec-ikev2-15.txt:
----------------------------------------------------------------------
   The data in the KE payload when using this group is the value x from
   the solution (x,y), the point on the curve chosen by taking the
   randomly chosen secret Ka and computing Ka*P, where * is the
   repetition of the group addition and double operations, P is the
   curve point with x coordinate equal to generator 1 and the y
   coordinate determined from the defining equation. The equation of
   curve is implicitly known by the Group Type and the A and B
   coefficients. There are two possible values for the y coordinate;
   either one can be used successfully (the two parties need not agree
   on the selection).
-- 
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec