-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 06/08/14 11:34, Gert Doering wrote:
> Hi,
>
> On Tue, Aug 05, 2014 at 03:21:39PM -0500, Les Mikesell wrote:
>> I don't know enough about the rekeying process to know it this
>> is feasible, but it seems like there should be a way to use
>> something like apache's prefork model to spin off some number of
>> processes to do the cpu-intensive parts without a lot of change
>> to the base code or the complications of making everything
>> thread-safe. And let the OS spread the processes over different
>> CPUs.
>
> Each worker needs to know about SSL state, replay protection, IP
> routing information, etc. - so it won't be much easier than careful
> usage of threads for stuff like "here's a packet, go decrypt and
> hand back to me for routing" or "here's a packet, go encrypt and
> stuff down *that* socket".
Just thinking aloud now, without many filters enabled. (read: uh-oh!)
The encryption and decryption using symmetric keys are really fast.
What is CPU intensive is when asymmetric encryption comes into play,
with the key exchanges and other negotiations etc. The data channel
(the network payload tunnelled over the VPN) uses symmetric
encryption, and all new connections and re-keying processes uses
asymmetric encryption, to agree upon a new symmetric encryption key.
With this in mind, it does make sense to split out the asymmetric
encryption phases to a separate core, which can allow other symmetric
encrypted traffic to flow more freely.
But, this is just splitting stuff into 2 threads. Any modern
computers doesn't really have that *few* CPU cores. (Even cellphones
seems to have at least 4 cores these days). So even though the
benefit of using 2 threads will be noticed, it can be done better.
What *if* there are 3 "thread groups"? One of these groups is a
single thread which is a SSL state manager. It keeps tracks of all
keys being used, and which state each client is in. Then there is a
"thread group" with symmetric encryption work, which basically does
the real tunnelling and takes care of the network traffic flow. But
it receives the keying material from the SSL state manager thread.
And then last "thread group" is the one taking care of asymmetric
encryption and the key negotiations.
On an 8 core box, it could scale out like this:
1 SSL state manager
4 Asymmetric encryption threads
3 Symmetric encryption threads
A 4 core box would then be simiar, just 1, 2 and 1 threads.
But! This is going to be a h*** of a lot of work. And almost
everything regarding the event management/scheduler and SSL code in
OpenVPN will be completely rewritten. In addition, it'll be a lot of
fun with the plug-ins and script support.
The advantage, how I see it, is primarily with SSL manager
process/thread. The SSL manager thread can be completely locked down
and only be accessible via a kind of internal API. *IF* this manager
thread can be a separate process, it can also be possible to lock it
down further (running as a different user than the other threads, on
Linux SELinux can further restrict its possibilities). In addition
this move can enable clustering support, where you can more seamlessly
move clients from one physical OpenVPN server to another one. The SSL
manager can exchange information through a local multicast network
with the other cluster member's SSL manager. However, one of the real
tricky things here is: How to tackle plug-ins and scripts when a
client moves from one box to another one?
Anyhow, clustering is far outside the scope of threading in OpenVPN.
But with a good thread design, this can be more easily be added later on.
<end_of_brain_dump/>
- --
kind regards,
David Sommerseth
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlPiG5wACgkQDC186MBRfrrutwCglGcsGJAyihSD6TgcTQpioww7
3icAn3oChT/tqwSHpXmWXGStPdatlNzt
=azen
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls.
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071&iu=/4140/ostg.clktrk
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
