[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec-tools-devel
Subject:    [Ipsec-tools-devel] concurrency problem with pfkey_dump_sadb
From:       Ryan Melendez <rmelendez () wayport ! net>
Date:       2007-04-23 23:11:59
Message-ID: 1177369919.6409.150.camel () rmelendez ! aus0 ! tx ! us ! corp ! wayport ! net
[Download RAW message or body]

Hear Ye! Year Ye!  Your feedback is greatly appreciated.

First you would probably only see this issue on a system like mine with
plenty security policies and remote hosts.  I've got ~4000 policies and
~2000 hosts.  It goes like this:

Racoon is started, creates a pf_key socket, requests all security
policies and processes them with the pfkey_handler.  This can take a
couple of minutes with such a large number of policies.  After the
entire SPD is processed racoon carries on processing acquire messages
and initiating key exchanges.  Unless....

The problem comes when isakmp_handler triggers a call to pfkey_dump_sadb
and a pfkey_send_dump down the same pf_key socket. (This happens quite
often with ~2000 hosts) pfkey_dump_sadb recv messages in a while(1) and
discards everything but SADB_DUMP, until there are no more SADB_DUMP
messages left on the buffer.  So all SADB_X_SPDDUMP that _were_ on the
buffer are lost.  It's not such a big deal with other types of messages
because they would just be sent again,but racoon does not recover the
SPDDUMP messages.


So you can restart racoon hoping you won't get another pfkey_dump_sadb
or load the SPD with setkey hoping the racoon pf_key buffer has enough
room for all the SPD_ADD messages that setkey will put on the socket.
If the kernel is processing packets that match the SPD when racoon is
starting with so many SP the socket can grow up to ~9MB before racoon
has processed all the SP.  (I have modified the buffer size accordingly)


Given the automation required on my system I need something a little
better. I have considered:

1)Using a dedicated socket and handler for security policies.

2)In pfkey_dump_sadb process both SADB_DUMP and SADB_X_SPDDUMP messages

3)SPDGET message in the case the kernel sends a spid not in the racoon
tail queue.

I implemented all three of the above, and had success with #1 #2.  I ran
into a problem with 3 whereby the kernel will only pass along the 'out'
policy and I have no way to determine the 'in' policy which I also need
to SPDGET.


Given the somewhat random nature of this problem it was not easy to
reproduce so I spent quit a bit of time debugging.  I appreciate your
feedback.


-- 
Thanks,
Ryan

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Ipsec-tools-devel mailing list
Ipsec-tools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel
[prev in list] [next in list] [prev in thread] [next in thread]