[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: problems with draft-jenkins-ipsec-rekeying-06.txt
> Mostly agreed.
>
> Given that we have an existing protocol with existing implementations,
> we should:
>
> a. Choose the meaning that "most" have used, if we can find it *and*
> if it is technically correct (i.e., secure),
>
> b. Failing that, choose a technically correct interpretation that's
> backwards compatible with most of the existing implementations, if
> there is one,
>
> c. Failing that, choose a technically correct interpretation (that's
> not backwards compatible).
>
> You left out (c) which is the last fallback, but you must have that
> one. (You can't choose backwards compatibility at the expense of
> security.)
Paul, I left out (c) for a reason. Fixing a bug in the protocol is not the
same as resolving an ambiguity. If this was truly a bug then I would
advocate changing the RFC to solve the problem, then advancing the IKE
version number and deprecating the old version.
Still, the fact remains that the purpose of message ids is to solve the
demultiplexing problem, not to prevent replay attacks. In fact, IKE does not
claim to offer a comprehensive solution to replay attacks. The fact that a
feature is missing from IKE does not give you latitude to invent it yourself
and claim it is part of the standard.
Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.
References: