1 |
pcg |
1.2 |
=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 |
pcg |
1.5 |
=head1 PART 1: Transport protocols |
14 |
pcg |
1.2 |
|
15 |
pcg |
1.6 |
GVPE offers a wide range of transport protocols that can be used to |
16 |
|
|
interchange data between nodes. Protocols differ in their overhead, speed, |
17 |
pcg |
1.3 |
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 |
pcg |
1.4 |
transport is listed first: |
22 |
pcg |
1.3 |
|
23 |
pcg |
1.2 |
=head2 RAW IP |
24 |
|
|
|
25 |
pcg |
1.3 |
This protocol is the best choice, performance-wise, as the minimum |
26 |
|
|
overhead per packet is only 38 bytes. |
27 |
|
|
|
28 |
pcg |
1.7 |
It works by sending the VPN payload using raw IP frames (using the |
29 |
pcg |
1.3 |
protocol set by C<ip-proto>). |
30 |
|
|
|
31 |
pcg |
1.7 |
Using raw IP frames has the drawback that many firewalls block "unknown" |
32 |
pcg |
1.3 |
protocols, so this transport only works if you have full IP connectivity |
33 |
|
|
between nodes. |
34 |
|
|
|
35 |
pcg |
1.2 |
=head2 ICMP |
36 |
|
|
|
37 |
pcg |
1.3 |
This protocol offers very low overhead (minimum 42 bytes), and can |
38 |
pcg |
1.6 |
sometimes tunnel through firewalls when other protocols can not. |
39 |
pcg |
1.3 |
|
40 |
pcg |
1.6 |
It works by prepending an ICMP header with type C<icmp-type> and a code |
41 |
pcg |
1.3 |
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 |
pcg |
1.7 |
administrators. |
44 |
pcg |
1.3 |
|
45 |
pcg |
1.7 |
This transport should only be used if other transports (i.e. raw IP) are |
46 |
pcg |
1.3 |
not available or undesirable (due to their overhead). |
47 |
|
|
|
48 |
pcg |
1.2 |
=head2 UDP |
49 |
|
|
|
50 |
pcg |
1.3 |
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 |
pcg |
1.2 |
=head2 TCP |
57 |
|
|
|
58 |
pcg |
1.3 |
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 |
pcg |
1.6 |
This protocol also has server and client sides. If the C<tcp-port> is |
74 |
|
|
set to zero, other nodes cannot connect to this node directly. If the |
75 |
|
|
C<tcp-port> is non-zero, the node can act both as a client as well as a |
76 |
|
|
server. |
77 |
pcg |
1.3 |
|
78 |
pcg |
1.2 |
=head2 DNS |
79 |
|
|
|
80 |
pcg |
1.3 |
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 |
|
|
It's only use is to tunnel through firewalls that do not allow direct |
95 |
|
|
internet access. Similar to using a HTTP proxy (as the TCP transport |
96 |
|
|
does), it uses a local DNS server/forwarder (given by the C<dns-forw-host> |
97 |
|
|
configuration value) as a proxy to send and receive data as a client, |
98 |
pcg |
1.6 |
and an C<NS> record pointing to the GVPE server (as given by the |
99 |
pcg |
1.3 |
C<dns-hostname> directive). |
100 |
|
|
|
101 |
|
|
The only good side of this protocol is that it can tunnel through most |
102 |
pcg |
1.6 |
firewalls mostly undetected, iff the local DNS server/forwarder is sane |
103 |
pcg |
1.7 |
(which is true for most routers, wireless LAN gateways and nameservers). |
104 |
pcg |
1.6 |
|
105 |
pcg |
1.7 |
Fine-tuning needs to be done by editing C<src/vpn_dns.C> directly. |
106 |
pcg |
1.3 |
|
107 |
pcg |
1.2 |
=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 |
pcg |
1.1 |
|
114 |
|
|
=head2 Anatomy of a VPN packet |
115 |
|
|
|
116 |
|
|
The exact layout and field lengths of a VPN packet is determined at |
117 |
pcg |
1.7 |
compile time and doesn't change. The same structure is used for all |
118 |
|
|
transport protocols, be it RAWIP or TCP. |
119 |
pcg |
1.1 |
|
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 |
pcg |
1.2 |
itself is calculated over the TYPE, SRCDST and DATA fields in all cases. |
127 |
pcg |
1.1 |
|
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 |
pcg |
1.6 |
node IDs (12 bits each). |
134 |
pcg |
1.1 |
|
135 |
|
|
The DATA portion differs between each packet type, naturally, and is the |
136 |
|
|
only part that can be encrypted. Data packets contain more fields, as |
137 |
|
|
shown: |
138 |
|
|
|
139 |
|
|
+------+------+--------+------+-------+------+ |
140 |
|
|
| HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
141 |
|
|
+------+------+--------+------+-------+------+ |
142 |
|
|
|
143 |
|
|
RAND is a sequence of fully random bytes, used to increase the entropy of |
144 |
|
|
the data for encryption purposes. |
145 |
|
|
|
146 |
|
|
SEQNO is a 32-bit sequence number. It is negotiated at every connection |
147 |
|
|
initialization and starts at some random 31 bit value. VPE currently uses |
148 |
pcg |
1.2 |
a sliding window of 512 packets/sequence numbers to detect reordering, |
149 |
pcg |
1.6 |
duplication and replay attacks. |
150 |
pcg |
1.1 |
|
151 |
pcg |
1.6 |
=head2 The authentication protocol |
152 |
pcg |
1.1 |
|
153 |
pcg |
1.7 |
Before nodes can exchange packets, they need to establish authenticity of |
154 |
|
|
the other side and a key. Every node has a private RSA key and the public |
155 |
|
|
RSA keys of all other nodes. |
156 |
pcg |
1.1 |
|
157 |
pcg |
1.7 |
A host establishes a simplex connection by sending the other node an |
158 |
pcg |
1.1 |
RSA encrypted challenge containing a random challenge (consisting of |
159 |
|
|
the encryption key to use when sending packets, more random data and |
160 |
|
|
PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
161 |
pcg |
1.7 |
duplicate auth packets). The destination node will respond by replying |
162 |
pcg |
1.1 |
with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
163 |
pcg |
1.7 |
will authenticate that node. The destination node will also set the |
164 |
pcg |
1.6 |
outgoing encryption parameters as given in the packet. |
165 |
pcg |
1.1 |
|
166 |
pcg |
1.7 |
When the source node receives a correct auth reply (by verifying the |
167 |
pcg |
1.1 |
hash and the id, which will expire after 120 seconds), it will start to |
168 |
pcg |
1.7 |
accept data packets from the destination node. |
169 |
pcg |
1.1 |
|
170 |
pcg |
1.7 |
This means that a node can only initiate a simplex connection, telling the |
171 |
pcg |
1.1 |
other side the key it has to use when it sends packets. The challenge |
172 |
pcg |
1.2 |
reply is only used to set the current IP address of the other side and |
173 |
|
|
protocol parameters. |
174 |
pcg |
1.1 |
|
175 |
pcg |
1.2 |
This protocol is completely symmetric, so to be able to send packets the |
176 |
pcg |
1.7 |
destination node must send a challenge in the exact same way as already |
177 |
|
|
described (so, in essence, two simplex connections are created per node |
178 |
pcg |
1.2 |
pair). |
179 |
pcg |
1.1 |
|
180 |
|
|
=head2 Retrying |
181 |
|
|
|
182 |
pcg |
1.7 |
When there is no response to an auth request, the node will send auth |
183 |
|
|
requests in bursts with an exponential back-off. After some time it will |
184 |
pcg |
1.6 |
resort to PING packets, which are very small (8 bytes + protocol header) |
185 |
pcg |
1.7 |
and lightweight (no RSA operations required). A node that receives ping |
186 |
pcg |
1.6 |
requests from an unconnected peer will respond by trying to create a |
187 |
|
|
connection. |
188 |
pcg |
1.1 |
|
189 |
pcg |
1.7 |
In addition to the exponential back-off, there is a global rate-limit on |
190 |
pcg |
1.2 |
a per-IP base. It allows long bursts but will limit total packet rate to |
191 |
pcg |
1.1 |
something like one control packet every ten seconds, to avoid accidental |
192 |
pcg |
1.2 |
floods due to protocol problems (like a RSA key file mismatch between two |
193 |
pcg |
1.7 |
nodes). |
194 |
pcg |
1.1 |
|
195 |
pcg |
1.6 |
The intervals between retries are limited by the C<max-retry> |
196 |
|
|
configuration value. A node with C<connect> = C<always> will always retry, |
197 |
|
|
a node with C<connect> = C<ondemand> will only try (and re-try) to connect |
198 |
|
|
as long as there are packets in the queue, usually this limits the retry |
199 |
|
|
period to C<max-ttl> seconds. |
200 |
|
|
|
201 |
|
|
Sending packets over the VPN will reset the retry intervals as well, which |
202 |
|
|
means as long as somebody is trying to send packets to a given node, GVPE |
203 |
|
|
will try to connect every few seconds. |
204 |
|
|
|
205 |
pcg |
1.1 |
=head2 Routing and Protocol translation |
206 |
|
|
|
207 |
pcg |
1.6 |
The GVPE routing algorithm is easy: there isn't much routing to speak |
208 |
|
|
of: When routing packets to another node, GVPE trues the following |
209 |
|
|
options, in order: |
210 |
|
|
|
211 |
|
|
=over 4 |
212 |
|
|
|
213 |
pcg |
1.7 |
=item If the two nodes should be able to reach each other directly (common |
214 |
pcg |
1.6 |
protocol, port known), then GVPE will send the packet directly to the |
215 |
|
|
other node. |
216 |
|
|
|
217 |
|
|
=item If this isn't possible (e.g. because the node doesn't have a |
218 |
|
|
C<hostname> or known port), but the nodes speak a common protocol and a |
219 |
|
|
router is available, then GVPE will ask a router to "mediate" between both |
220 |
|
|
nodes (see below). |
221 |
|
|
|
222 |
|
|
=item If a direct connection isn't possible (no common protocols) or |
223 |
|
|
forbidden (C<deny-direct>) and there are any routers, then GVPE will try |
224 |
|
|
to send packets to the router with the highest priority that is connected |
225 |
|
|
already I<and> is able (as specified by the config file) to connect |
226 |
|
|
directly to the target node. |
227 |
|
|
|
228 |
|
|
=item If no such router exists, then GVPE will simply send the packet to |
229 |
|
|
the node with the highest priority available. |
230 |
|
|
|
231 |
|
|
=item Failing all that, the packet will be dropped. |
232 |
|
|
|
233 |
|
|
=back |
234 |
pcg |
1.1 |
|
235 |
|
|
A host can usually declare itself unreachable directly by setting it's |
236 |
|
|
port number(s) to zero. It can declare other hosts as unreachable by using |
237 |
pcg |
1.6 |
a config-file that disables all protocols for these other hosts. Another |
238 |
|
|
option is to disable all protocols on that host in the other config files. |
239 |
pcg |
1.1 |
|
240 |
|
|
If two hosts cannot connect to each other because their IP address(es) |
241 |
pcg |
1.7 |
are not known (such as dial-up hosts), one side will send a I<mediated> |
242 |
pcg |
1.6 |
connection request to a router (routers must be configured to act as |
243 |
|
|
routers!), which will send both the originating and the destination host |
244 |
|
|
a connection info request with protocol information and IP address of the |
245 |
|
|
other host (if known). Both hosts will then try to establish a direct |
246 |
|
|
connection to the other peer, which is usually possible even when both |
247 |
|
|
hosts are behind a NAT gateway. |
248 |
|
|
|
249 |
|
|
Routing via other nodes works because the SRCDST field is not encrypted, |
250 |
|
|
so the router can just forward the packet to the destination host. Since |
251 |
|
|
each host uses it's own private key, the router will not be able to |
252 |
|
|
decrypt or encrypt packets, it will just act as a simple router and |
253 |
|
|
protocol translator. |
254 |
pcg |
1.1 |
|
255 |
|
|
|