There is a hard coded 30 second timer in the kernel that kicks off phase 1 negotiations.
 
http://lists.openwall.net/netdev/2007/05/25/14


From: ipsec-tools-devel-bounces@lists.sourceforge.net [mailto:ipsec-tools-devel-bounces@lists.sourceforge.net] On Behalf Of ythhaj khkci
Sent: Monday, July 23, 2007 5:44 PM
To: ipsec-tools-devel@lists.sourceforge.net
Subject: [Ipsec-tools-devel] Same traffic keys

Hello

I can semi-reliably power up my IPsec devices and get the same traffic keys. That is, I run setkey -D once the network is passing ESP packets and I note down the output. Then reboot and find that setkey -D gives identical keys.

For these tests, timing is important. I have to begin a ping from one laptop through the IPsec tunnel to a distant laptop at the same time as I power on both IPsec devices. I can get the same setkey -D output about 80% of the time if I do this carefully.

These are the same boards I recently reported racoon taking 30s to become ready to handle traffic on. The specs are:
266MHz PPC, 128MB Ram, Flash storage, no keyboard, no mouse, no hard drive and no real time clock.

With such hardware we have a real problem getting random numbers out of the boards that are different on different boot-ups. We are running kernel 2.6.21 with the recent patchs that fix a partially broken /dev/random. Using scripts inspired by the urandom man page we cat some random data from a file into /dev/urandom. Tests as part of the boot scripts can then extract some random data from /dev/urandom and we see that the outputs are always different *provided* the data we use to seed the random number subsystem is different (and the same for the same data). Note that with a previous kernel, before the recent patches, we could get the same random numbers every time no matter what data we catted into /dev/urandom. Obviously the seeding process happens before we run setkey -f ipsec.conf and racoon.

Given that we know we can get random numbers from /dev/urandom it is alarming to get the same traffic keys.

We think that racoon gets its random numbers from openssl which in turn seeds itself from the linux random number system (the racoon debug logs hint to this). In which case, as we don't specifically run any openssl program when we boot up, when does this openssl seeding happen? Or am I misunderstanding the way this works?

I appreciate that this might not strictly be within the bounds of what the ipsec-tools software does but I wonder if you guys have any ideas about this issue? Am I simply missing a particular command and will be kicking myself after reading the first reply? Is racoon doing something wrong or is the blame more likely with openssl?

Cheers

RF

PS Still not had the software rebuilt by our suppliers to check whether that patch solved the racoon startup delay problem.