1 |
pcg |
1.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 |
pcg |
1.2 |
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 |
pcg |
1.1 |
|