- some first documentation in english
[strongswan.git] / Source / charon / doc / Architecture.txt
1  strongSwans overall design
2 ============================
3
4 IKEv1 and IKEv2 is handled in different keying daemons. The ole IKEv1 stuff is
5 completely handled in pluto, as it was all the times. IKEv2 is handled in the
6 new keying daemon, which is called charon. 
7 Daemon control is done over unix sockets. Pluto uses whack, as it did all the
8 times. Charon uses another socket interface, called stroke. Stroke uses another
9 format as whack and therefore is not compatible to whack. The starter utility,
10 wich does fast configuration parsing, speaks both the protocols, whack and
11 stroke. It also handles daemon startup and termination. 
12 Pluto uses starter for some commans, for other it uses the whack utility. To be
13 as close to pluto as possible, charon has the same split up of commands to
14 starter and stroke. All commands are wrapped together in the ipsec script, which
15 allows transparent control of both daemons.
16
17          +-----------------------------------------+
18          ¦                  ipsec                  ¦
19          +-----+--------------+---------------+----+
20                ¦              ¦               ¦
21                ¦              ¦               ¦
22                ¦        +-----+-----+         ¦
23          +-----+----+   ¦           ¦   +-----+----+
24          ¦          ¦   ¦  starter  ¦   ¦          ¦
25          ¦  stroke  ¦   ¦           ¦   ¦   whack  ¦
26          ¦          ¦   +---+--+----+   ¦          ¦
27          +------+---+       ¦  ¦        +--+-------+
28                 ¦           ¦  ¦           ¦
29             +---+------+    ¦  ¦    +------+--+
30             ¦          ¦    ¦  ¦    ¦         ¦
31             ¦  charon  +----+  +----+  pluto  ¦
32             ¦          ¦            ¦         ¦
33             +-----+----+            +----+----+
34                   ¦                      ¦
35             +-----+----+                 ¦
36             ¦    LSF   ¦                 ¦
37             +-----+----+                 ¦
38                   ¦                      ¦
39             +-----+----+            +----+----+
40             ¦ RAW Sock ¦            ¦ UDP/500 ¦
41             +----------+            +---------+
42
43 Since IKEv2 uses the same port as IKEv1, both daemons must listen to UDP port
44 500. Under Linux, there is no clean way to set up two sockets at the same port.
45 To reslove this problem, charon uses a RAW socket, as they are used in network
46 sniffers. An installed Linux Socket Filter (LSF) filters out all none-IKEv2
47 traffic. Pluto receives any IKE message, independant of charons behavior.
48 Therefore plutos behavior is changed to discard any IKEv2 traffic silently.
49
50
51  IKEv2 keying daemon: charon
52 =============================
53
54 All IKEv2 stuff is handled in charon. It uses a newer and more flexible
55 architecture than pluto. Charon uses a thread-pool, which allows parallel
56 execution SA-management. Beside the thread-pool, there are some special purpose
57 threads which do their job for the common health of the daemon.
58
59                        +------+
60                        ¦ E  Q ¦
61                        ¦ v  u ¦---+                   +------+  +------+
62                        ¦ e  e ¦   ¦                   ¦      ¦  ¦ IKE- ¦
63                        ¦ n  u ¦  +----------+         ¦      ¦--¦ SA   ¦
64                        ¦ t  e ¦  ¦          ¦         ¦ I  M ¦  +------+
65      +------------+    ¦ -    ¦  ¦ Sceduler ¦         ¦ K  A ¦
66      ¦  receiver  ¦    +------+  ¦          ¦         ¦ E  N ¦  +------+
67      +----+-------+              +----------+         ¦ -  A ¦  ¦ IKE- ¦
68           ¦      ¦     +------+   ¦                   ¦ S  G ¦--¦ SA   ¦
69   +-------+--+   +-----¦ J  Q ¦---+  +------------+   ¦ A  E ¦  +------+
70  -¦  socket  ¦         ¦ o  u ¦      ¦            ¦   ¦ -  R ¦
71   +-------+--+         ¦ b  e ¦      ¦   Thread-  ¦   ¦      ¦
72           ¦            ¦ -  u ¦      ¦   Pool     ¦   ¦      ¦
73      +----+-------+    ¦    e ¦------¦            ¦---¦      ¦
74      ¦   sender   ¦    +------+      +------------+   +------+
75      +----+-------+
76           ¦            +------+
77           ¦            ¦ S  Q ¦
78           ¦            ¦ e  u ¦
79           ¦            ¦ n  e ¦
80           ¦            ¦ d  u ¦
81           ¦            ¦ -  e ¦
82           ¦            +--+---+
83           ¦               ¦
84           +---------------+
85
86 The thread-pool is the heart of the architecture. It processes jobs from a
87 (fully synchronized) job-queue. Mostly, a job is associated with a specific
88 IKE SA. These IKE SAs are synchronized, only one thread can work one an IKE SA.
89 This makes it unnecesary to use further synchronisation methods once a IKE SA
90 is checked out. The (rather complex) synchronization of IKE SAs is completely
91 don in the IKE SA manager.
92 The sceduler is responsible for event firing. It waits until a event in the
93 (fully synchronized) event-queue is ready for processing and pushes the event
94 down to the job-queue. A thread form the pool will pick it up as quick as
95 possible. Every thread can queue events or jobs. Furter, an event can place a
96 packet in the send-queue. The sender thread waits for those packets and sends
97 them over the wire, via the socket. The receiver does exactly the opposite of
98 the sender. It waits on the socket, reads in packets an places them on the
99 job-queue for further processing by a thread from the pool.
100 There are even more threads, not drawn in the upper scheme. The stroke thread
101 is responsible for reading and processessing commands from another process. The
102 kernel interface thread handles communication from and to the kernel via a
103 netlink socket. It waits for kernel events and processes them appropriately.
104 The configuration architecture for charon is complex, but is flexible and
105 extensible. All configuration stuff is split up in multiple parts:
106
107 connection      Defines a connection between two hosts. Proposals define with
108                 wich algorithms a IKE SA should be set up.
109 policy          Defines the rules to apply ontop of a connection. A policy is
110                 defined between two IDs. Proposals and traffic selectors allow
111                 fine grained configuration of the CHILD SAs (AH and ESP) to set
112                 up.
113 credential      A credential something used for authentication, such as a
114                 preshared key, a RSA private or public key, certificate, ...
115 configuration   The configuration itself handles daemon related configuration
116                 stuff, such as interface binding or logging settings.
117
118 These configuration types are defined as interfaces, and are currently
119 implemented only in the stroke class. Through the modular design, parts can be
120 replaced with more powerful backends, such as a RADIUS server for the
121 credentials, a SQL database for the connections, policy definitions on an LDAP
122 server, and so on...