[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: draft-ietf-ipsec-ike-ext-meth-01.txt
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.
--
kivinen@iki.fi Work : +358-9-4354 3218
SSH Communications Security http://www.ssh.fi/
SSH IPSEC Toolkit http://www.ssh.fi/ipsec/
Follow-Ups:
References: