… | |
… | |
23 | =head2 RAW IP |
23 | =head2 RAW IP |
24 | |
24 | |
25 | This protocol is the best choice, performance-wise, as the minimum |
25 | This protocol is the best choice, performance-wise, as the minimum |
26 | overhead per packet is only 38 bytes. |
26 | overhead per packet is only 38 bytes. |
27 | |
27 | |
28 | It works by sending the VPN payload using raw ip frames (using the |
28 | It works by sending the VPN payload using raw IP frames (using the |
29 | protocol set by C<ip-proto>). |
29 | protocol set by C<ip-proto>). |
30 | |
30 | |
31 | Using raw ip frames has the drawback that many firewalls block "unknown" |
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 |
32 | protocols, so this transport only works if you have full IP connectivity |
33 | between nodes. |
33 | between nodes. |
34 | |
34 | |
35 | =head2 ICMP |
35 | =head2 ICMP |
36 | |
36 | |
… | |
… | |
38 | sometimes tunnel through firewalls when other protocols can not. |
38 | sometimes tunnel through firewalls when other protocols can not. |
39 | |
39 | |
40 | It works by prepending an ICMP header with type C<icmp-type> and a code |
40 | It works by prepending an 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 |
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 |
42 | packets look like echo replies, which looks rather strange to network |
43 | admins. |
43 | administrators. |
44 | |
44 | |
45 | This transport should only be used if other transports (i.e. raw ip) are |
45 | This transport should only be used if other transports (i.e. raw IP) are |
46 | not available or undesirable (due to their overhead). |
46 | not available or undesirable (due to their overhead). |
47 | |
47 | |
48 | =head2 UDP |
48 | =head2 UDP |
49 | |
49 | |
50 | This is a good general choice for the transport protocol as UDP packets |
50 | This is a good general choice for the transport protocol as UDP packets |
… | |
… | |
89 | traffic even if it doesn't need to transport packets. |
89 | traffic even if it doesn't need to transport packets. |
90 | |
90 | |
91 | In addition, the same problems as the TCP transport also plague this |
91 | In addition, the same problems as the TCP transport also plague this |
92 | protocol. |
92 | protocol. |
93 | |
93 | |
94 | It's only use is to tunnel through firewalls that do not allow direct |
94 | Its 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 |
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> |
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, |
97 | configuration value) as a proxy to send and receive data as a client, |
98 | and an C<NS> record pointing to the GVPE server (as given by the |
98 | and an C<NS> record pointing to the GVPE server (as given by the |
99 | C<dns-hostname> directive). |
99 | C<dns-hostname> directive). |
100 | |
100 | |
101 | The only good side of this protocol is that it can tunnel through most |
101 | The only good side of this protocol is that it can tunnel through most |
102 | firewalls mostly undetected, iff the local DNS server/forwarder is sane |
102 | firewalls mostly undetected, iff the local DNS server/forwarder is sane |
103 | (which is true for most routers, WLAN gateways and nameservers). |
103 | (which is true for most routers, wireless LAN gateways and nameservers). |
104 | |
104 | |
105 | Finetuning needs to be done by editing C<src/vpn_dns.C> directly. |
105 | Fine-tuning needs to be done by editing C<src/vpn_dns.C> directly. |
106 | |
106 | |
107 | =head1 PART 2: The GNU VPE protocol |
107 | =head1 PART 2: The GNU VPE protocol |
108 | |
108 | |
109 | This section, unfortunately, is not yet finished, although the protocol |
109 | This section, unfortunately, is not yet finished, although the protocol |
110 | is stable (until bugs in the cryptography are found, which will likely |
110 | is stable (until bugs in the cryptography are found, which will likely |
… | |
… | |
112 | you some overview over the protocol. |
112 | you some overview over the protocol. |
113 | |
113 | |
114 | =head2 Anatomy of a VPN packet |
114 | =head2 Anatomy of a VPN packet |
115 | |
115 | |
116 | The exact layout and field lengths of a VPN packet is determined at |
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 |
117 | compile time and doesn't change. The same structure is used for all |
118 | transort protocols, be it RAWIP or TCP. |
118 | transport protocols, be it RAWIP or TCP. |
119 | |
119 | |
120 | +------+------+--------+------+ |
120 | +------+------+--------+------+ |
121 | | HMAC | TYPE | SRCDST | DATA | |
121 | | HMAC | TYPE | SRCDST | DATA | |
122 | +------+------+--------+------+ |
122 | +------+------+--------+------+ |
123 | |
123 | |
… | |
… | |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
149 | duplication and replay attacks. |
149 | duplication and replay attacks. |
150 | |
150 | |
151 | =head2 The authentication protocol |
151 | =head2 The authentication protocol |
152 | |
152 | |
153 | Before hosts can exchange packets, they need to establish authenticity of |
153 | Before nodes can exchange packets, they need to establish authenticity of |
154 | the other side and a key. Every host has a private RSA key and the public |
154 | the other side and a key. Every node has a private RSA key and the public |
155 | RSA keys of all other hosts. |
155 | RSA keys of all other nodes. |
156 | |
156 | |
157 | A host establishes a simplex connection by sending the other host an |
157 | A host establishes a simplex connection by sending the other node an RSA |
158 | RSA encrypted challenge containing a random challenge (consisting of |
158 | encrypted challenge containing a random challenge (consisting of the |
159 | the encryption key to use when sending packets, more random data and |
159 | encryption and authentication keys to use when sending packets, more |
160 | PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
160 | random data and PKCS1_OAEP padding) and a random 16 byte "challenge-id" |
161 | duplicate auth packets). The destination host will respond by replying |
161 | (used to detect duplicate auth packets). The destination node will respond |
162 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
162 | by replying with an (unencrypted) hash of the decrypted challenge, which |
163 | will authenticate that host. The destination host will also set the |
163 | will authenticate that node. The destination node will also set the |
164 | outgoing encryption parameters as given in the packet. |
164 | outgoing encryption parameters as given in the packet. |
165 | |
165 | |
166 | When the source host receives a correct auth reply (by verifying the |
166 | When the source node receives a correct auth reply (by verifying the |
167 | hash and the id, which will expire after 120 seconds), it will start to |
167 | hash and the id, which will expire after 120 seconds), it will start to |
168 | accept data packets from the destination host. |
168 | accept data packets from the destination node. |
169 | |
169 | |
170 | This means that a host can only initate a simplex connection, telling the |
170 | This means that a node can only initiate a simplex connection, telling the |
171 | other side the key it has to use when it sends packets. The challenge |
171 | other side the key it has to use when it sends packets. The challenge |
172 | reply is only used to set the current IP address of the other side and |
172 | reply is only used to set the current IP address of the other side and |
173 | protocol parameters. |
173 | protocol parameters. |
174 | |
174 | |
175 | This protocol is completely symmetric, so to be able to send packets the |
175 | This protocol is completely symmetric, so to be able to send packets the |
176 | destination host must send a challenge in the exact same way as already |
176 | destination node must send a challenge in the exact same way as already |
177 | described (so, in essence, two simplex connections are created per host |
177 | described (so, in essence, two simplex connections are created per node |
178 | pair). |
178 | pair). |
179 | |
179 | |
180 | =head2 Retrying |
180 | =head2 Retrying |
181 | |
181 | |
182 | When there is no response to an auth request, the host will send auth |
182 | When there is no response to an auth request, the node will send auth |
183 | requests in bursts with an exponential backoff. After some time it will |
183 | requests in bursts with an exponential back-off. After some time it will |
184 | resort to PING packets, which are very small (8 bytes + protocol header) |
184 | resort to PING packets, which are very small (8 bytes + protocol header) |
185 | and lightweight (no RSA operations required). A host that receives ping |
185 | and lightweight (no RSA operations required). A node that receives ping |
186 | requests from an unconnected peer will respond by trying to create a |
186 | requests from an unconnected peer will respond by trying to create a |
187 | connection. |
187 | connection. |
188 | |
188 | |
189 | In addition to the exponential backoff, there is a global rate-limit on |
189 | In addition to the exponential back-off, there is a global rate-limit on |
190 | a per-IP base. It allows long bursts but will limit total packet rate to |
190 | a per-IP base. It allows long bursts but will limit total packet rate to |
191 | something like one control packet every ten seconds, to avoid accidental |
191 | something like one control packet every ten seconds, to avoid accidental |
192 | floods due to protocol problems (like a RSA key file mismatch between two |
192 | floods due to protocol problems (like a RSA key file mismatch between two |
193 | hosts). |
193 | nodes). |
194 | |
194 | |
195 | The intervals between retries are limited by the C<max-retry> |
195 | The intervals between retries are limited by the C<max-retry> |
196 | configuration value. A node with C<connect> = C<always> will always 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 |
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 |
198 | as long as there are packets in the queue, usually this limits the retry |
… | |
… | |
203 | will try to connect every few seconds. |
203 | will try to connect every few seconds. |
204 | |
204 | |
205 | =head2 Routing and Protocol translation |
205 | =head2 Routing and Protocol translation |
206 | |
206 | |
207 | The GVPE routing algorithm is easy: there isn't much routing to speak |
207 | 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 |
208 | of: When routing packets to another node, GVPE tries the following |
209 | options, in order: |
209 | options, in order: |
210 | |
210 | |
211 | =over 4 |
211 | =over 4 |
212 | |
212 | |
213 | =item If the two hosts should be able to reach each other directly (common |
213 | =item If the two nodes should be able to reach each other directly (common |
214 | protocol, port known), then GVPE will send the packet directly to the |
214 | protocol, port known), then GVPE will send the packet directly to the |
215 | other node. |
215 | other node. |
216 | |
216 | |
217 | =item If this isn't possible (e.g. because the node doesn't have a |
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 |
218 | C<hostname> or known port), but the nodes speak a common protocol and a |
… | |
… | |
236 | port number(s) to zero. It can declare other hosts as unreachable by using |
236 | port number(s) to zero. It can declare other hosts as unreachable by using |
237 | a config-file that disables all protocols for these other hosts. Another |
237 | 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. |
238 | option is to disable all protocols on that host in the other config files. |
239 | |
239 | |
240 | If two hosts cannot connect to each other because their IP address(es) |
240 | If two hosts cannot connect to each other because their IP address(es) |
241 | are not known (such as dialup hosts), one side will send a I<mediated> |
241 | are not known (such as dial-up hosts), one side will send a I<mediated> |
242 | connection request to a router (routers must be configured to act as |
242 | connection request to a router (routers must be configured to act as |
243 | routers!), which will send both the originating and the destination host |
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 |
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 |
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 |
246 | connection to the other peer, which is usually possible even when both |