Re: bin/18331: racoon doesn't keep SAs in sync

[Martin Neitzel <neitzel%gaertner.de@localhost>]

The following reply was made to PR bin/18331; it has been noted by GNATS.

From: Martin Neitzel <neitzel%gaertner.de@localhost>
To: M.Drochner%fz-juelich.de@localhost
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: bin/18331: racoon doesn't keep SAs in sync
Date: Fri, 10 Oct 2008 03:20:49 +0200

 Just a few thoughts on this (old) PR...
 
 You wrote right at the beginning:
 > This is easily triggered by (if not caused by) a time jump backwards
 > on one system.
 
 Yepp.  IPSEC relies on stable clocks.  If you make the system clock jump
 backwards, apparently one side will suddenly compute a lifetime value
 of a key to be negative or "rolled-over", at any rate out of bounds,
 and hence whack the SA.  You can see this nicely in all eight laptop
 log msgs starting right at the clock reset from 15:24:17 to 15:23:18.
 
 I'm not at all sure whether the "pfkey.c:1365:pk_recvexpire():" refers
 to a packet received from the remote or the local side but as far as I
 can see it racoon just reacts here.  I'm rather an IPSEC newbie and just
 guessing here: Could it be that the laptop kernel notices the "timeout"
 and withdraws the SPI but the other side doesn't?  And that the unilateral
 withdrawel is perhaps not communictated to the other side because each
 side is supposed to take care of expirations autonomously?
 
 I wouldn't be suprised if things work here just as designed.
 
                                                Regards, Martin Neitzel