Re: problems with draft-jenkins-ipsec-rekeying-06.txt

[Dan Harkins <[e-mail]>]

  Yes, technical merit should guide resolution but it helps to have
the problem laid out first. This whole thing started with your
proposal that was a "better approach to certain parts of the rekeying
problem" that draft-jenkins-ipsec-rekeying-06.txt addressed. That
draft addresses _lots_ of issues. What certain parts are you resolving?

  The responder pre-set-up problem, which is what you seem to be
focusing on, is solved by using a CONNECTED notify. There is no "security 
hole" associated with this. There is only potential for a DoS attack. 
Nowhere in your proposal does it even discuss a DoS attack. So what is 
it you're solving? If the problem space has moved then let's take a 
step back and redefine what it is we're discussing.

  Maybe an even more *superior* solution would be what David Faucher
proposed: just make the MID a monotonically increasing counter and
don't accept anything <= the currently authenticated MID. But this
requires agreeing on what the problem is that the solution proposes
to solve. 

  Dan.

On Mon, 17 Jul 2000 18:36:03 EDT you wrote
> 
> Moreover, I think this has slightly missed our point.  We are not just
> arguing that there is a different interpretation possible here, or that it
> is the preferred interpretation in the absence of supplementary folklore
> (although we do make both those claims). 
> 
> We contend that our interpretation is *superior*.  It improves the
> protocol's robustness, and permits solving certain vexing problems in a
> much simpler way than Tim Jenkins proposes, and does this (as verified by
> both analysis and practical experience) without introducing significant
> implementation difficulties or interoperability problems.
> 
> The primary criterion for choice when resolving ambiguities should be
> technical merit, not closeness to the original intent. 
> 
>                                                           Henry Spencer
>                                                        [e-mail]
>