[AusNOG] IPSEC time skew renegotiate?

[Mark ZZZ Smith]

----- Original Message -----
> From: Mark ZZZ Smith <markzzzsmith at yahoo.com.au>
> To: Jake Anderson <yahoo at vapourforge.com>; Geordie Guy <elomis at gmail.com>
> Cc: "<ausnog at lists.ausnog.net>" <ausnog at lists.ausnog.net>
> Sent: Tuesday, 7 January 2014 7:28 AM
> Subject: Re: [AusNOG] IPSEC time skew renegotiate?
> 
> 
> 
> 
> 
> 
>> ________________________________
>>  From: Jake Anderson <yahoo at vapourforge.com>
>> To: Geordie Guy <elomis at gmail.com> 
>> Cc: "<ausnog at lists.ausnog.net>" 
> <ausnog at lists.ausnog.net> 
>> Sent: Tuesday, 7 January 2014 12:03 AM
>> Subject: Re: [AusNOG] IPSEC time skew renegotiate?
>> 
>> 
>> 
>> Some applications don't handle a negative time increments well, its not 
> intuitive to think and then handle time going backwards.
> 
> 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.) 
> 
> 
> I'm getting rusty on IPsec (I worked with it in 2001/2002), however IIRC 
> literal wall clock time synchronisation wasn't critical to it. However, the 
> clocks do have to be synchronised so that the peers switch to new session keys 
> at the same time, so they both should be using the same time source. 



> 
> 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.

> So I'd suggest the first step is to make sure both of the IPsec gateways are 
> using the same NTP server.
> 

I'd still try to do this though, I think it would definitely indicate if time/clocks are a contributing cause.

> 
>> IE they may say use an unsigned int to hold the last time
>> uint_elapsed_time = current_time - uint_start_time
>> becomes hinkey when last time is > current time, it'll either
>       error out or wrap and give you an elapsed time that's really huge.
>> 
>> 
>> On 06/01/14 21:28, Geordie Guy wrote:
>> 
>> It's always negative. Is that a thing? May need to read up more...
>>> 
>>> On 06/01/2014 8:17 PM, "Jake Anderson" 
> <yahoo at vapourforge.com> wrote:
>>> 
>>> Is the time adjustment perhaps negative and its causing something to 
> flip out thinking its waited longer than the life of the universe for the next 
> key?
>>>> 
>>>> On 06/01/14 14:09, Geordie Guy wrote:
>>>> 
>>>> G'day NOGgers, 
>>>>> 
>>>>> 
>>>>> We have an IPSEC peer that keeps dropping the tunnel and 
> renegotiating. The only events in the logs on their side that look like they 
> could be related are a fairly constant NTP update which is causing their 
> Netscreen to adjust by between 3 and 13 milliseconds every ten minutes.  Would 
> this cause the tunnel to renegotiate when the clock changed?  It seems to happen 
> on the half hour every half hour, or every three NTP updates.
>>>>> 
>>>>> 
>>>>> - Geordie
>>>>> 
>>>>> 
>>>>> _______________________________________________
> AusNOG mailing list AusNOG at lists.ausnog.net 
> http://lists.ausnog.net/mailman/listinfo/ausnog 
> 
>>>> 
>> 
>> 
>> _______________________________________________
>> AusNOG mailing list
>> AusNOG at lists.ausnog.net
>> http://lists.ausnog.net/mailman/listinfo/ausnog
>> 
>> 
>> 
> _______________________________________________
> AusNOG mailing list
> AusNOG at lists.ausnog.net
> http://lists.ausnog.net/mailman/listinfo/ausnog
>