[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: replay window
Stephen Kent wrote:
> I don't have a proposed algorithm for calculating a replay window
> size; I'm just concerned that we not pick a single, universal value at
> this time. However, I do feel that the size of the window ultitamely
> should be controlled by the receiver, since that's where the work is done.
> So, "negotiation" may be a misnomer here. One could begin by having a
> receiving implementation always insist on a fixed window size, irrespective
> of the request from the sender, and that would be compliant. At least this
> allows for changinf your implementation in the future but advertising the
> change, rather than having it be a locally defined mystery.
I am a little bit late in joining this discussion, so perhaps I missed some
arguments that were already used. If you happen to have a look at the
internet draft '*-esp-stream-01.txt', (which has a very ugly weakness (inherent
in using stream ciphers) that was first reported by Angelos, and on which I
will write something RSN :-( ), you will find some practical limits in
section 6.1 esp-stream does *not* do any negotiation of the replay window
size. The reason for this is that the decision how big the window actually
needs to be is mostly receiver-dependant in environments where lower layer
QoS can not be determined. A receiver can monitor the behaviour of its
associations, and 'fix' the window size to achieve best performance /
resource consumption. On the other hand, if the sender fears about the time
data may be 'unobserved', it just needs to change the packet key. No big
issue, and no need for any form of negotiation there.
Comments?
Germano
References: