[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE v2 Requirements and backwards compatability
Unless IKEv2 is a subset of IKEv1 which would simplify things, but that seem
not to be the approach of the WG. So, am I correct in saying that any
attempts to simplify IKEv1 by tightening the language, removing AH, COMMIT
BIT, and a "mode" would not make IKEv1 better, and less complex? How about
pre-defining protection suites to avoid negotiation explosions? I am sure
this has all been discussed on the list. I will check the achieves. How
about describing how certs and IKE should work (Multiple roots, cert
requests, chains etc). Maybe including DPD and the hash fixes, and the
current NAT work, and that may make an excellent IKEv2.
That being said, if even the above does not meet the requirements, then
IKEv1, in any form, would not fly. Glad to see that the requirements are
framing the debate.
Thanks
Scott
----- Original Message -----
From: "Paul Cardon" <paul@moquijo.com>
To: "Scott Fanning" <sfanning@cisco.com>
Cc: "IETF-IPSec" <ipsec@lists.tislabs.com>
Sent: Monday, December 17, 2001 5:47 PM
Subject: Re: IKE v2 Requirements and backwards compatability
> Scott Fanning wrote:
>
> > Should there be a requirement that IKEv2 be able to interoperate with
> > IKEv1? There is a large deployed base, and a migration path to the new
> > version should be an requirement. I understand this might increase the
> > complexity, but I am sure people using IKE today will not swap out all
> > their equipment overnight.
>
>
> If IKEv2 can interoperate with IKEv1 then it IS IKEv1.
>
> -paul
>
Follow-Ups:
References: