commit c8e17fa947a17fbedfada5b52639d340e8843579
parent 0ca549361445f8f982eb4bdb18f90b1c3ff8c669
Author: sin <sin@2f30.org>
Date: Thu, 31 Mar 2016 19:01:27 +0100
rework design comment
Diffstat:
M | stun.c | | | 30 | +++++++++++++++++------------- |
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/stun.c b/stun.c
@@ -2,12 +2,19 @@
* Design overview:
*
* stun implements a point to point encrypted tunnel. It supports
- * both layer 2 (TAP) and layer 3 (TUN) tunnels. At the moment, the
- * only supported transport is TCP.
+ * layer 2 (TAP) and layer 3 (TUN) tunnels. TCP is the only supported
+ * transport.
*
- * stun can be started either as a server or a client. There can only be
- * a single client connected to the server at any time. When a client connects
- * there is a mutual challenge-response phase as shown below:
+ * All communication is encrypted using a pre-shared symmetric key.
+ * aes-256-gcm was chosen because it is fast and does authentication.
+ * The key is derived with PBKDF2.
+ *
+ * stun is a client-server design. There can only be a single client
+ * connected to the server at any time. Routing between clients is handled
+ * by the networking stack on the server side.
+ *
+ * When a client connects there is a mutual challenge-response phase
+ * as shown below:
*
* t0: server challenges client
* t1: client responds to server's challenge
@@ -16,16 +23,13 @@
*
* The challenge-response algorithm is as follows:
*
- * The challenge is a randomly generated 64-bit integer encrypted with a
- * pre-shared symmetric key and sent to the receiver.
+ * The challenge is a randomly generated 64-bit integer encrypted
+ * with the pre-shared key and sent to the receiver.
* The receiver decrypts it, adds 1, encrypts it and sends it back to
- * the sender. The sender verifies that the correct response was received.
- *
- * All communication is encrypted using a pre-shared symmetric key. The cipher
- * used is aes-256-gcm and the key is derived with PBKDF2.
+ * the sender. The sender verifies the response.
+ * This algorithm is the same as what Kerberos uses for authentication.
*
- * All tunneled traffic is encapsulated inside the TCP payload.
- * The packet format is shown below:
+ * The stun packet format is shown below:
*
* [TAG] [IV] [PAYLOAD LENGTH] [PAYLOAD]
*