1 |
=head1 The GNU-VPE Protocols |
2 |
|
3 |
=head1 Overview |
4 |
|
5 |
GVPE can make use of a number of protocols. One of them is the GNU VPE |
6 |
protocol which is used to authenticate tunnels and send encrypted data |
7 |
packets. This protocol is described in more detail the second part of this |
8 |
document. |
9 |
|
10 |
The first part of this document describes the transport protocols which |
11 |
are used by GVPE to send it's data packets over the network. |
12 |
|
13 |
=head1 PART 1: Tansport protocols |
14 |
|
15 |
=head2 RAW IP |
16 |
|
17 |
=head2 ICMP |
18 |
|
19 |
=head2 UDP |
20 |
|
21 |
=head2 TCP |
22 |
|
23 |
=head2 DNS |
24 |
|
25 |
=head1 PART 2: The GNU VPE protocol |
26 |
|
27 |
This section, unfortunately, is not yet finished, although the protocol |
28 |
is stable (until bugs in the cryptography are found, which will likely |
29 |
completely change the following description). Nevertheless, it should give |
30 |
you some overview over the protocol. |
31 |
|
32 |
=head2 Anatomy of a VPN packet |
33 |
|
34 |
The exact layout and field lengths of a VPN packet is determined at |
35 |
compiletime and doesn't change. The same structure is used for all |
36 |
transort protocols, be it RAWIP or TCP. |
37 |
|
38 |
+------+------+--------+------+ |
39 |
| HMAC | TYPE | SRCDST | DATA | |
40 |
+------+------+--------+------+ |
41 |
|
42 |
The HMAC field is present in all packets, even if not used (e.g. in auth |
43 |
request packets), in which case it is set to all zeroes. The checksum |
44 |
itself is calculated over the TYPE, SRCDST and DATA fields in all cases. |
45 |
|
46 |
The TYPE field is a single byte and determines the purpose of the packet |
47 |
(e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
48 |
CONNECT REQUEST/INFO etc.). |
49 |
|
50 |
SRCDST is a three byte field which contains the source and destination |
51 |
node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
52 |
hosts, since all hosts must connect to each other once on startup. But if |
53 |
restarts are rare or tolerable and most connections are on demand, much |
54 |
larger networks are feasible. |
55 |
|
56 |
The DATA portion differs between each packet type, naturally, and is the |
57 |
only part that can be encrypted. Data packets contain more fields, as |
58 |
shown: |
59 |
|
60 |
+------+------+--------+------+-------+------+ |
61 |
| HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
62 |
+------+------+--------+------+-------+------+ |
63 |
|
64 |
RAND is a sequence of fully random bytes, used to increase the entropy of |
65 |
the data for encryption purposes. |
66 |
|
67 |
SEQNO is a 32-bit sequence number. It is negotiated at every connection |
68 |
initialization and starts at some random 31 bit value. VPE currently uses |
69 |
a sliding window of 512 packets/sequence numbers to detect reordering, |
70 |
duplication and reply attacks. |
71 |
|
72 |
=head2 The authentification protocol |
73 |
|
74 |
Before hosts can exchange packets, they need to establish authenticity of |
75 |
the other side and a key. Every host has a private RSA key and the public |
76 |
RSA keys of all other hosts. |
77 |
|
78 |
A host establishes a simplex connection by sending the other host a |
79 |
RSA encrypted challenge containing a random challenge (consisting of |
80 |
the encryption key to use when sending packets, more random data and |
81 |
PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
82 |
duplicate auth packets). The destination host will respond by replying |
83 |
with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
84 |
will authentify that host. The destination host will also set the outgoing |
85 |
encryption parameters as given in the packet. |
86 |
|
87 |
When the source host receives a correct auth reply (by verifying the |
88 |
hash and the id, which will expire after 120 seconds), it will start to |
89 |
accept data packets from the destination host. |
90 |
|
91 |
This means that a host can only initate a simplex connection, telling the |
92 |
other side the key it has to use when it sends packets. The challenge |
93 |
reply is only used to set the current IP address of the other side and |
94 |
protocol parameters. |
95 |
|
96 |
This protocol is completely symmetric, so to be able to send packets the |
97 |
destination host must send a challenge in the exact same way as already |
98 |
described (so, in essence, two simplex connections are created per host |
99 |
pair). |
100 |
|
101 |
=head2 Retrying |
102 |
|
103 |
When there is no response to an auth request, the host will send auth |
104 |
requests in bursts with an exponential backoff. After some time it will |
105 |
resort to PING packets, which are very small (8 bytes) and lightweight |
106 |
(no RSA operations required). A host that receives ping requests from an |
107 |
unconnected peer will respond by trying to create a connection. |
108 |
|
109 |
In addition to the exponential backoff, there is a global rate-limit on |
110 |
a per-IP base. It allows long bursts but will limit total packet rate to |
111 |
something like one control packet every ten seconds, to avoid accidental |
112 |
floods due to protocol problems (like a RSA key file mismatch between two |
113 |
hosts). |
114 |
|
115 |
=head2 Routing and Protocol translation |
116 |
|
117 |
The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
118 |
tries to establish direct connections, if the protocol abilities of the |
119 |
two hosts allow it. |
120 |
|
121 |
If the two hosts should be able to reach each other (common protocol, ip |
122 |
and port all known), but cannot (network down), then there will be no |
123 |
connection, point. |
124 |
|
125 |
A host can usually declare itself unreachable directly by setting it's |
126 |
port number(s) to zero. It can declare other hosts as unreachable by using |
127 |
a config-file that disables all protocols for these other hosts. |
128 |
|
129 |
If two hosts cannot connect to each other because their IP address(es) |
130 |
are not known (such as dialup hosts), one side will send a connection |
131 |
request to a router (routers must be configured to act as routers!), which |
132 |
will send both the originating and the destination host a connection info |
133 |
request with protocol information and IP address of the other host (if |
134 |
known). Both hosts will then try to establish a connection to the other |
135 |
peer, which is usually possible even when both hosts are behind a NAT |
136 |
gateway. |
137 |
|
138 |
If the hosts cannot reach each other because they have no common protocol, |
139 |
the originator instead use the router with highest priority and matching |
140 |
protocol as peer. Since the SRCDST field is not encrypted, the router host |
141 |
can just forward the packet to the destination host. Since each host uses |
142 |
it's own private key, the router will not be able to decrypt or encrypt |
143 |
packets, it will just act as a simple router and protocol translator. |
144 |
|
145 |
When no router is connected, the host will aggressively try to connect to |
146 |
all routers, and if a router is asked for an unconnected host it will try |
147 |
to ask another router to establish the connection. |
148 |
|
149 |
... more not yet written about the details of the routing, please bug me |
150 |
... |
151 |
|