aboutsummaryrefslogtreecommitdiffstats
path: root/Source/charon/doc/Architecture.txt
diff options
context:
space:
mode:
authorMartin Willi <martin@strongswan.org>2006-04-05 12:10:50 +0000
committerMartin Willi <martin@strongswan.org>2006-04-05 12:10:50 +0000
commit6862128151fb78f63685a8da5575783c426d64a7 (patch)
tree75920a6688ed5654fb917ecccc1e0e469480fd1f /Source/charon/doc/Architecture.txt
parent3dbbbf3e16366b0da33b29bbc1a4ba9a976e43a0 (diff)
downloadstrongswan-6862128151fb78f63685a8da5575783c426d64a7.tar.bz2
strongswan-6862128151fb78f63685a8da5575783c426d64a7.tar.xz
../svn-commit.tmp
Diffstat (limited to 'Source/charon/doc/Architecture.txt')
-rw-r--r--Source/charon/doc/Architecture.txt128
1 files changed, 0 insertions, 128 deletions
diff --git a/Source/charon/doc/Architecture.txt b/Source/charon/doc/Architecture.txt
deleted file mode 100644
index 3e8855fa9..000000000
--- a/Source/charon/doc/Architecture.txt
+++ /dev/null
@@ -1,128 +0,0 @@
- 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 for years.
-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 commands, 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.
-
- +-----------------------------------------+
- | ipsec |
- +-----+--------------+---------------+----+
- | | |
- | | |
- | +-----+-----+ |
- +-----+----+ | | +-----+----+
- | | | starter | | |
- | stroke | | | | whack |
- | | +---+--+----+ | |
- +------+---+ | | +--+-------+
- | | | |
- +---+------+ | | +------+--+
- | | | | | |
- | charon +----+ +----+ pluto |
- | | | |
- +-----+----+ +----+----+
- | |
- +-----+----+ |
- | LSF | |
- +-----+----+ |
- | |
- +-----+----+ +----+----+
- | RAW Sock | | UDP/500 |
- +----------+ +---------+
-
-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
-=============================
-
- Threading modell
-------------------
-
-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.
-
- +------+
- | E Q |
- | v u |---+ +------+ +------+
- | e e | | | | | IKE- |
- | n u | +-----------+ | |--| SA |
- | t e | | | | I M | +------+
- +------------+ | - | | Scheduler | | K a |
- | receiver | +------+ | | | E n | +------+
- +----+-------+ +-----------+ | - a | | IKE- |
- | | +------+ | | S g |--| SA |
- +-------+--+ +-----| J Q |---+ +------------+ | A e | +------+
- -| socket | | o u | | | | - r |
- +-------+--+ | b e | | Thread- | | |
- | | - u | | Pool | | |
- +----+-------+ | e |------| |---| |
- | sender | +------+ +------------+ +------+
- +----+-------+
- | +------+
- | | S Q |
- | | e u |
- | | n e |
- +------------| d u |
- | - e |
- +--+---+
-
-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
-done in the IKE SA manager.
-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.
-
-
- configuration backends
-------------------------
-
-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.
-credential A credential is something used for authentication, such as a
- 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
-implemented only in the stroke class. Through the modular design, parts could be
-replaced with more powerful backends, such as a RADIUS server for the
-credentials, a SQL database for the connections, policy definitions on an LDAP
-server, and so on...