[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: compliance question
Dan,
>A question for the protocol police. Section 3.3.3 of RFC2406 says:
>
> The sender assumes anti-replay is enabled as a default, unless
> otherwise notified by the receiver (see 3.4.3). Thus, if the counter
> has cycled, the sender will set up a new SA and key (unless the SA
> was configured with manual key management).
>
> If anti-replay is disabled, the sender does not need to monitor or
> reset the counter, e.g., in the case of manual key management (see
> Section 5). However, the sender still increments the counter and
> when it reaches the maximum value, the counter rolls over back to
> zero.
>
>Ignoring for the sake of a question whether disabling anti-replay is
>smart or not, would an implementation be conformant if, when anti-replay
>is disabled, the sequence number rolled over to zero prior to reaching
>it's maximum value? That is 1, 2, ... 2^5, 1, 2, etc.
If we adopted a way for the sender to be told by the receiver that it
did not care about anti-replay, then it would seem reasonable to
ignore the transmit counter value and allow it to rollover. But, for
now, this behavior would be non-compliant. For some algorithms and
modes, e.g.g., single DES in CBC mode, 2**32 packets is a good limit
and most easily enforced by the counter, irrespective of anti-replay
concerns, so we should be aware that we would be giving up this
feature if we adopt this approach. However, if we depricate the use
of single DES and move to AES, as expected, this might become moot.
Steve
Follow-Ups:
References: