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

Re: Position statement on IKE development



On Sun, Aug 05, 2001 at 09:59:56PM -0400, Andrew Krywaniuk wrote:
> Okay, the first thing to do is **DON'T PANIC**.
> 
> The opinion in this document is not new. In fact, this moratorium on IKE
> development has been in place for more than a year already, as I
> specifically remember Ted talking about it at the Adelaide meeting. The fact
> that the opinion of the ADs has suddenly been put in writing and posted to
> the mailing list is no reason to get excited.

Indeed.  Nothing really has changed here.  My understanding is that
the note from the IESG/IAB this is more of a reminder more than
anything else.  It was explaining the reasons for the moratorium, 

Specifically, we do have permission to go ahead with making interim
modifications to IKE, which need badly fixing in the short term:
specifically in the NAT/Firewall traversal and support for SCTP.  But
all other changes are to be shunted to "son of IKE", and even there
the focus is on making the protocol work, and be simpler and easier to
understand/analyze, and not add the kitchen sink in terms of feature.

As far as user authentication and dead peer detection, part of the
problem with those items is that there has *not* been consensus, and
in fact there's been a fair amount of controversy, about what's the
best way to handle these items.  People have sketched out solutions
for user authentication that don't require changes to IKE, and that
work is properly scoped to the IPSRA working group (and not "son of
ike").

Dead peer recovery probably will be within in the scope of "son of
ike", but here again there has been controversy about how is the best
way of solving the problem.  One advantage about "son of ike" allowing
protocol changes (but likely requiring that the changes be
"implementation preserving"), is that there may be more latitude to
solve this particular proble right, instead of kludging around things.
I will note that there have been many different proposed solutions to
solving this particular problem, including polling/heartbeat
mechanisms, authenticated birth/death certificates, etc.  

							- Ted


References: