NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: bin/18331: racoon doesn't keep SAs in sync
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
Home |
Main Index |
Thread Index |
Old Index