[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



Thanks for the help. I will add your suggested clarifications to the next
draft.

> >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.

OK. 

> >> 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?

Anyone? I do not know if this is -actually- negotiated, Hillary?

> >> 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.)

OK.

> 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).

Good idea. Once and a while when the quick check fails, do the complete
check... Interesting... Hmm...

> Thomas

Thanks!

jim.