Thanks for the reply Patrick.
Does this mean that as things stand, if I wait more than 30s between seeding
the RNG and starting IPsec then I'll always get different traffic keys?
On 24/07/07, Patrick Ma <patma@...> wrote:
> There is a hard coded 30 second timer in the kernel that kicks off phase
> 1 negotiations.
> *From:* ipsec-tools-devel-bounces@... [mailto:
> ipsec-tools-devel-bounces@...] *On Behalf Of *ythhaj
> *Sent:* Monday, July 23, 2007 5:44 PM
> *To:* ipsec-tools-devel@...
> *Subject:* [Ipsec-tools-devel] Same traffic keys
> 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
> 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?
> PS Still not had the software rebuilt by our suppliers to check whether
> that patch solved the racoon startup delay problem.