diff options
Diffstat (limited to 'Source/doc')
| -rw-r--r-- | Source/doc/Architecture.txt | 128 | ||||
| -rw-r--r-- | Source/doc/Known-bugs.txt | 5 | ||||
| -rw-r--r-- | Source/doc/Todo-list.txt | 44 |
3 files changed, 177 insertions, 0 deletions
diff --git a/Source/doc/Architecture.txt b/Source/doc/Architecture.txt new file mode 100644 index 000000000..3e8855fa9 --- /dev/null +++ b/Source/doc/Architecture.txt @@ -0,0 +1,128 @@ + 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... diff --git a/Source/doc/Known-bugs.txt b/Source/doc/Known-bugs.txt new file mode 100644 index 000000000..079d4d0f9 --- /dev/null +++ b/Source/doc/Known-bugs.txt @@ -0,0 +1,5 @@ + Known bugs in charon +====================== + +- intiating the same connection twice makes trouble. +- diff --git a/Source/doc/Todo-list.txt b/Source/doc/Todo-list.txt new file mode 100644 index 000000000..4915ea7c7 --- /dev/null +++ b/Source/doc/Todo-list.txt @@ -0,0 +1,44 @@ + TODO-List for charon +====================== + ++ = done, - = todo, ordered by priority + ++ private key loading: der, without passphrase ++ load all private keys from ipsec.d/private/ in stroke.c ++ handle leftcert and rightcert in starterstroke.c/stroke.c ++ load specified certs in stroke.c ++ extract public keys from certs ++ public key authentication ++ release for Andreas + ++ stroke loglevels ++ stroke up ++ ike_sa_manager checkout_by_hosts ++ stroke down ++ stroke output redirection ++ stroke status + +- libx509 + + new charon build - libstrong? + + transforms + + utils (plus host) + - doxygen fixes (two doxyfiles?) + - allocator cleanup (used in lib, charon and pluto(!)) + - logger reimplementation? (one logger for lib, charon, pluto) + - integrate asn1 parser/oid (asn1/oid) + - integrate PEM loading (pem) + - ... (more to come, for sure) + +- ipsec.secrets parsing + +- certificate DN parsing +- certificate subjectAltName parsing +- certificate lookup via ID +- certificate validation/chaining +- certificate exchange + +- trapping + +- delete notify, when to send? +- notifys on connection setup failure +- create child sa message |