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

Re: anti-replay protection without IKE



>>>>> "John" == John Ioannidis <ji@research.att.com> writes:

 >> RFC 2401 hints that replay checking shouldn't be done for manual
 >> SAs, presumably on the theory that manual keys are likely to be
 >> long-lived.  However, there are

 John> I had missed that detail, but the explanation makes no sense.
 John> It's *especially* when we have long-lived keys that we want
 John> replay protection!

 John> On applications with manual keying, or non-IKE keying, maybe we
 John> want to allow turning off the replay protection, but I feel
 John> that it MUST be turned on by default.

Let's distinguish the two cases.  I think the existing text is for
manual keying, not "non-IKE" keying.  Non-IKE dynamic keying is
(presumably) already covered by the same rules that cover SAs created
by IKE.

 >> Should (or SHOULD) implementations permit such applications to
 >> request replay checking?

 John> I think that the phrasing should be "implementations MAY permit
 John> applications to turn OFF replay protection, but replay
 John> protection MUST be turned on by default."

Well, that would of course invalidate existing implementations...

Anyway, for truly manual keyed SAs, this is a bit problematic.  If
your keying state is non-volatile but the sequence state isn't (which
is a likely case) then after a reboot on one end the sequence checker
would throw out all traffic until you send as many packets as were
sent before the crash.

This may be a non-issue in some applications, so allowing sequence
checking to be turned on for manual keyed SAs makes sense to me.  It's 
not clear that it's the right default, though.

Also, if it's turned on then the SA should either go away or become
non-operational when the sequence number hits 2^32-1.

	paul


References: