[AusNOG] IPSEC time skew renegotiate?

[Justin Clacherty]

> -----Original Message-----
> From: AusNOG [mailto:ausnog-bounces at lists.ausnog.net] On Behalf Of
> Mark ZZZ Smith
> Sent: Tuesday, 7 January 2014 6:43 AM
> To: Mark ZZZ Smith; Jake Anderson; Geordie Guy
> Cc: <ausnog at lists.ausnog.net>
> Subject: Re: [AusNOG] IPSEC time skew renegotiate?
> > I'd think it is unlikely that NTP is moving time backwards. Time sync
> > done properly always moves time forwards, just not necessarily at the
> > same rate as real time until time is synchronised (which is why people
> > shouldn't do timesync by putting 'ntpdate' in a cronjob.)
> >

Been a while since I've looked at ntp but as far as I'm aware you've described ntpd correctly. It effectively slows down a clock that's running fast.  If there is a very large jump then it may set it back but this wouldn't happen every half hour.  Generally once it's been running for a while and decides it's synchronised that means it's worked out the characteristics of your clock wrt ntpd's clock sources and is automatically adjusting the clock in the kernel.  In this instance you should see very small jumps (if any) each time ntpd runs and ntpd just keeps re-characterising the clock (it will drift differently with time and temperature) and rewriting the hardware clock (which will skew differently again).

There are however some embedded implementations of ntpd that don't do things this way, they basically jump back by the full amount (or some portion of it) each time it's run.  If you are consistently seeing similar drift then chances are you're running one of these versions of ntp.

> >
> > If the session key lifetime is 3600 seconds that does suggest the time
> change is
> > the cause. I seem to remember one of the signs of a good IPsec
> implementation
> > was that it did a make-before-break switch over of session keys to avoid
> packet
> > loss, so if these netscreen ones are good ones, I think it does further
> support
> > the time change being the cause, because even the make-before-break
> isn't
> > hiding loss.
> >
> 
> Actually, thinking about it more, I don't think the clocks being synchronised is
> a requirement, just that they run at the same rate (i.e., a second is a second).
> They know when to change session keys because when new session keys
> start to be used, that provides a synchronisation point in time, and know
> they will need to change keys at e.g., now+3600 seconds.
>

Doesn't the key lifetime basically say this is the maximum lifetime I'll accept and then adds in some level of hysteresis for the renegotiation?  i.e. it will renegotiate at 3500-3599 seconds.
 
Justin.