[Openswan dev] Why does pluto need ipsec and whack?

[Henrik Nordstrom]

On Thu, 14 Jul 2005, Daniel Djamaludin wrote:

> Does anyone know the background as to why pluto needs to have the 
> configuation read by the ipsec configurator and then passed onto whack 
> which then prods pluto?

That way no config file is really needed, just pluto and whack and a few 
other small glue pieces.

> I'm curious as to why pluto wasn't designed to 
> just read the configuration files for itself and any changes to the 
> files to be updated with a SIGHUP signal.

Pluto is designed to be online controlled by whack alone.

Implementing a good "SIGHUP" is far from trivial as you must then 
carefully compare what has changed and take appropriate actions. With the 
design taken bu pluto + whack the implementation in pluto is greatly 
simplified by infact instead asking the administrator to indicate what 
parts have changed.

In addition, a "SIGHUP" based design makes it very hard to make dynamic 
updates as the whole configuration needs to be reloaded on each and every 
change.

> Is there something fundamental to the behaviour of pluto that I'm 
> missing here?

It's a design of clean layers. Makes the whole system very easy to 
costomize and a great power imho.

* Kernel IPSec for handling established SAs.

* Pluto running IKE and controlling the kernel SAs. Also uses glue scripts 
to manage routing etc as desired when installing/removing the SAs. By 
default using routing scripts from the configuration scripts package, but 
these may be replaced if needed.

* whack controlling Pluto.

* configuration scripts automating the whack calls, and some related glue 
for starting/stopping pluto etc.

* configuration file acting as a data source for the configuration scripts

In our IPSec design based on Open-S/WAN 1.x we decided not to use the 
configuration scripts or configuration file at all. Instead the 
configuration part is dynamically driven by our system configuration 
database, and pluto is dynamically reconfigured as needed. Due to the 
"appliance" nature routing is also done quite differently than what you 
would do on a normal system and thanks to the up/down scripts design used 
by pluto it was very easy to fit. There was some minor tweaks we had to do 
to make the startup of pluto behave nicely without too gross race windows, 
but nothing major. More information can be found in the archives from 
"Super-FreeS/WAN" time or http://marasystems.com/download/freeswan/

We are now planning to upgrade our integration to the current OpenS/WAN 
2.x, and it will be interesting to see see what falls out from that 
effort.

Regards
Henrik