[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
comments on replay processing
[In response to Steve Kent's observation that I may have recalled the WG
discussion inacurately, I originally was going to go back and check the
archives to find my error, but then I decided it would be more productive
to simply state my opinion. I'm *not* trying to change anything here, so
if I've messed up something relative to the current draft set, it's my error.]
For Receiver Sequence Number Processing, I think that what we should have is:
1. receiver extracts sequence number from the packet
2.1 if sequence number is NOT within the current expected range
then
2.2 take action because a replay attack may be underway
else
2.3 life goes on
Now I don't think the 'action' at step 2.2 is standardized in the draft, I
think it's a local implementation issue. One might delete the SA, call out
the Marines, dump core and halt, output a mild message to the operator
console, output an SNMP Trap, etc. etc.
I specifically don't think the 'action' is required to include any feedback
to the sender. Therefore, I don't think there is any way the sender is
aware of receiver replay processing. This includes any knowledge of what the
receiver's replay history size is. Furthermore I don't think there is
anything
the sender could do about it. Since there is no feedback in the 'normal' case
and no feedback in the case of an asynchronously deleted SA, I don't see what
reaction, negative or positive, the sender can have. I think the receiver
should
always implement replay checking. If we think this is a safety thing, then we
should require it.
I don't think the issue is whether or not we can wiggle
the DOI by adding another parameter number. The issue with ISAKMP is that
adding an interaction increases the complexity of an already complex
situation and I don't think we should be doing that.
Furthermore, whether my opinion is something people agree with or not I
don't think we should be modifying the ISAKMP message traffic at this stage
in the document process -- I think this is a fine item to put on the
"Useful but not Criticial Path" list.
Follow-Ups: