[Openswan dev] Network Time Protocol and openswan

[Paul Wouters]

On Thu, 11 Sep 2008, hiren joshi wrote:

> I want to implement Network Time Protocol client on a machine running openswan.
> 
> NTP client corrects the time by *SETTING* it if the time drift is > 43 seconds.

You realise that ntpd drifts time towards the correct time for a reason?
Doing large steps in time is not recommended, precisely because of issues
you describe below.

> With the parameter: ikelifetime
> 
> Test case: Advance the clock by few seconds
> ikelifetime(x) = ikelifetime(y), rekey(x) = yes, rekey(y) = no,
> rekeymargin(x) = rekeymargin(y) = 1, nodpd, tunnel initiator: y
> Observation: For existing SA, openswan sends delete SA payload to peer
> early and starts negotiating new SA

early? Did you account for rekeyfuzz= ?

> Test case: Delay the clock for few seconds at x (x, y: IPSec Peers)
> ikelifetime(x) = ikelifetime(y), rekey(x) = yes, rekey(y) = no,
> rekeymargin(x) = rekeymargin(y) = 1, nodpd, tunnel initiator: y,
> Observation: Peer sends delete SA payload, SA is deleted and not re-negotiated .
> Analysis: As peer was set rekey=no and perhaps we have no renegotiate
> event pending for the SA as the SA itself is deleted, there was no
> renegotiation from either side.

Does (x) have auto=add or auto=start? When using auto=add, when the SA
is deleted, no new one is created. Perhaps you need to do your tests
with auto=start and rekey=yes, and perhaps set rekeyfuzz=0% to not
confuse the timings?

> Also tested the behavior for DPD:
> Advancing time results in early declaration of peer as dead.
> Delaying the time results in late declaration.

I am not sure if I agree with "early". Time did advance after all.

> Please let me know if there is anything in the roadmap that will make
> openswan resilient to time change.

There is nothing planned, and at this stage, I am not sure if I agree
with you that there are problems.

Paul