… | |
… | |
10 | The first part of this document describes the transport protocols which |
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. |
11 | are used by GVPE to send it's data packets over the network. |
12 | |
12 | |
13 | =head1 PART 1: Transport protocols |
13 | =head1 PART 1: Transport protocols |
14 | |
14 | |
15 | GVPE offers a range of transport protocols that can be used to interchange |
15 | GVPE offers a wide range of transport protocols that can be used to |
16 | data between nodes. Protocols differ in their overhead, speed, |
16 | interchange data between nodes. Protocols differ in their overhead, speed, |
17 | reliability, and robustness. |
17 | reliability, and robustness. |
18 | |
18 | |
19 | The following sections describe each transport protocol in more |
19 | The following sections describe each transport protocol in more |
20 | detail. They are sorted by overhead/efficiency, the most efficient |
20 | detail. They are sorted by overhead/efficiency, the most efficient |
21 | transport is listed first: |
21 | transport is listed first: |
… | |
… | |
33 | between nodes. |
33 | between nodes. |
34 | |
34 | |
35 | =head2 ICMP |
35 | =head2 ICMP |
36 | |
36 | |
37 | This protocol offers very low overhead (minimum 42 bytes), and can |
37 | This protocol offers very low overhead (minimum 42 bytes), and can |
38 | sometimes tunnel through firewalls when other protocols cannot. |
38 | sometimes tunnel through firewalls when other protocols can not. |
39 | |
39 | |
40 | It works by prepending a 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 | admins. |
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 |
… | |
… | |
68 | most proxies do not allow connections to other ports. |
68 | most proxies do not allow connections to other ports. |
69 | |
69 | |
70 | It is an abuse of the usage a proxy was designed for, so make sure you are |
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. |
71 | allowed to use it for GVPE. |
72 | |
72 | |
73 | This protocol also has server and client sides. If the C<tcp-port> is set |
73 | This protocol also has server and client sides. If the C<tcp-port> is |
74 | to zero, other nodes cannot connect to this node directly (and C<tcp-port> |
74 | set to zero, other nodes cannot connect to this node directly. If the |
75 | zero cannot be used). If the C<tcp-port> is non-zero, the node can act |
75 | C<tcp-port> is non-zero, the node can act both as a client as well as a |
76 | both as a client as well as a server. |
76 | server. |
77 | |
77 | |
78 | =head2 DNS |
78 | =head2 DNS |
79 | |
79 | |
80 | B<WARNING:> Parsing and generating DNS packets is rather tricky. The code |
80 | B<WARNING:> Parsing and generating DNS packets is rather tricky. The code |
81 | almost certainly contains buffer overflows and other, likely exploitable, |
81 | almost certainly contains buffer overflows and other, likely exploitable, |
… | |
… | |
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 | 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 |
94 | 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 |
95 | 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> |
96 | 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, |
97 | 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 |
98 | and an C<NS> record pointing to the GVPE server (as given by the |
101 | C<dns-hostname> directive). |
99 | C<dns-hostname> directive). |
102 | |
100 | |
103 | 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 |
104 | firewalls undetected, iff the local DNS server/forwarder is sane (which is |
102 | firewalls mostly undetected, iff the local DNS server/forwarder is sane |
105 | true for most routers, wlan gateways and nameservers). |
103 | (which is true for most routers, WLAN gateways and nameservers). |
|
|
104 | |
|
|
105 | Finetuning 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 |
… | |
… | |
128 | The TYPE field is a single byte and determines the purpose of the packet |
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, |
129 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
130 | CONNECT REQUEST/INFO etc.). |
130 | CONNECT REQUEST/INFO etc.). |
131 | |
131 | |
132 | SRCDST is a three byte field which contains the source and destination |
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+ |
133 | node IDs (12 bits each). |
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 | |
134 | |
138 | The DATA portion differs between each packet type, naturally, and is the |
135 | 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 |
136 | only part that can be encrypted. Data packets contain more fields, as |
140 | shown: |
137 | shown: |
141 | |
138 | |
… | |
… | |
147 | the data for encryption purposes. |
144 | the data for encryption purposes. |
148 | |
145 | |
149 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
146 | 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 |
147 | initialization and starts at some random 31 bit value. VPE currently uses |
151 | a sliding window of 512 packets/sequence numbers to detect reordering, |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
152 | duplication and reply attacks. |
149 | duplication and replay attacks. |
153 | |
150 | |
154 | =head2 The authentification protocol |
151 | =head2 The authentication protocol |
155 | |
152 | |
156 | Before hosts can exchange packets, they need to establish authenticity of |
153 | 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 |
154 | the other side and a key. Every host has a private RSA key and the public |
158 | RSA keys of all other hosts. |
155 | RSA keys of all other hosts. |
159 | |
156 | |
160 | A host establishes a simplex connection by sending the other host a |
157 | A host establishes a simplex connection by sending the other host an |
161 | RSA encrypted challenge containing a random challenge (consisting of |
158 | RSA encrypted challenge containing a random challenge (consisting of |
162 | 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 |
163 | 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 |
164 | duplicate auth packets). The destination host will respond by replying |
161 | duplicate auth packets). The destination host will respond by replying |
165 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
162 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
166 | will authentify that host. The destination host will also set the outgoing |
163 | will authenticate that host. The destination host will also set the |
167 | encryption parameters as given in the packet. |
164 | outgoing encryption parameters as given in the packet. |
168 | |
165 | |
169 | When the source host receives a correct auth reply (by verifying the |
166 | 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 |
167 | hash and the id, which will expire after 120 seconds), it will start to |
171 | accept data packets from the destination host. |
168 | accept data packets from the destination host. |
172 | |
169 | |
… | |
… | |
182 | |
179 | |
183 | =head2 Retrying |
180 | =head2 Retrying |
184 | |
181 | |
185 | 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 host will send auth |
186 | requests in bursts with an exponential backoff. After some time it will |
183 | 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 |
184 | resort to PING packets, which are very small (8 bytes + protocol header) |
188 | (no RSA operations required). A host that receives ping requests from an |
185 | and lightweight (no RSA operations required). A host that receives ping |
189 | unconnected peer will respond by trying to create a connection. |
186 | requests from an unconnected peer will respond by trying to create a |
|
|
187 | connection. |
190 | |
188 | |
191 | In addition to the exponential backoff, there is a global rate-limit on |
189 | 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 |
190 | 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 |
191 | 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 |
192 | floods due to protocol problems (like a RSA key file mismatch between two |
195 | hosts). |
193 | hosts). |
196 | |
194 | |
|
|
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, |
|
|
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 | |
197 | =head2 Routing and Protocol translation |
205 | =head2 Routing and Protocol translation |
198 | |
206 | |
199 | The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
207 | The GVPE routing algorithm is easy: there isn't much routing to speak |
200 | tries to establish direct connections, if the protocol abilities of the |
208 | of: When routing packets to another node, GVPE trues the following |
201 | two hosts allow it. |
209 | options, in order: |
202 | |
210 | |
|
|
211 | =over 4 |
|
|
212 | |
203 | If the two hosts should be able to reach each other (common protocol, ip |
213 | =item If the two hosts should be able to reach each other directly (common |
204 | and port all known), but cannot (network down), then there will be no |
214 | protocol, port known), then GVPE will send the packet directly to the |
205 | connection, point. |
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 |
206 | |
234 | |
207 | A host can usually declare itself unreachable directly by setting it's |
235 | 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 |
236 | 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. |
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. |
210 | |
239 | |
211 | 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) |
212 | are not known (such as dialup hosts), one side will send a connection |
241 | are not known (such as dialup hosts), one side will send a I<mediated> |
213 | request to a router (routers must be configured to act as routers!), which |
242 | connection request to a router (routers must be configured to act as |
214 | will send both the originating and the destination host a connection info |
243 | routers!), which will send both the originating and the destination host |
215 | request with protocol information and IP address of the other host (if |
244 | a connection info request with protocol information and IP address of the |
216 | known). Both hosts will then try to establish a connection to the other |
245 | other host (if known). Both hosts will then try to establish a direct |
217 | peer, which is usually possible even when both hosts are behind a NAT |
246 | connection to the other peer, which is usually possible even when both |
218 | gateway. |
247 | hosts are behind a NAT gateway. |
219 | |
248 | |
220 | If the hosts cannot reach each other because they have no common protocol, |
249 | Routing via other nodes works because the SRCDST field is not encrypted, |
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 |
250 | so the router can just forward the packet to the destination host. Since |
224 | it's own private key, the router will not be able to decrypt or encrypt |
251 | each host uses it's own private key, the router will not be able to |
225 | packets, it will just act as a simple router and protocol translator. |
252 | decrypt or encrypt packets, it will just act as a simple router and |
|
|
253 | protocol translator. |
226 | |
254 | |
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 | |
255 | |
231 | ... more not yet written about the details of the routing, please bug me |
|
|
232 | ... |
|
|
233 | |
|
|