Re: Position statement on IKE development

[Dan Harkins <dharkins@xxxxxxxxxx>]

  It's not going to be any less extensible than it already is but unless
there is a massive change of heart by our ADs it will not include legacy
user authentication or keepalives or any of the other things that we all
think users expect. If you remember, the Position Statement said:

    "This effort is at serious risk of suffering the 'second system 
     effect', where all the features that were left out of the first 
     version, end up in the second.  For this to happen would be a 
     spectacular disaster, and very much detract from the goal: to 
     produce a more secure, simpler, and more robust version of IKE."

I think if you ask Marcus or Jeff they would say that legacy user 
authentication and keepalives fall into the "second system effect"
class of feature. 

  If you also re-read the Position Statement you'll note that the
moratorium is temporary until the process of cleaning and simplifying
is done. I believe we can revisit things like legacy user authentication
when the moratorium is lifted.

  Dan.

On Sat, 04 Aug 2001 02:09:08 MDT you wrote
> Dan,
> 
> Is there any plan to make son-of-ike extensible for things like legacy user
> authentication, keepalives, etc?  Or will it just simplify the existing
> solution?  Without adding this new functionality, I think that IKE will
> still fall short of what user expectations are.
> 
> Mike
> 
> > -----Original Message-----
> > From: Dan Harkins [mailto:dharkins@xxxxxxxxxx]
> > Sent: Friday, August 03, 2001 4:35 PM
> > To: Henry Spencer
> > Cc: IP Security List; ietf-ipsra@xxxxxxxx; ipsec-policy@xxxxxxxx
> > Subject: Re: Position statement on IKE development 
> > 
> > 
> >   I discussed this in Minneapolis. The plan is to combine ISAKMP, IKE,
> > and the IPsec DOI into a single draft describing a key management
> > protocol for IPsec. 
> > 
> >   The intent, as well-meaning as it was, was to have a 
> > generic language 
> > (ISAKMP) in which to describe a key management protocol and 
> > there could
> > be many key management protocols with IKE as just one of 
> > them. IKE, then,
> > was supposed to be a generic key exchange protocol which could create 
> > "SAs" for multiple services, of which IPsec (specified in the 
> > DOI) was 
> > just one. But IKE is the only thing that used ISAKMP and the other two
> > DOI documents-- OSPF and RIP-- died a quiet death.
> > 
> >   The benefit of having this artificial layering is nil and the cost 
> > (the nuisance factor you mention, the conflicting verbage, 
> > the unnecessary
> > repetition of things, the incredible complexity it causes) is high so
> > it is being done away with. There should be only one thing 
> > that listens
> > on UDP port 500 and that is a key management protocol for IPsec which
> > should be described in a (relatively) short and concise draft. I'm 
> > working on it.
> > 
> >   Dan.
> > 
> > On Fri, 03 Aug 2001 15:29:09 EDT Henry Spencer wrote
> > > On Fri, 3 Aug 2001, Bill Sommerfeld wrote:
> > > > > Therefore, I would suggest that any effort in replacing 
> > IKE also consider
> > > > > replacing/rewriting portions of IPSEC DOI ...
> > > > 
> > > > Last I heard, the son-of-ike plan was to merge the DOI 
> > into the key
> > > > mgmt document.
> > > 
> > > Realistically, there's no meaningful distinction between 
> > IKE and the DOI.
> > > In fact, the separation between the two documents is a real 
> > nuisance when
> > > one is looking for obscure details.  They need to be 
> > considered as a unit.
> > > 
> > >                                                           
> > Henry Spencer
> > >                                                        
> > henry@xxxxxxxxxxxxx
> >