[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems with draft-jenkins-ipsec-rekeying-06.txt
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
> henry@spsystems.net
>
References: