Hi, On Wed, Aug 06, 2014 at 02:12:12PM +0200, David Sommerseth wrote: > Just thinking aloud now, without many filters enabled. (read: uh-oh!)
:)
> The encryption and decryption using symmetric keys are really fast.
fast, but used very very often...
> What is CPU intensive is when asymmetric encryption comes into play,
> with the key exchanges and other negotiations etc.
slow, but used much more seldom... assuming VPN clients that stay
connected for a reasonable amount of time, and transfer "enough" data.
> 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.
My rough idea was something like
- one control thread doing the IP routing and "client connection maintenance"
- one group of threads to do "decrypt incoming packet"
- one group of threads to do "encrypt outgoing packet and send away"
and of course the "control thread" could split off the asymmetric crypto
to yet another thread... this should be sufficient to at least utilize
a few more cores, until we get to bottlenecks in the central thread.
> 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.
Yep. Something like that :-)
Nice design, now it just needs to be done...
> 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?
Hehe, something left for 2.7, I'd say :-)
gert
--
USENET is *not* the non-clickable part of WWW!
//www.muc.de/~gert/
Gert Doering - Munich, Germany g...@greenie.muc.de
fax: +49-89-35655025 g...@net.informatik.tu-muenchen.de
pgpbL0_vYtNv_.pgp
Description: 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
