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

[Tero Kivinen <[e-mail]>]

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.

> > There might be limitiations in mixing the version numbers, but in
> > general I would say they it should be allowed. If we redefine SKEYID
...
> Doesn't this complicates processing a lot?

No, I don't think so. 

> 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.
-- 
[e-mail]                               Work : [phone]
SSH Communications Security                  http://www.ssh.fi/
SSH IPSEC Toolkit                            http://www.ssh.fi/ipsec/