Dynamic skew (Re: review of Projects/replay_cache_collision_avoidance, ending Jan. 12)

[Nicolas Williams]

On Tue, Dec 30, 2008 at 04:04:34PM -0500, Ken Raeburn wrote:
> You also need to make sure you don't get confused in the case where  
> the boot-time clock value is bogus, and later corrected by NTP, so  
> that time()-boot_time may be significantly different from  
> seconds_since_boot.  (Or, explicitly decide that you will trust the  
> system clock to be accurate at startup.)

Right.  Getting the correct time portably is going to be difficult, and
best left to OS vendors/distros.

The glue OS vendors/distros would need is this: an API (or CLI) to
create an rcache with a given initial time skew other than zero.

Thus all you giuys would have to do is: a) provide a way to record the time
an rcache was created and its initial time skew, b) always defaulting the
latter to zero, and c) an option to control whether to fsync() the
rcache, defaulting to yes.

OS vendors/distros could then change the default of (c) if they ensure
that any abrupt time synchronization completes prior to any krb5
services coming online.  And they could provide for non-zero initial
time skew by doing additional OS-specific work.

BTW, any time that the local clock changes abruptly there is an impact
on the rcache, but RFC4120 does not mention this, probably because such
changes are very rare post-boot, but it's important to make any abrupt
clock synchronization at boot time before starting any time-sensitive
services.

Nico
--