[strongSwan] PSK_with_ideal_keys, charon_crashes_with_8m_keylife_?

[o Encryptos]

Hello all,

It is my first post and I would like to thank the strongSwan creators and
all who contribute to this excellent suite of tools.
I've been watching almost all e-mails and I'm impressed by the almost
immediate response of Andreas, Willi, Tobias

I have a couple of questions:

Q1:
===
If someone could supply me with a group of a couple of thousands of
cryptographically ideal keys (statistically independent, FIPS 140-2, etc.)
and also guarantee that the keys could be safely distributed to all peers
then if I use these keys as PSK this is what really happens:

The PSK keys will be used to derive all SKEYSEED values SK_x but the actual
mathematical characteristics of the given group of cryptokeys will not be
inherited to the keys used by the CHILD_SA because DH is the base mechanism
for the creation of the "traffic keys".

How could I take advantage of the "given ideal keys" ?
Is it possible to use the DH derived keys as an index to the pool of those
"ideal keys"?


Q2:
===
I've been testing the following scenario:
(test
pc:192.168.123.23)->192.168.123.223---192.168.2.23===back-to-back===192.168.2.24---192.168.124.224->(test
pc:192.168.124.24)

After many hours (14h appx.) of continuous but low traffic (0.01%, that is
about 15 packets/sec),
I received the debug messages:

charon: 08[DMN] thread 10 received 11
charon: 08[DMN] killing ourself, received critical signal

while the configuration is like that:

config setup
      plutostart=no
      charonstart=yes
      charondebug=all
conn %default
        ikelifetime=1h
        keylife=8m
        rekeymargin=2m
        keyingtries=%forever
        authby=secret
        keyexchange=ikev2
        mobike=no
        esp=aes256-sha2_256-modp2048!
        ike=aes256-sha2_256-modp2048!
        inactivity=10m
conn net23-net24-1222
        left=192.168.2.223
        leftsubnet=192.168.123.0/24
        leftid=device23
        leftfirewall= yes
        right=192.168.2.224
        rightsubnet=192.168.124.0/24
        rightid=device24
        auto=route

I've seen the same messages (Bug#614105, regarding version 4.5.0-1)

but I'm using 4.4.1 and was quite stable from the beginning, even under
heavy stress
(rfc2544, tens of peers each with a couple of sub-nets)

Should I blame the short keylife (8m) ?
Is it possible that the rekey happens at 4m (rekeyfuzz=100%) and the time
left is not enough to make all calculations?


I would appreciate any help,
Best Regards,
Nikos
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20110321/63197b04/attachment.html>