Project

General

Profile

IKE keying daemon charon » History » Version 1

Version 1/19 - Next » - Current version
Martin Willi, 29.06.2007 11:04


= IKEv2 keying daemon charon =

Overwiev
The ''charon'' keying daemon was built from scratch to implement the IKEv2 protocol for strongSwan. Architecture
''charon'' has a fully multi-threaded design to meet todays requirements.
It is built modular and is extensible through plugins.

{{{
------ ----- ------ --------- --------- | Stroke | | XML | | DBUS | | Local | | SQLite |
------ ----- ------ --------- --------- | | | | |
------------------------------- -------------------------- | Interfaces | | Backends |
------------------------------- --------------------------

----------    ---------        ----            --------
 |  receiver  |    |           |        |      |  ----  | CHILD_SA |
---------+ | Scheduler | | IKE- | | IKE- |--+----------+ | | | | SA |--| SA | | CHILD_SA |
-------+ --------- | | ---- --------
<->| socket | | | Man- |
-------+ --------- | ager | ---- -------- | | | | | | IKE- |--| CHILD_SA |
---------+ | Processor |--------| |--| SA | -------- | sender | | | | | ----
---------- --------- ----
-------------------------------       --------------------------
|               Bus               |       |      Kernel Interface      |
------------------------------- -------------------------- | | |
----------- ----------- V | File-Logger | | Sys-Logger | //////
----------- -----------
}}}

=== processor ===
The threading is realized with the help of a thread pool (called processor),
which contains a fixed amount of precreated threads. All threads in the
daemon originate from the processor. To delegate work to a thread, jobs are
queued to the processor for asynchronous execution.

=== scheduler ===
The scheduler is responsible to execute timed events. Jobs may be queued to
the scheduler to get executed at a defined time (e.g. rekeying). The scheduler
does not execute the jobs itself, it queues them to the processor.

=== IKE_SA manager ===
The IKE_SA manager managers all IKE_SA. It further handles the synchronization:
Each IKE_SA must be checked out strictly and checked in again after use. The
manager guarantees that only one thread may check out a single IKE_SA. This allows
us to write the (complex) IKE_SAs routines non-threadsave.

=== IKE_SA ===
The IKE_SA contain the state and the logic of each IKE_SA and handle the messages.

=== CHILD_SA ===
The CHILD_SA contains state about a IPsec security association and manages them.
An IKE_SA may have multiple CHILD_SAs. Communication to the kernel takes place
here through the kernel interface.

=== kernel interface ===
The kernel interface installs IPsec security associations, policies routes and
virtual addresses. It further provides methods to enumerate interfaces and may notify
the daemon about state changes at lower layers.

=== Bus ===
The bus receives signals from the different threads and relais them to interested
listeners. Debugging signals, but also important state changes or error messages are
sent over the bus.
It's listeners are not only for logging, but also to track the state of an IKE_SA.

=== File-Logger and Sys-Logger ===
These bus listeners are long-time registered and log messages sent to the bus to a file
or the syslog. They filter the huge amount of messages to a defined loglevel.

=== Interfaces ===
The interface manager loads pluggable controlling interfaces. These are written to control
the daemon from external inputs (e.g. initiate IKE_SA, close IKE_SA, ...). The interface
manager further provides a simple API to establish these tasks.

=== Backends ===
Backends are pluggable modules which provide configuration. They have to implement an API
which the daemon core uses to get configuration.