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

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



> > I disagree here. The time to weigh technical merit is
> BEFORE the protocol is
> > standardized and everyone has implemented it.
>
> IKE is only a Proposed Standard at this time.

I think we're confusing English and Jargon again. RFC 2026 defines the terms
"Proposed Standard" and "Internet Standard," not the word "standardized."

You are free to write a draft proposing this behaviour for IKEv2 (or
IKEv1.1), but this is not the correct way to modify IKEv1.


> > I also believe that this violates the design principle
> which mandates that
> > Alice should not be able to force unbounded state creation
> on Bob's machine.
>
> Your belief is incorrect.  As we have pointed out --
> repeatedly -- if too
> much state accumulates, Bob rekeys (that is, replaces) the
> ISAKMP SA, at
> which point all saved state related to the old one can be discarded.

Replacing unbounded state creation with unbounded rekeying frequency is no
solution. Fine, so this problem is kind of academic, but you are endagering
the ability of a host to be fully self-stablizing (and that is of academic
interest to me).


> As we have pointed out -- repeatedly -- our interpretation has
> demonstrated interoperability with a wide variety of existing
> implementations.  This is not theory, but established fact.

You don't interoperate with people in this regard; you just think you do
because this situation (a collision in 2^32) rarely happens. That's like
saying your implemetation of DES40 is interoperable: no one ever proposes it
and you never accept it.


> Given the length of the lists involved -- tiny -- either
> approach will be
> totally dominated by fixed overhead anyway, unless you're
> doing something
> very strange.

I reserve the right to do something strange.


> > I've often you heard you say (or maybe it was Hugh) that an
> implementation
> > should be allowed to ignore notify and delete messages
> since there is no
> > guarantee of delivery. Is the implementation required to
> keep track of of
> > the message ids from packets it may never receive?
>
> It keeps track of the ones it receives, and not the ones it
> doesn't receive.
> Can we try to keep this discussion serious?

If an exchange times out or a packet is dropped then the peers may not agree
as to which message ids have been used. Now there is potential for one of
the peers to detect a spurious replay attack (and reject legitimate
packets).

You already conceded that maybe this technique would have to only apply to
QMs, since notifies carry no guarantee of delivery. (So already your
convention is of limited usefulness.) But it is also possible for a QM
negotiation to fail prematurely. What do you do then?

A better solution than the one you propose, the use of a counter (a
well-known anti-replay mechanism), has already been discussed on this list.
If we do decide to add such a feature to IKEv2, I don't see why we would go
with your suboptimal technique.

Andrew
--------------------------------------
Beauty with out truth is insubstantial.
Truth without beauty is unbearable.



Follow-Ups: References: