[Openswan dev] Re: thoughts on openswan initscripts

[Paul Wouters]

On Sat, 21 Feb 2004, Bill Nottingham wrote:

> This is only different in nomenclature, though, if I'm understanding
> you right. The semantics are pretty much the same, yes? (i.e., it's
> one end of the connection)

It appears to be so, for the few options of racoon that I checked. I didn't
go fully into checking the X509/certificate things. For Openswan again, these
are tied to specfic directories. CRL's go into /etc/ipsec.d/crls, CA's go into
/etc/ipsec.d/cacerts/ etc. This should make live on your config-tool actually
much easier then supporting all kinds of arguments in ifcfg-*.
For instance, I don't think racoon supports multiple crl lists or multiple CA's,
but even if it does, someone would probably also store it somewhere in the
/etc/racoon/ directory, and not in ifcfg-* files.
Also, the PSK syntax is different. Openswan stores source-dest-secret
combinatins, while racoon stores them per source. I'm not sure if this means
you have to use the same PSK with all your tunnels.
Finally, I have a feeling the ifcfg configs are written with a "client" setup
in mind. What if I am going to have 250 point-to-point tunnels (for instance
to secure the local wireless /24 with wavesec)?
Another issue is some default tunnels we might want to ship. If we use 
/etc/ipsec.d/conns/ and include *.conf from there, we (or anyone else, such as
a company) can easily ship a conn by connname. Using ifcfg-* we have to be a
bit more careful about naming it.

> That's entirely possible, though. It's hard to write a generic
> infrastructure when only looking at one alternative at the time...

I am not trying to assign blame. I'm only interested in getting a working
solution :)
 
> > didn't work. The /etc/racoon/$DST.conf file could not be parsed by racoon)
> 
> Hm, haven't seen that in bugzilla (ducks).

jej jej :)
 
> Basically, it's simpler to just deal with the parameters that the
> network tool needs abstracted from the config file. This is especially
> true with something that can be manually configured to a much greater
> extent than what the config tool supports, such as IPSEC.

Perhaps for Racoon, but Openswan has so many options. It would become easier
to write/re-use a parser already written that reads ipsec.conf + includes.
Adding a middleware layer also adds maintanance and increases the chance of
someone making mistakes. 

 
> > So, what it boils down to I guess is this. Why don't racoon and openswan
> > just keep their tunnel configurations in their seperate files, in their
> > own syntax, in their own directory structure?
> 
> It's writing two backends for the network config tool, neither of
> which is there at the moment. Aside from that, it sounds fine. ;)
 
I can see the use of this middle layer if it would make the config-tool handle 
ipsec regardless of userland, but as I said before, I think that's an illusion.
People won't be able to switch based on a single IPSEC_USERLAND variable 
anyway. So I think we might as well skip the middle layer here.

> One of the features of the way it's written now is that the source
> address is computed automatically 99% of the time, so that shouldn't
> be a problem.

Openswan supports that too. With version 2 style ipsec.conf files, the
assumed default if unspecified is "interfaces=%defaultroute" and 
"left=%defaultroute". In other words, it picks the appropriate ip address
for itself.

Paul