[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: IKE must have no Heirs
This will be my second (and last) e-mail on this thread because their are
too many egos involved here. As an implementor of IPSEC & IKE, I can
testify that IKE is confusion, convoluted, overly complicated,, and has
security holes. There are papers written on this subject by people much
more intelligent than myself who have come to the same conclusion.
Kory
On Tue, 7 Aug 2001, Dan Harkins wrote:
> It was called SKIP. I suggest you guys familiarize yourselves with
> this WG.
>
> Dan.
>
> On Tue, 07 Aug 2001 00:28:20 PDT you wrote
> >
> > I second the motion. And also propose no port number (i.e. do the new
> > one over raw IP).
> >
> > - Alex
> >
> > At 11:07 PM 8/6/2001 -0700, Kory Hamzeh wrote:
> > >
> > >Well said. I agree with you 100%. Throw is out and let's start from
> > >scratch with something more reasonable and realistic.
> > >
> > >Kory
> > >
> > >
> > >On Mon, 6 Aug 2001, Hallam-Baker, Phillip wrote:
> > >
> > >>
> > >> > Unfortunately the notion that IPsec should simply \"bind
> > >> > a key to an IP address\" was rejected repeatedly throughout
> > >> > the history of the IPsec WG.
> > >>
> > >> This is why I think we have to stop talking about 'son of IKE'
> > >> as if the problem was in the 7 years and 9 months of trying to
> > >> implement the requirements and not the 3 months of requirements
> > >> capture.
> > >>
> > >> [ ..... ]
> > >>
> > >> From here there are two routes forward. We could specify a reduced
> > >> IKE, eliminating all but 2 of the current 8 modes, simplifying the
> > >> negotiation, knife AH... to result in a simpler draft that we can be
> > >> confident would get a broad review. I think that would have been an
> > >> excellent idea three years ago, I think that it is too late after
> > >> the interop tests have been performed. All that would come out
> > >> is a description of a profile of the current spec that resulted
> > >> in one configuration that was secure. But implementations would
> > >> still be constrained by the existing legacy base which would
> > >> drag deployments back into the mire of unexamined code paths and
> > >> unanticipated interactions.
> > >>
> > >> The second is to burn the current drafts and start from scratch
> > >> with a fresh port number. If any change is made that breaks
> > >> backwards compatibility then this might as well be what you do.
> > >>
> > >> In short the phrase 'Son of IKE' is part of the problem, not
> > >> the solution. IKE must have no heirs, it is time for a new dynasty
> > >> to take the throne.
References: