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

Michael Richardson mcr at sandelman.ottawa.on.ca
Wed Jul 13 22:22:03 CEST 2005


>>>>> "Daniel" == Daniel Djamaludin <danield at snapgear.com> writes:
    Daniel> Hello,

    Daniel> Does anyone know the background as to why pluto needs to
    Daniel> have the configuation read by the ipsec configurator and
    Daniel> then passed onto whack which then prods pluto? I'm curious
    Daniel> as to why pluto wasn't designed to just read the
    Daniel> configuration files for itself and any changes to the files
    Daniel> to be updated with a SIGHUP signal. Is there something
    Daniel> fundamental to the behaviour of pluto that I'm missing here?

  Yes, there are three things you are missing:

  a) history.
  b) IPC.
  c) security.

  The SIGHUP method is certainly one way, but in many cases, you want to
create a new policy dynamically (i.e. through some programmatic
interface), and feed the result to pluto.

  The alternative is that you have to run sed/awk/perl on the
configuration files, and that really sucks.  

  Once you decide that you want to have an IPC interface for
programmatic policy, you might as well have that interface be the
primary interface for all things.

  There is some additional history involving preferences of people who
worked on the FreeS/WAN project in its early days. I won't go into this
part, but it explains the use of awk.

  There are additionally some security advantages to removing
configuration file parsing from the daemon --- or at least having very
clear interfaces between the two pieces.

  There is no requirement that you have configuration files at all. If
you want to store configuration in a SQL database, or an XML file, and
translate it to the whack interface (either command line, or libwhack),
you are free to do so. That's probably smarter than writing a program to
write ipsec.conf files from the database (which many people have done).

  You will see programs/starter, which is a C/bison/flex parser for the
configuration files.  It is a work in progress, and something we'd like
to have the resources to finish. Some people use it, but it is not
possible to express all current policies with it.

  In particular, we still want to be able to dynamically load new
policies. This raises issues of synchronization --- when you SIGHUP the
"starter" program, should it remove the dynamic policies?

  So, our goal is that we will progress to obsoleting the scripts, and
then have starter/whack/pluto. Later on, starter will become a library,
and may get incorporated into pluto.  It will use the whack interface,
however, it will be, I guess, "Intra-process communication".

- -- 
] Michael Richardson          Xelerance Corporation, Ottawa, ON |  firewalls  [
] mcr @ xelerance.com           Now doing IPsec training, see   |net architect[
] http://www.sandelman.ca/mcr/    www.xelerance.com/training/   |device driver[
]                    I'm a dad: http://www.sandelman.ca/lrmr/                 [

Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys


More information about the Dev mailing list