| 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 |
The vpe routing algorithm is easy: there isn't any routing. Vped always |
| 78 |
tries to establish direct connections, if the protocol abilities of the |
| 79 |
two hosts allow it. |
| 80 |
|
| 81 |
If the two hosts should be able to reach each other (common protocol, ip |
| 82 |
and port all known), but cannot (network down), then there will be no |
| 83 |
connection, point. |
| 84 |
|
| 85 |
A host can usually declare itself unreachable directly by setting it's |
| 86 |
port number(s) to zero. It can declare other hosts as unreachable by using |
| 87 |
a config-file that disables all protocols for these other hosts. |
| 88 |
|
| 89 |
If two hosts cannot connect to each other because their IP address(es) |
| 90 |
are not known (such as dialup hosts), one side will send a connection |
| 91 |
request to a router (routers must be configured to act as routers!), which |
| 92 |
will send both the originating and the destination host a connection info |
| 93 |
request with protocol information and IP address of the other host (if |
| 94 |
known). Both hosts will then try to establish a connection to the other |
| 95 |
peer, which is usually possible even when both hosts are behind a NAT |
| 96 |
gateway. |
| 97 |
|
| 98 |
If the hosts cannot reach each other because they have no common protocol, |
| 99 |
the originator instead use the router with highest priority and matching |
| 100 |
protocol as peer. Since the SRCDST field is not encrypted, the router host |
| 101 |
can just forward the packet to the destination host. Since each host uses |
| 102 |
it's own private key, the router will not be able to decrypt or encrypt |
| 103 |
packets, it will just act as a simple router and protocol translator. |
| 104 |
|
| 105 |
When no router is connected, the host will aggressively try to connect to |
| 106 |
all routers, and if a router is asked for an unconnected host it will try |
| 107 |
to ask another router to establish the connection. |
| 108 |
|
| 109 |
... more not yet written about the details of the routing, please bug me |
| 110 |
... |
| 111 |
|
