commit 5cb07984b76d82b26414c071e1c6c3db0e0f09ee parent eec19fac6675df594355c653abf331a6b17c8057 Author: sin <sin@2f30.org> Date: Tue, 29 Mar 2016 10:28:13 +0100 add design overview Diffstat:
| M | stun.c | | | 38 | +++++++++++++++++++++++++++++++++++++- |
1 file changed, 37 insertions(+), 1 deletion(-)
diff --git a/stun.c b/stun.c @@ -1,4 +1,40 @@ -/* See LICENSE file for copyright and license details. */ +/* + * 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. + * + * There is a server and a client. By default the server listens on + * port 12080. When a client connects there is a challenge-response phase + * as shown below: + * + * t0: server challenges client + * t1: client responds to server's challenge + * t2: client challenges server + * t3: server responds to client's challenge + * + * The challenge-response algorithm is as follows: + * + * The challenge is a randomly generated integer, encrypted with a pre-shared + * symmetric key and sent to the receiver. + * The receiver decrypts it, adds 1 and sends the response back to the sender. + * The sender verifies that the correct response was received. + * + * All communication is encrypted using a pre-shared symmetric key, currently + * using aes-256-cbc hashed with sha1. + * + * All tunneled traffic is encapsulated inside the TCP payload. + * The packet format is shown below: + * + * [PAYLOAD LEN][PAYLOAD] + * + * The payload is encrypted and padded to 16 bytes. The payload length is + * the length of the unpadded payload. When the receiver processes a packet + * it needs to pad the payload len in order to decrypt the packet. The unpadded + * length is then used to determine the size of the actual decrypted payload. + */ + #include <sys/types.h> #include <sys/uio.h> #include <sys/ioctl.h>