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 |
GVPE offers a range of transport protocols that can be used to interchange |
16 |
data between nodes. Protocols differ in their overhead, speed, |
17 |
reliability, and robustness. |
18 |
|
19 |
The following sections describe each transport protocol in more |
20 |
detail. They are sorted by overhead/efficiency, the most efficient |
21 |
transport is listed first: |
22 |
|
23 |
=head2 RAW IP |
24 |
|
25 |
This protocol is the best choice, performance-wise, as the minimum |
26 |
overhead per packet is only 38 bytes. |
27 |
|
28 |
It works by sending the VPN payload using raw ip frames (using the |
29 |
protocol set by C<ip-proto>). |
30 |
|
31 |
Using raw ip frames has the drawback that many firewalls block "unknown" |
32 |
protocols, so this transport only works if you have full IP connectivity |
33 |
between nodes. |
34 |
|
35 |
=head2 ICMP |
36 |
|
37 |
This protocol offers very low overhead (minimum 42 bytes), and can |
38 |
sometimes tunnel through firewalls when other protocols cannot. |
39 |
|
40 |
It works by prepending a ICMP header with type C<icmp-type> and a code |
41 |
of C<255>. The default C<icmp-type> is C<echo-reply>, so the resulting |
42 |
packets look like echo replies, which looks rather strange to network |
43 |
admins. |
44 |
|
45 |
This transport should only be used if other transports (i.e. raw ip) are |
46 |
not available or undesirable (due to their overhead). |
47 |
|
48 |
=head2 UDP |
49 |
|
50 |
This is a good general choice for the transport protocol as UDP packets |
51 |
tunnel well through most firewalls and routers, and the overhead per |
52 |
packet is moderate (minimum 58 bytes). |
53 |
|
54 |
It should be used if RAW IP is not available. |
55 |
|
56 |
=head2 TCP |
57 |
|
58 |
This protocol is a very bad choice, as it not only has high overhead (more |
59 |
than 60 bytes), but the transport also retries on it's own, which leads |
60 |
to congestion when the link has moderate packet loss (as both the TCP |
61 |
transport and the tunneled traffic will retry, increasing congestion more |
62 |
and more). It also has high latency and is quite inefficient. |
63 |
|
64 |
It's only useful when tunneling through firewalls that block better |
65 |
protocols. If a node doesn't have direct internet access but a HTTP proxy |
66 |
that supports the CONNECT method it can be used to tunnel through a web |
67 |
proxy. For this to work, the C<tcp-port> should be C<443> (C<https>), as |
68 |
most proxies do not allow connections to other ports. |
69 |
|
70 |
It is an abuse of the usage a proxy was designed for, so make sure you are |
71 |
allowed to use it for GVPE. |
72 |
|
73 |
This protocol also has server and client sides. If the C<tcp-port> is set |
74 |
to zero, other nodes cannot connect to this node directly (and C<tcp-port> |
75 |
zero cannot be used). If the C<tcp-port> is non-zero, the node can act |
76 |
both as a client as well as a server. |
77 |
|
78 |
=head2 DNS |
79 |
|
80 |
B<WARNING:> Parsing and generating DNS packets is rather tricky. The code |
81 |
almost certainly contains buffer overflows and other, likely exploitable, |
82 |
bugs. You have been warned. |
83 |
|
84 |
This is the worst choice of transport protocol with respect to overhead |
85 |
(overhead can be 2-3 times higher than the transferred data), and latency |
86 |
(which can be many seconds). Some DNS servers might not be prepared to |
87 |
handle the traffic and drop or corrupt packets. The client also has to |
88 |
constantly poll the server for data, so the client will constantly create |
89 |
traffic even if it doesn't need to transport packets. |
90 |
|
91 |
In addition, the same problems as the TCP transport also plague this |
92 |
protocol. |
93 |
|
94 |
Most configuration needs to be done by editing C<src/vpn_dns.C> directly. |
95 |
|
96 |
It's only use is to tunnel through firewalls that do not allow direct |
97 |
internet access. Similar to using a HTTP proxy (as the TCP transport |
98 |
does), it uses a local DNS server/forwarder (given by the C<dns-forw-host> |
99 |
configuration value) as a proxy to send and receive data as a client, |
100 |
and a C<NS> record pointing to the GVPE server (as given by the |
101 |
C<dns-hostname> directive). |
102 |
|
103 |
The only good side of this protocol is that it can tunnel through most |
104 |
firewalls undetected, iff the local DNS server/forwarder is sane (which is |
105 |
true for most routers, wlan gateways and nameservers). |
106 |
|
107 |
=head1 PART 2: The GNU VPE protocol |
108 |
|
109 |
This section, unfortunately, is not yet finished, although the protocol |
110 |
is stable (until bugs in the cryptography are found, which will likely |
111 |
completely change the following description). Nevertheless, it should give |
112 |
you some overview over the protocol. |
113 |
|
114 |
=head2 Anatomy of a VPN packet |
115 |
|
116 |
The exact layout and field lengths of a VPN packet is determined at |
117 |
compiletime and doesn't change. The same structure is used for all |
118 |
transort protocols, be it RAWIP or TCP. |
119 |
|
120 |
+------+------+--------+------+ |
121 |
| HMAC | TYPE | SRCDST | DATA | |
122 |
+------+------+--------+------+ |
123 |
|
124 |
The HMAC field is present in all packets, even if not used (e.g. in auth |
125 |
request packets), in which case it is set to all zeroes. The checksum |
126 |
itself is calculated over the TYPE, SRCDST and DATA fields in all cases. |
127 |
|
128 |
The TYPE field is a single byte and determines the purpose of the packet |
129 |
(e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
130 |
CONNECT REQUEST/INFO etc.). |
131 |
|
132 |
SRCDST is a three byte field which contains the source and destination |
133 |
node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
134 |
hosts, since all hosts must connect to each other once on startup. But if |
135 |
restarts are rare or tolerable and most connections are on demand, much |
136 |
larger networks are feasible. |
137 |
|
138 |
The DATA portion differs between each packet type, naturally, and is the |
139 |
only part that can be encrypted. Data packets contain more fields, as |
140 |
shown: |
141 |
|
142 |
+------+------+--------+------+-------+------+ |
143 |
| HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
144 |
+------+------+--------+------+-------+------+ |
145 |
|
146 |
RAND is a sequence of fully random bytes, used to increase the entropy of |
147 |
the data for encryption purposes. |
148 |
|
149 |
SEQNO is a 32-bit sequence number. It is negotiated at every connection |
150 |
initialization and starts at some random 31 bit value. VPE currently uses |
151 |
a sliding window of 512 packets/sequence numbers to detect reordering, |
152 |
duplication and reply attacks. |
153 |
|
154 |
=head2 The authentification protocol |
155 |
|
156 |
Before hosts can exchange packets, they need to establish authenticity of |
157 |
the other side and a key. Every host has a private RSA key and the public |
158 |
RSA keys of all other hosts. |
159 |
|
160 |
A host establishes a simplex connection by sending the other host a |
161 |
RSA encrypted challenge containing a random challenge (consisting of |
162 |
the encryption key to use when sending packets, more random data and |
163 |
PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
164 |
duplicate auth packets). The destination host will respond by replying |
165 |
with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
166 |
will authentify that host. The destination host will also set the outgoing |
167 |
encryption parameters as given in the packet. |
168 |
|
169 |
When the source host receives a correct auth reply (by verifying the |
170 |
hash and the id, which will expire after 120 seconds), it will start to |
171 |
accept data packets from the destination host. |
172 |
|
173 |
This means that a host can only initate a simplex connection, telling the |
174 |
other side the key it has to use when it sends packets. The challenge |
175 |
reply is only used to set the current IP address of the other side and |
176 |
protocol parameters. |
177 |
|
178 |
This protocol is completely symmetric, so to be able to send packets the |
179 |
destination host must send a challenge in the exact same way as already |
180 |
described (so, in essence, two simplex connections are created per host |
181 |
pair). |
182 |
|
183 |
=head2 Retrying |
184 |
|
185 |
When there is no response to an auth request, the host will send auth |
186 |
requests in bursts with an exponential backoff. After some time it will |
187 |
resort to PING packets, which are very small (8 bytes) and lightweight |
188 |
(no RSA operations required). A host that receives ping requests from an |
189 |
unconnected peer will respond by trying to create a connection. |
190 |
|
191 |
In addition to the exponential backoff, there is a global rate-limit on |
192 |
a per-IP base. It allows long bursts but will limit total packet rate to |
193 |
something like one control packet every ten seconds, to avoid accidental |
194 |
floods due to protocol problems (like a RSA key file mismatch between two |
195 |
hosts). |
196 |
|
197 |
=head2 Routing and Protocol translation |
198 |
|
199 |
The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
200 |
tries to establish direct connections, if the protocol abilities of the |
201 |
two hosts allow it. |
202 |
|
203 |
If the two hosts should be able to reach each other (common protocol, ip |
204 |
and port all known), but cannot (network down), then there will be no |
205 |
connection, point. |
206 |
|
207 |
A host can usually declare itself unreachable directly by setting it's |
208 |
port number(s) to zero. It can declare other hosts as unreachable by using |
209 |
a config-file that disables all protocols for these other hosts. |
210 |
|
211 |
If two hosts cannot connect to each other because their IP address(es) |
212 |
are not known (such as dialup hosts), one side will send a connection |
213 |
request to a router (routers must be configured to act as routers!), which |
214 |
will send both the originating and the destination host a connection info |
215 |
request with protocol information and IP address of the other host (if |
216 |
known). Both hosts will then try to establish a connection to the other |
217 |
peer, which is usually possible even when both hosts are behind a NAT |
218 |
gateway. |
219 |
|
220 |
If the hosts cannot reach each other because they have no common protocol, |
221 |
the originator instead use the router with highest priority and matching |
222 |
protocol as peer. Since the SRCDST field is not encrypted, the router host |
223 |
can just forward the packet to the destination host. Since each host uses |
224 |
it's own private key, the router will not be able to decrypt or encrypt |
225 |
packets, it will just act as a simple router and protocol translator. |
226 |
|
227 |
When no router is connected, the host will aggressively try to connect to |
228 |
all routers, and if a router is asked for an unconnected host it will try |
229 |
to ask another router to establish the connection. |
230 |
|
231 |
... more not yet written about the details of the routing, please bug me |
232 |
... |
233 |
|