2006-03-21 10:10:56 +00:00
|
|
|
|
strongSwans overall design
|
|
|
|
|
============================
|
|
|
|
|
|
|
|
|
|
IKEv1 and IKEv2 is handled in different keying daemons. The ole IKEv1 stuff is
|
|
|
|
|
completely handled in pluto, as it was all the times. IKEv2 is handled in the
|
|
|
|
|
new keying daemon, which is called charon.
|
|
|
|
|
Daemon control is done over unix sockets. Pluto uses whack, as it did all the
|
|
|
|
|
times. Charon uses another socket interface, called stroke. Stroke uses another
|
|
|
|
|
format as whack and therefore is not compatible to whack. The starter utility,
|
|
|
|
|
wich does fast configuration parsing, speaks both the protocols, whack and
|
|
|
|
|
stroke. It also handles daemon startup and termination.
|
|
|
|
|
Pluto uses starter for some commans, for other it uses the whack utility. To be
|
|
|
|
|
as close to pluto as possible, charon has the same split up of commands to
|
|
|
|
|
starter and stroke. All commands are wrapped together in the ipsec script, which
|
|
|
|
|
allows transparent control of both daemons.
|
|
|
|
|
|
|
|
|
|
+-----------------------------------------+
|
|
|
|
|
<20> ipsec <20>
|
|
|
|
|
+-----+--------------+---------------+----+
|
|
|
|
|
<20> <20> <20>
|
|
|
|
|
<20> <20> <20>
|
|
|
|
|
<20> +-----+-----+ <20>
|
|
|
|
|
+-----+----+ <20> <20> +-----+----+
|
|
|
|
|
<20> <20> <20> starter <20> <20> <20>
|
|
|
|
|
<20> stroke <20> <20> <20> <20> whack <20>
|
|
|
|
|
<20> <20> +---+--+----+ <20> <20>
|
|
|
|
|
+------+---+ <20> <20> +--+-------+
|
|
|
|
|
<20> <20> <20> <20>
|
|
|
|
|
+---+------+ <20> <20> +------+--+
|
|
|
|
|
<20> <20> <20> <20> <20> <20>
|
|
|
|
|
<20> charon +----+ +----+ pluto <20>
|
|
|
|
|
<20> <20> <20> <20>
|
|
|
|
|
+-----+----+ +----+----+
|
|
|
|
|
<20> <20>
|
|
|
|
|
+-----+----+ <20>
|
|
|
|
|
<20> LSF <20> <20>
|
|
|
|
|
+-----+----+ <20>
|
|
|
|
|
<20> <20>
|
|
|
|
|
+-----+----+ +----+----+
|
|
|
|
|
<20> RAW Sock <20> <20> UDP/500 <20>
|
|
|
|
|
+----------+ +---------+
|
|
|
|
|
|
|
|
|
|
Since IKEv2 uses the same port as IKEv1, both daemons must listen to UDP port
|
|
|
|
|
500. Under Linux, there is no clean way to set up two sockets at the same port.
|
|
|
|
|
To reslove this problem, charon uses a RAW socket, as they are used in network
|
|
|
|
|
sniffers. An installed Linux Socket Filter (LSF) filters out all none-IKEv2
|
|
|
|
|
traffic. Pluto receives any IKE message, independant of charons behavior.
|
|
|
|
|
Therefore plutos behavior is changed to discard any IKEv2 traffic silently.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
IKEv2 keying daemon: charon
|
|
|
|
|
=============================
|
|
|
|
|
|
2006-03-23 15:25:43 +00:00
|
|
|
|
Threading modell
|
|
|
|
|
------------------
|
|
|
|
|
|
2006-03-21 10:10:56 +00:00
|
|
|
|
All IKEv2 stuff is handled in charon. It uses a newer and more flexible
|
|
|
|
|
architecture than pluto. Charon uses a thread-pool, which allows parallel
|
|
|
|
|
execution SA-management. Beside the thread-pool, there are some special purpose
|
|
|
|
|
threads which do their job for the common health of the daemon.
|
|
|
|
|
|
|
|
|
|
+------+
|
|
|
|
|
<20> E Q <20>
|
|
|
|
|
<20> v u <20>---+ +------+ +------+
|
|
|
|
|
<20> e e <20> <20> <20> <20> <20> IKE- <20>
|
2006-03-23 15:25:43 +00:00
|
|
|
|
<20> n u <20> +-----------+ <20> <20>--<2D> SA <20>
|
|
|
|
|
<20> t e <20> <20> <20> <20> I M <20> +------+
|
|
|
|
|
+------------+ <20> - <20> <20> Scheduler <20> <20> K a <20>
|
|
|
|
|
<20> receiver <20> +------+ <20> <20> <20> E n <20> +------+
|
|
|
|
|
+----+-------+ +-----------+ <20> - a <20> <20> IKE- <20>
|
|
|
|
|
<20> <20> +------+ <20> <20> S g <20>--<2D> SA <20>
|
|
|
|
|
+-------+--+ +-----<2D> J Q <20>---+ +------------+ <20> A e <20> +------+
|
|
|
|
|
-<2D> socket <20> <20> o u <20> <20> <20> <20> - r <20>
|
2006-03-21 10:10:56 +00:00
|
|
|
|
+-------+--+ <20> b e <20> <20> Thread- <20> <20> <20>
|
|
|
|
|
<20> <20> - u <20> <20> Pool <20> <20> <20>
|
|
|
|
|
+----+-------+ <20> e <20>------<2D> <20>---<2D> <20>
|
|
|
|
|
<20> sender <20> +------+ +------------+ +------+
|
|
|
|
|
+----+-------+
|
|
|
|
|
<20> +------+
|
|
|
|
|
<20> <20> S Q <20>
|
|
|
|
|
<20> <20> e u <20>
|
|
|
|
|
<20> <20> n e <20>
|
2006-03-23 15:25:43 +00:00
|
|
|
|
+------------<2D> d u <20>
|
|
|
|
|
<20> - e <20>
|
|
|
|
|
+--+---+
|
2006-03-21 10:10:56 +00:00
|
|
|
|
|
|
|
|
|
The thread-pool is the heart of the architecture. It processes jobs from a
|
|
|
|
|
(fully synchronized) job-queue. Mostly, a job is associated with a specific
|
|
|
|
|
IKE SA. These IKE SAs are synchronized, only one thread can work one an IKE SA.
|
|
|
|
|
This makes it unnecesary to use further synchronisation methods once a IKE SA
|
|
|
|
|
is checked out. The (rather complex) synchronization of IKE SAs is completely
|
2006-03-23 15:25:43 +00:00
|
|
|
|
done in the IKE SA manager.
|
2006-03-21 10:10:56 +00:00
|
|
|
|
The sceduler is responsible for event firing. It waits until a event in the
|
|
|
|
|
(fully synchronized) event-queue is ready for processing and pushes the event
|
|
|
|
|
down to the job-queue. A thread form the pool will pick it up as quick as
|
|
|
|
|
possible. Every thread can queue events or jobs. Furter, an event can place a
|
|
|
|
|
packet in the send-queue. The sender thread waits for those packets and sends
|
|
|
|
|
them over the wire, via the socket. The receiver does exactly the opposite of
|
|
|
|
|
the sender. It waits on the socket, reads in packets an places them on the
|
|
|
|
|
job-queue for further processing by a thread from the pool.
|
|
|
|
|
There are even more threads, not drawn in the upper scheme. The stroke thread
|
|
|
|
|
is responsible for reading and processessing commands from another process. The
|
|
|
|
|
kernel interface thread handles communication from and to the kernel via a
|
|
|
|
|
netlink socket. It waits for kernel events and processes them appropriately.
|
2006-03-23 15:25:43 +00:00
|
|
|
|
|
|
|
|
|
|
|
|
|
|
configuration backends
|
|
|
|
|
------------------------
|
|
|
|
|
|
2006-03-21 10:10:56 +00:00
|
|
|
|
The configuration architecture for charon is complex, but is flexible and
|
|
|
|
|
extensible. All configuration stuff is split up in multiple parts:
|
|
|
|
|
|
|
|
|
|
connection Defines a connection between two hosts. Proposals define with
|
|
|
|
|
wich algorithms a IKE SA should be set up.
|
|
|
|
|
policy Defines the rules to apply ontop of a connection. A policy is
|
|
|
|
|
defined between two IDs. Proposals and traffic selectors allow
|
|
|
|
|
fine grained configuration of the CHILD SAs (AH and ESP) to set
|
|
|
|
|
up.
|
2006-03-23 15:25:43 +00:00
|
|
|
|
credential A credential is something used for authentication, such as a
|
2006-03-21 10:10:56 +00:00
|
|
|
|
preshared key, a RSA private or public key, certificate, ...
|
|
|
|
|
configuration The configuration itself handles daemon related configuration
|
|
|
|
|
stuff, such as interface binding or logging settings.
|
|
|
|
|
|
|
|
|
|
These configuration types are defined as interfaces, and are currently
|
2006-03-23 15:25:43 +00:00
|
|
|
|
implemented only in the stroke class. Through the modular design, parts could be
|
2006-03-21 10:10:56 +00:00
|
|
|
|
replaced with more powerful backends, such as a RADIUS server for the
|
|
|
|
|
credentials, a SQL database for the connections, policy definitions on an LDAP
|
2006-03-23 15:25:43 +00:00
|
|
|
|
server, and so on...
|