[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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.
 


Follow-Ups: References: