| 1 |
=head1 The VPE Protocol |
| 2 |
|
| 3 |
=head2 Anatomy of a VPN packet |
| 4 |
|
| 5 |
The exact layout and field lengths of a VPN packet is determined at |
| 6 |
compiletime and doesn't change. The same structure is used for all |
| 7 |
protocols, be it rawip or tcp. |
| 8 |
|
| 9 |
+------+------+--------+------+ |
| 10 |
| HMAC | TYPE | SRCDST | DATA | |
| 11 |
+------+------+--------+------+ |
| 12 |
|
| 13 |
The HMAC field is present in all packets, even if not used (e.g. in |
| 14 |
authentification packets), in which case it is set to all zeroes. The |
| 15 |
checksum itself is over the TYPE, SRCDST and DATA fields in all cases. |
| 16 |
|
| 17 |
The TYPE field is a single byte and determines the purpose of the packet |
| 18 |
(e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
| 19 |
CONNECT REQUEST/INFO etc.). |
| 20 |
|
| 21 |
SRCDST is a three byte field which contains the source and destination |
| 22 |
node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
| 23 |
hosts, since all hosts connect to each other on startup. But if restarts |
| 24 |
are rare or tolerable and most connections are on demand, larger networks |
| 25 |
are possible. |
| 26 |
|
| 27 |
The DATA portion differs between each packet type, naturally, and is the |
| 28 |
only part that can be encrypted encrypted. Data packets contain more |
| 29 |
fields, as shown: |
| 30 |
|
| 31 |
+------+------+--------+------+-------+------+ |
| 32 |
| HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
| 33 |
+------+------+--------+------+-------+------+ |
| 34 |
|
| 35 |
RAND is a sequence of fully random bytes, used to increase the entropy of the data |
| 36 |
for encryption purposes. |
| 37 |
|
| 38 |
SEQNO is a 32-bit sequence number. It is negotiated at every connection |
| 39 |
initialization and starts at some random value. |
| 40 |
|
| 41 |
=head2 The authentification protocol |
| 42 |
|
| 43 |
Before hosts can exchange packets, they need to establish authenticity of |
| 44 |
the other side and a key. Every host has a private RSA key and the public |
| 45 |
RSA keys of all other hosts. |
| 46 |
|
| 47 |
A host establishes a simplex connection by sending the other host a RSA |
| 48 |
challenge containing the random digest and encryption keys (different) |
| 49 |
to use when sending packets, plus more randomness plus some PKCS1_OAEP |
| 50 |
padding plus a random 16 byte id. The destination host will respond by |
| 51 |
replying with an (unencrypted) RIPEMD160 hash of the decrypted data, which |
| 52 |
will authentify that host. The destination host will also set the outgoing |
| 53 |
encryption parameters as given in the packet. |
| 54 |
|
| 55 |
When the source host receives a correct auth reply (by verifying the |
| 56 |
hash and the id, which will expire after 20 seconds). it will start to |
| 57 |
accept data packets from the destination host. The protocol is completely |
| 58 |
symmetric, so to be able to send packets the destination host must send a |
| 59 |
challenge in the exact same way as already described. |
| 60 |
|
| 61 |
=head2 Retrying |
| 62 |
|
| 63 |
When there is no response to an auth request, the host will send auth |
| 64 |
requests in bursts with an exponential backoff. After some time it will |
| 65 |
resort to PING packets, which are very small (8 byte) and lightweight (no |
| 66 |
RSA operations). A host that receives ping requests from an unconnected |
| 67 |
peer will respond by trying to create a connection. |
| 68 |
|
| 69 |
In addition to the exponential backoff, there is a global rate-limit on |
| 70 |
a per-ip base. It allows long bursts but will limit total packet rate to |
| 71 |
something like one control packet every ten seconds, to avoid accidental |
| 72 |
floods due to protocol problems (like a rsa key file mismatch between two |
| 73 |
hosts). |
| 74 |
|
| 75 |
=head2 Routing and Protocol translation |
| 76 |
|
| 77 |
... not yet written, please bug me ... |
| 78 |
|
