… | |
… | |
8 | document. |
8 | document. |
9 | |
9 | |
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: Tansport protocols |
13 | =head1 PART 1: Transport protocols |
|
|
14 | |
|
|
15 | 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 | 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: |
14 | |
22 | |
15 | =head2 RAW IP |
23 | =head2 RAW IP |
16 | |
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 | |
17 | =head2 ICMP |
35 | =head2 ICMP |
18 | |
36 | |
|
|
37 | This protocol offers very low overhead (minimum 42 bytes), and can |
|
|
38 | sometimes tunnel through firewalls when other protocols can not. |
|
|
39 | |
|
|
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 |
|
|
42 | packets look like echo replies, which looks rather strange to network |
|
|
43 | administrators. |
|
|
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 | |
19 | =head2 UDP |
48 | =head2 UDP |
20 | |
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 | |
21 | =head2 TCP |
56 | =head2 TCP |
22 | |
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 |
|
|
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 | |
23 | =head2 DNS |
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 | 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 |
|
|
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 | and an C<NS> record pointing to the GVPE server (as given by the |
|
|
99 | C<dns-hostname> directive). |
|
|
100 | |
|
|
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 |
|
|
103 | (which is true for most routers, wireless LAN gateways and nameservers). |
|
|
104 | |
|
|
105 | Fine-tuning needs to be done by editing C<src/vpn_dns.C> directly. |
24 | |
106 | |
25 | =head1 PART 2: The GNU VPE protocol |
107 | =head1 PART 2: The GNU VPE protocol |
26 | |
108 | |
27 | This section, unfortunately, is not yet finished, although the protocol |
109 | This section, unfortunately, is not yet finished, although the protocol |
28 | 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 |
… | |
… | |
30 | you some overview over the protocol. |
112 | you some overview over the protocol. |
31 | |
113 | |
32 | =head2 Anatomy of a VPN packet |
114 | =head2 Anatomy of a VPN packet |
33 | |
115 | |
34 | 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 |
35 | 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 |
36 | transort protocols, be it RAWIP or TCP. |
118 | transport protocols, be it RAWIP or TCP. |
37 | |
119 | |
38 | +------+------+--------+------+ |
120 | +------+------+--------+------+ |
39 | | HMAC | TYPE | SRCDST | DATA | |
121 | | HMAC | TYPE | SRCDST | DATA | |
40 | +------+------+--------+------+ |
122 | +------+------+--------+------+ |
41 | |
123 | |
… | |
… | |
46 | 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 |
47 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
129 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
48 | CONNECT REQUEST/INFO etc.). |
130 | CONNECT REQUEST/INFO etc.). |
49 | |
131 | |
50 | 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 |
51 | node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
133 | node IDs (12 bits each). |
52 | hosts, since all hosts must connect to each other once on startup. But if |
|
|
53 | restarts are rare or tolerable and most connections are on demand, much |
|
|
54 | larger networks are feasible. |
|
|
55 | |
134 | |
56 | 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 |
57 | 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 |
58 | shown: |
137 | shown: |
59 | |
138 | |
… | |
… | |
65 | the data for encryption purposes. |
144 | the data for encryption purposes. |
66 | |
145 | |
67 | 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 |
68 | 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 |
69 | a sliding window of 512 packets/sequence numbers to detect reordering, |
148 | a sliding window of 512 packets/sequence numbers to detect reordering, |
70 | duplication and reply attacks. |
149 | duplication and replay attacks. |
71 | |
150 | |
72 | =head2 The authentification protocol |
151 | =head2 The authentication protocol |
73 | |
152 | |
74 | Before hosts can exchange packets, they need to establish authenticity of |
153 | Before nodes can exchange packets, they need to establish authenticity of |
75 | 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 |
76 | RSA keys of all other hosts. |
155 | RSA keys of all other nodes. |
77 | |
156 | |
78 | A host establishes a simplex connection by sending the other host a |
157 | A host establishes a simplex connection by sending the other node an |
79 | RSA encrypted challenge containing a random challenge (consisting of |
158 | RSA encrypted challenge containing a random challenge (consisting of |
80 | 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 |
81 | 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 |
82 | duplicate auth packets). The destination host will respond by replying |
161 | duplicate auth packets). The destination node will respond by replying |
83 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
162 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
84 | will authentify that host. The destination host will also set the outgoing |
163 | will authenticate that node. The destination node will also set the |
85 | encryption parameters as given in the packet. |
164 | outgoing encryption parameters as given in the packet. |
86 | |
165 | |
87 | 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 |
88 | 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 |
89 | accept data packets from the destination host. |
168 | accept data packets from the destination node. |
90 | |
169 | |
91 | 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 |
92 | 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 |
93 | 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 |
94 | protocol parameters. |
173 | protocol parameters. |
95 | |
174 | |
96 | 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 |
97 | 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 |
98 | described (so, in essence, two simplex connections are created per host |
177 | described (so, in essence, two simplex connections are created per node |
99 | pair). |
178 | pair). |
100 | |
179 | |
101 | =head2 Retrying |
180 | =head2 Retrying |
102 | |
181 | |
103 | 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 |
104 | 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 |
105 | 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) |
106 | (no RSA operations required). A host that receives ping requests from an |
185 | and lightweight (no RSA operations required). A node that receives ping |
107 | 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. |
108 | |
188 | |
109 | 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 |
110 | 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 |
111 | something like one control packet every ten seconds, to avoid accidental |
191 | something like one control packet every ten seconds, to avoid accidental |
112 | 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 |
113 | hosts). |
193 | nodes). |
|
|
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. |
114 | |
204 | |
115 | =head2 Routing and Protocol translation |
205 | =head2 Routing and Protocol translation |
116 | |
206 | |
117 | 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 |
118 | tries to establish direct connections, if the protocol abilities of the |
208 | of: When routing packets to another node, GVPE trues the following |
119 | two hosts allow it. |
209 | options, in order: |
120 | |
210 | |
|
|
211 | =over 4 |
|
|
212 | |
121 | If the two hosts should be able to reach each other (common protocol, ip |
213 | =item If the two nodes should be able to reach each other directly (common |
122 | 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 |
123 | 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 |
124 | |
234 | |
125 | 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 |
126 | 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 |
127 | 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. |
128 | |
239 | |
129 | 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) |
130 | are not known (such as dialup hosts), one side will send a connection |
241 | are not known (such as dial-up hosts), one side will send a I<mediated> |
131 | 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 |
132 | will send both the originating and the destination host a connection info |
243 | routers!), which will send both the originating and the destination host |
133 | 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 |
134 | 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 |
135 | 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 |
136 | gateway. |
247 | hosts are behind a NAT gateway. |
137 | |
248 | |
138 | 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, |
139 | the originator instead use the router with highest priority and matching |
|
|
140 | protocol as peer. Since the SRCDST field is not encrypted, the router host |
|
|
141 | 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 |
142 | 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 |
143 | 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. |
144 | |
254 | |
145 | When no router is connected, the host will aggressively try to connect to |
|
|
146 | all routers, and if a router is asked for an unconnected host it will try |
|
|
147 | to ask another router to establish the connection. |
|
|
148 | |
255 | |
149 | ... more not yet written about the details of the routing, please bug me |
|
|
150 | ... |
|
|
151 | |
|
|