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

Re: Regarding the next version of IKE



Title: Regarding the next version of IKE
I think I brought this issue up a couple of months ago. The resounding answer at the time is that the version number in the isakmp hdr is enough to direct message to the correct process running a specific IKE version. I think there is some code reuse here (although that is a debatable requirement as well).
 
On a very different note:
 
Also, I was wondering if it would be possible to add a "message type" in the isakmp hdr in the IKEv2 (Harkins et al) to indicate what part of the exchange the message represents. This would be different than the "Exchange Type" as it would offer a finer level of granularity. I know you can look at how the message is constructed to determine that information, but it seems to be that a simple identifier to validate a message against a state machine would be a cheaper operation. Of course, it does not remove the requirement to examine the payloads to ensure that all is in order. Just an idea.
 
Scott
----- Original Message -----
Sent: Wednesday, March 06, 2002 2:47 PM
Subject: RE: Regarding the next version of IKE

I am not convinced that compatibility with IKEv1 needs to be an overiding concern at this stage, however it is certainly an advantage.
 
Although IPSEC is in principle a peer-peer protocol current deployment is largely to support VPNs, the killer app being securing remote access. I am not particularly concerned about IPSEC embedded in operating systems, security patches are not uncommon these days.
 
A simpler IKE that is 'backwards compatible' would be nice, but how much compatibility would I really get in practice?
 
The penalty for losing backwards compatibility will be starting adoption from a lower base, but I might be willing to swap that for a higher rate of adoption.
 
        Phill

Phillip Hallam-Baker FBCS C.Eng.
Principal Scientist
VeriSign Inc.
pbaker@verisign.com
781 245 6996 x227