[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Last Call: Combined DES-CBC, HMAC and Replay Prevention Security Transform to Proposed Standard
>The appendix A code is relative to 0, not the actual value starting value,
>therefore, before calling the routine in Appendix A, RP_key_I must be
>(unsigned) subtracted from the count of a given received packet.
Sounds good. Just be sure to add some text saying this, as it wasn't
obvious to me at first.
>> On another point that others have brought up, I don't see the value of
>> having a *negotiated* replay window. I think its reasonable for the
>> receiver to have one, but for the sender to know what its size is
>> implies that the sender would (for some reason) find it useful to send
>> (slightly) out of sequence packets and derive some sort of benefit. I
>> don't have a clear sense of why a sender would do that and what
>> benefit it would derive.
>If you are sending bridged packets, the sender may want to force the
>receiver to have a 0 window size, that it does not accept any out of order
>packets. It was added after a vote at a meeting. I did not propose
>it.
Could someone provide the rational and add a few motivating lines to
the text? It's come up enough times on the list that its usefulness is
clearly not obvious to everyone. Plus, the bridge example seems
bizarre to me. When does a sending node know that there are bridges in
between it and the ultimate recipient? If it doesn't know, how can it
take advantage of the (optional) window?
>Lets now take a -fresh- look at the optimization and forget what the draft
>says or what the previous email said.
Good explanation.
>> Under what conditions would it be correct to reject a packet with a
>higher
>> sequence number than seen so far?
>When the count has moved up by X or more packets.
But there are also scenarios where count will have increased by X or
more legitimately (though I agree that this will not be a common
case). So from a correctness perspective, it's not 100% clear that one
should always perform this check.
I'd like the document to explain the pros and cons of doing the check,
so that an implementor can make an intelligent choice. The quick check
is just to help deal with denial of service attacks. It is not needed
for correctness, and can in fact lead to cases where legitimate
packets are dropped (and all subsequent communication fails until a
new SA is negotiated). If you end up leaving the text in the draft,
I'd suggest adding a few sentences making this motivation more
clear. (The step is optional.)
There are also other tricks that could be employed to reduce the
damage of denial of service attacks that wouldn't have the same
problem. For example, keep track of the rate at which packets aren't
authenticating properly, and when the rate exceeds some threshold,
take more agressive action (like using the quick check on 95% of the
packets, but still doing the full check every once in a while).
Thomas
References: