| … | |
… | |
| 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 |
| … | |
… | |
| 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 |
| 158 | RSA encrypted challenge containing a random challenge (consisting of |
158 | RSA encrypted challenge containing a random challenge (consisting of |
| 159 | the encryption key to use when sending packets, more random data and |
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 |
160 | PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
| 161 | duplicate auth packets). The destination host will respond by replying |
161 | duplicate auth packets). The destination node will respond by replying |
| 162 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
162 | with an (unencrypted) RIPEMD160 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 |
| … | |
… | |
| 208 | of: When routing packets to another node, GVPE trues the following |
208 | of: When routing packets to another node, GVPE trues 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 |
