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

Re: comments on replay processing



Rodney,


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

Ah and ESP call for auditing the event but recommend not taking any action
that could be exploited as a denial of service opportunity. So these specs
are not completely silent on the subject of what action to take.  The
sender may very well have feedback if legitimate packets are being dropped,
e.g., if TCP is being used retransmissions will indicate packet loss, but
not tell us where the loss occurred.  Having knowledge of the receive
window size might help in this fault isolation, as I mentioned before.

Steve




References: