Re: draft-ietf-ipsec-ike-ext-meth-01.txt

"Valery Smyslov" <svan@trustworks.com> Wed, 07 July 1999 08:16 UTC

Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by mail.proper.com (8.8.8/8.8.5) with ESMTP id BAA06631; Wed, 7 Jul 1999 01:16:43 -0700 (PDT)
Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA10691 Wed, 7 Jul 1999 02:37:14 -0400 (EDT)
Message-Id: <199907070636.KAA28544@relay1.trustworks.com>
Comments: Authenticated sender is <svan@ss10>
From: Valery Smyslov <svan@trustworks.com>
Organization: TWS
To: Tero Kivinen <kivinen@ssh.fi>
Date: Wed, 07 Jul 1999 10:36:43 +0004
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Subject: Re: draft-ietf-ipsec-ike-ext-meth-01.txt
CC: ipsec@lists.tislabs.com
In-reply-to: <199907061739.UAA26678@torni.ssh.fi>
References: <199907050722.LAA20287@relay1.trustworks.com>
X-mailer: Pegasus Mail for Win32 (v2.52)
Sender: owner-ipsec@lists.tislabs.com
Precedence: bulk

On  6 Jul 99 at 20:39, Tero Kivinen wrote:

> Valery Smyslov writes:
> > Yes, but KE protocol is currently encoded not in Proposal ID (that, 
> > right, must be only one within SA payload and must be equal 
> > PROTO_ISAKMP), but in Transform ID. It is absolutely legal to have 
> > multiple transforms with (possibly) different IDs within that single 
> > proposal payload. Currently only KEY_IKE is defined, but things might 
> 
> True, I mixed PROTO_ISAKMP with KEY_IKE.
 
Tero, I still would like to get an answer for my original question - 
if paragraph 4 from section 6 of your draft is right (statement that 
ISAKMP and IKE share one version number), what will ISAKMP version 
number mean in case several KE protocols (e.g. several transforms 
with different TransformIDs) are present in SA?

> > Sometimes you allow different versions, sometimes - not. What are
> > the reasons for mixing versions in phase 1 and 2?
> 
> I can start with old version of ISAKMP packet format and finish Phase
> 1 with that, but during that time I can find out from the vendor-id or
> something that yes the other end supports ISAKMP 1.1 which is needed
> to do some special exchanges, so I can switch to use ISAKMP 1.1 packet
> format for later exchanges.
> 
> The reason I want to start with 1.0 instead of 1.1, might be that the
> other end might just drop all packets whose version number is not 1.0.

If the other end drops all packets with 1.1, you will have to use 1.0 
even in the phase 2. If it doesn't, you may start with 1.1 even in 
phase 1 and continue to use it in phase 2. The behaviour when peer 
allows 1.1 only after receiving a familiar VendorID sounds strange to 
me, because after this he may not obey any ISAKMP version limitations 
at all and do anything. ISAKMP version defines standard interoperable 
packet format, while VendorID - non-standard.

> -- 
> kivinen@iki.fi                               Work : +358-9-4354 3218
> SSH Communications Security                  http://www.ssh.fi/
> SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/

Regards,
Valery.