Project

General

Profile

An XML based management protocol for strongSwan (SMP) » History » Version 7

Martin Willi, 02.04.2008 09:49

1 1 Martin Willi
2 7 Martin Willi
h1. An XML based management protocol for strongSwan (SMP)
3 1 Martin Willi
4 1 Martin Willi
5 7 Martin Willi
We are developing a flexible XML-based configuration interface. It uses the *SMP* protocol developed by Andreas Eigenmann and Joël Stillhart as part of their diploma thesis. 
6 7 Martin Willi
7 7 Martin Willi
8 7 Martin Willi
h2. Overview
9 7 Martin Willi
10 7 Martin Willi
The currently implemented communication interface to [[charon]] is called stroke. It's a simple protocol with it's own binary format. Only the input format is specified, output is redirected to the console.
11 7 Martin Willi
12 1 Martin Willi
While this protocol is usable for console applications (ipsec/starter), we need a better protocol to get feedback for an operation, query the status of the daemon, ...
13 1 Martin Willi
14 1 Martin Willi
15 7 Martin Willi
h2. Requirements
16 1 Martin Willi
17 7 Martin Willi
** Querying
18 7 Martin Willi
**** IKE_SA list
19 7 Martin Willi
**** Daemon status
20 7 Martin Willi
**** ...
21 7 Martin Willi
** Control
22 7 Martin Willi
**** initiate connection
23 7 Martin Willi
**** terminate connection
24 7 Martin Willi
**** ...
25 7 Martin Willi
** Get notifications
26 7 Martin Willi
**** client connected
27 7 Martin Willi
**** client connect attempt failed
28 7 Martin Willi
**** ...
29 7 Martin Willi
30 7 Martin Willi
31 7 Martin Willi
h2. Protocol
32 7 Martin Willi
33 7 Martin Willi
To get an universal usable and easy to implement protocol, SMP is based on a XML. We use "Relax-NG":http://www.relaxng.org schemas for validation, as they are more powerful than DTD, but simpler than XML schema.
34 7 Martin Willi
35 7 Martin Willi
36 7 Martin Willi
h3. Connectivity
37 7 Martin Willi
38 1 Martin Willi
SMP uses a reliable protocol. We implement the protocol over a Unix socket for the first try, TCP connections are targeted for a later release (see security).
39 3 Martin Willi
40 7 Martin Willi
41 7 Martin Willi
h3. Security
42 7 Martin Willi
43 1 Martin Willi
We do not implement any security (encryption/authentication) in the first iteration. We will operate on a Unix socket, we enforce security with file permissions. Further development iterations will support for remote administration (over TCP), and then we need authentication, encryption and integrity checks.
44 3 Martin Willi
45 3 Martin Willi
The proposed XML-Security like approach proposed in the diploma thesis suffers from replay attack detection. Futher, using the asymmetric approach for each message may be to expensive.
46 3 Martin Willi
47 3 Martin Willi
If we implement a more complex notification mechanism, we need to register anyway at connection setup. We could agree on encryption and compression algorithm and exchange a key in this registration process.
48 3 Martin Willi
49 3 Martin Willi
50 7 Martin Willi
h3. Message format
51 3 Martin Willi
52 7 Martin Willi
The root element of an exchanged element is the _<message>_ element. A message has a _type_ attribute of either _request_, _response_ or _notification_. To protect messages against replay attacks, each message as an _id_ attribute, which in unique and incremental for each request/response pair. Notifications use their own counter for for message ids, as they appear asynchronously.
53 7 Martin Willi
54 7 Martin Willi
Messages of _type_ _request_ and _response_ contain one or more of the elements _query_ and _control_.
55 7 Martin Willi
56 7 Martin Willi
57 7 Martin Willi
h3. Schema
58 7 Martin Willi
59 3 Martin Willi
The complete schema is available at [source:trunk/src/charon/plugins/smp/schema.xml] (draft).
60 4 Tobias Brunner
61 7 Martin Willi
62 7 Martin Willi
h3. Query Operations
63 7 Martin Willi
64 7 Martin Willi
** [[SMPQueryIKESA|Query a list of IKE_SAs]]
65 7 Martin Willi
** ...
66 7 Martin Willi
The status of all IKE_SAs can be queried by sending a message of type _request_ including a query