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

Re: Position statement on IKE development


On Mon, Aug 06, 2001 at 06:03:08PM -0600, Horn, Mike wrote:
[-- snip --]
> Perhaps a new requirements draft needs to be started, so that Son of IKE
> does not suffer the same fate as IKE.  IMHO, I think trying to make Son of
> IKE "implementation preserving" is going to take Son of IKE down a very
> familiar and ugly path.  Starting out with a new port assignment, and
> building from the ground up might be the only answer.  There are obviously a
> lot of lessons that have been learned the hard way which should serve to
> greatly improve both the security and reduce the complexity of a next
> generation key exchange protocol designed specifically for IPsec.

Speaking from an operator's viewpoint, I have to agree with Mike and
other posters in support of jumping over 'son-of-IKE' and, instead,
launching a new initiative for a 'next-generation' IKE that is based
on a clearly defined set of *requirements* from the operator and
implementor community.  In fact, starting with *requirements draft*
BEFORE 'son-of-IKE' would be immensely helpful in gathering consensus
on whether it is even worth it to do 'son-of-IKE' or just jump over it
and start from scratch.  As a good friend and colleague says: "You've
got to define a target before you can aim at it; otherwise, you'll
never hit anything."  Right now, I have a hard time seeing how
painting some broad strokes of: a) simplify IKE; and, b) possibly add
these other arbitrary "enhancements" will lead to anything but
delaying the inevitable opening up the can-of-worms that is re-vamping
IKE from the ground up so it has extensibility and future-proofing.

The bottom-line is the current proposals on the table really only
addresses two thirds of the problems I see in the real-world today.
Specifically, 1) simplification of IKE; and, 2) NAT-traversal.  What
it doesn't address is: 3) remote-access/legacy-authentication issues,
which in all fairness, has been stated "will be worked on later" while
IPSRA is also valiantly attempting to come up with a solution today.
Ultimately, it boils down to the fact that, as an operator, I'd much
rather see a comprehensive solution developed that addresses all three
concerns than have to deploy 'son-of-IKE' and then, some time later,
either 'son-of-IKE++' or 'next-gen-IKE' that finally captures all of
my customer's needs.

Anyway, just my $0.02 ...

-shane