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

Re: compliance question

  Steve,

  A way to tell a peer in a standards-compliant manner already exists.
RFC2407 defines a REPLAY-STATUS notify message that IKE can use to
tell a peer whether or not it has anti-replay enabled for a particular
SA (it's chained onto a Quick Mode message ala RESPONDER-LIFETIME).
I don't know how many people actually implemented it though. The default
is to assume anti-replay is enabled so the only use of REPLAY-STATUS
would be to support something that we all acknowledge is generally 
not a good idea to do. 

    Dan.

On Mon, 29 Jan 2001 16:02:28 EST you wrote
> 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: