| 1 | .\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.20) |
1 | .\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.28) |
| 2 | .\" |
2 | .\" |
| 3 | .\" Standard preamble: |
3 | .\" Standard preamble: |
| 4 | .\" ======================================================================== |
4 | .\" ======================================================================== |
| 5 | .de Sp \" Vertical space (when we can't use .PP) |
5 | .de Sp \" Vertical space (when we can't use .PP) |
| 6 | .if t .sp .5v |
6 | .if t .sp .5v |
| … | |
… | |
| 36 | .el\{\ |
36 | .el\{\ |
| 37 | . ds -- \|\(em\| |
37 | . ds -- \|\(em\| |
| 38 | . ds PI \(*p |
38 | . ds PI \(*p |
| 39 | . ds L" `` |
39 | . ds L" `` |
| 40 | . ds R" '' |
40 | . ds R" '' |
|
|
41 | . ds C` |
|
|
42 | . ds C' |
| 41 | 'br\} |
43 | 'br\} |
| 42 | .\" |
44 | .\" |
| 43 | .\" Escape single quotes in literal strings from groff's Unicode transform. |
45 | .\" Escape single quotes in literal strings from groff's Unicode transform. |
| 44 | .ie \n(.g .ds Aq \(aq |
46 | .ie \n(.g .ds Aq \(aq |
| 45 | .el .ds Aq ' |
47 | .el .ds Aq ' |
| 46 | .\" |
48 | .\" |
| 47 | .\" If the F register is turned on, we'll generate index entries on stderr for |
49 | .\" If the F register is turned on, we'll generate index entries on stderr for |
| 48 | .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index |
50 | .\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index |
| 49 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
51 | .\" entries marked with X<> in POD. Of course, you'll have to process the |
| 50 | .\" output yourself in some meaningful fashion. |
52 | .\" output yourself in some meaningful fashion. |
| 51 | .ie \nF \{\ |
53 | .\" |
|
|
54 | .\" Avoid warning from groff about undefined register 'F'. |
| 52 | . de IX |
55 | .de IX |
| 53 | . tm Index:\\$1\t\\n%\t"\\$2" |
|
|
| 54 | .. |
56 | .. |
| 55 | . nr % 0 |
57 | .nr rF 0 |
| 56 | . rr F |
58 | .if \n(.g .if rF .nr rF 1 |
| 57 | .\} |
59 | .if (\n(rF:(\n(.g==0)) \{ |
| 58 | .el \{\ |
60 | . if \nF \{ |
| 59 | . de IX |
61 | . de IX |
|
|
62 | . tm Index:\\$1\t\\n%\t"\\$2" |
| 60 | .. |
63 | .. |
|
|
64 | . if !\nF==2 \{ |
|
|
65 | . nr % 0 |
|
|
66 | . nr F 2 |
|
|
67 | . \} |
|
|
68 | . \} |
| 61 | .\} |
69 | .\} |
|
|
70 | .rr rF |
| 62 | .\" |
71 | .\" |
| 63 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
72 | .\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2). |
| 64 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
73 | .\" Fear. Run. Save yourself. No user-serviceable parts. |
| 65 | . \" fudge factors for nroff and troff |
74 | . \" fudge factors for nroff and troff |
| 66 | .if n \{\ |
75 | .if n \{\ |
| … | |
… | |
| 122 | .\} |
131 | .\} |
| 123 | .rm #[ #] #H #V #F C |
132 | .rm #[ #] #H #V #F C |
| 124 | .\" ======================================================================== |
133 | .\" ======================================================================== |
| 125 | .\" |
134 | .\" |
| 126 | .IX Title "GVPE.PROTOCOL 7" |
135 | .IX Title "GVPE.PROTOCOL 7" |
| 127 | .TH GVPE.PROTOCOL 7 "2013-07-19" "2.25" "GNU Virtual Private Ethernet" |
136 | .TH GVPE.PROTOCOL 7 "2014-04-26" "2.25" "GNU Virtual Private Ethernet" |
| 128 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
137 | .\" For nroff, turn off justification. Always turn off hyphenation; it makes |
| 129 | .\" way too many mistakes in technical documents. |
138 | .\" way too many mistakes in technical documents. |
| 130 | .if n .ad l |
139 | .if n .ad l |
| 131 | .nh |
140 | .nh |
| 132 | .SH "The GNU-VPE Protocols" |
141 | .SH "The GNU-VPE Protocols" |
| 133 | .IX Header "The GNU-VPE Protocols" |
142 | .IX Header "The GNU-VPE Protocols" |
| 134 | .SH "Overview" |
143 | .SH "Overview" |
| 135 | .IX Header "Overview" |
144 | .IX Header "Overview" |
| 136 | \&\s-1GVPE\s0 can make use of a number of protocols. One of them is the \s-1GNU\s0 \s-1VPE\s0 |
145 | \&\s-1GVPE\s0 can make use of a number of protocols. One of them is the \s-1GNU VPE\s0 |
| 137 | protocol which is used to authenticate tunnels and send encrypted data |
146 | protocol which is used to authenticate tunnels and send encrypted data |
| 138 | packets. This protocol is described in more detail the second part of this |
147 | packets. This protocol is described in more detail the second part of this |
| 139 | document. |
148 | document. |
| 140 | .PP |
149 | .PP |
| 141 | The first part of this document describes the transport protocols which |
150 | The first part of this document describes the transport protocols which |
| 142 | are used by \s-1GVPE\s0 to send it's data packets over the network. |
151 | are used by \s-1GVPE\s0 to send its data packets over the network. |
| 143 | .SH "PART 1: Transport protocols" |
152 | .SH "PART 1: Transport protocols" |
| 144 | .IX Header "PART 1: Transport protocols" |
153 | .IX Header "PART 1: Transport protocols" |
| 145 | \&\s-1GVPE\s0 offers a wide range of transport protocols that can be used to |
154 | \&\s-1GVPE\s0 offers a wide range of transport protocols that can be used to |
| 146 | interchange data between nodes. Protocols differ in their overhead, speed, |
155 | interchange data between nodes. Protocols differ in their overhead, speed, |
| 147 | reliability, and robustness. |
156 | reliability, and robustness. |
| 148 | .PP |
157 | .PP |
| 149 | The following sections describe each transport protocol in more |
158 | The following sections describe each transport protocol in more |
| 150 | detail. They are sorted by overhead/efficiency, the most efficient |
159 | detail. They are sorted by overhead/efficiency, the most efficient |
| 151 | transport is listed first: |
160 | transport is listed first: |
| 152 | .SS "\s-1RAW\s0 \s-1IP\s0" |
161 | .SS "\s-1RAW IP\s0" |
| 153 | .IX Subsection "RAW IP" |
162 | .IX Subsection "RAW IP" |
| 154 | This protocol is the best choice, performance-wise, as the minimum |
163 | This protocol is the best choice, performance-wise, as the minimum |
| 155 | overhead per packet is only 38 bytes. |
164 | overhead per packet is only 38 bytes. |
| 156 | .PP |
165 | .PP |
| 157 | It works by sending the \s-1VPN\s0 payload using raw \s-1IP\s0 frames (using the |
166 | It works by sending the \s-1VPN\s0 payload using raw \s-1IP\s0 frames (using the |
| … | |
… | |
| 176 | .IX Subsection "UDP" |
185 | .IX Subsection "UDP" |
| 177 | This is a good general choice for the transport protocol as \s-1UDP\s0 packets |
186 | This is a good general choice for the transport protocol as \s-1UDP\s0 packets |
| 178 | tunnel well through most firewalls and routers, and the overhead per |
187 | tunnel well through most firewalls and routers, and the overhead per |
| 179 | packet is moderate (minimum 58 bytes). |
188 | packet is moderate (minimum 58 bytes). |
| 180 | .PP |
189 | .PP |
| 181 | It should be used if \s-1RAW\s0 \s-1IP\s0 is not available. |
190 | It should be used if \s-1RAW IP\s0 is not available. |
| 182 | .SS "\s-1TCP\s0" |
191 | .SS "\s-1TCP\s0" |
| 183 | .IX Subsection "TCP" |
192 | .IX Subsection "TCP" |
| 184 | This protocol is a very bad choice, as it not only has high overhead (more |
193 | This protocol is a very bad choice, as it not only has high overhead (more |
| 185 | than 60 bytes), but the transport also retries on it's own, which leads |
194 | than 60 bytes), but the transport also retries on its own, which leads |
| 186 | to congestion when the link has moderate packet loss (as both the \s-1TCP\s0 |
195 | to congestion when the link has moderate packet loss (as both the \s-1TCP\s0 |
| 187 | transport and the tunneled traffic will retry, increasing congestion more |
196 | transport and the tunneled traffic will retry, increasing congestion more |
| 188 | and more). It also has high latency and is quite inefficient. |
197 | and more). It also has high latency and is quite inefficient. |
| 189 | .PP |
198 | .PP |
| 190 | It's only useful when tunneling through firewalls that block better |
199 | It's only useful when tunneling through firewalls that block better |
| … | |
… | |
| 192 | that supports the \s-1CONNECT\s0 method it can be used to tunnel through a web |
201 | that supports the \s-1CONNECT\s0 method it can be used to tunnel through a web |
| 193 | proxy. For this to work, the \f(CW\*(C`tcp\-port\*(C'\fR should be \f(CW443\fR (\f(CW\*(C`https\*(C'\fR), as |
202 | proxy. For this to work, the \f(CW\*(C`tcp\-port\*(C'\fR should be \f(CW443\fR (\f(CW\*(C`https\*(C'\fR), as |
| 194 | most proxies do not allow connections to other ports. |
203 | most proxies do not allow connections to other ports. |
| 195 | .PP |
204 | .PP |
| 196 | It is an abuse of the usage a proxy was designed for, so make sure you are |
205 | It is an abuse of the usage a proxy was designed for, so make sure you are |
| 197 | allowed to use it for \s-1GVPE\s0. |
206 | allowed to use it for \s-1GVPE.\s0 |
| 198 | .PP |
207 | .PP |
| 199 | This protocol also has server and client sides. If the \f(CW\*(C`tcp\-port\*(C'\fR is |
208 | This protocol also has server and client sides. If the \f(CW\*(C`tcp\-port\*(C'\fR is |
| 200 | set to zero, other nodes cannot connect to this node directly. If the |
209 | set to zero, other nodes cannot connect to this node directly. If the |
| 201 | \&\f(CW\*(C`tcp\-port\*(C'\fR is non-zero, the node can act both as a client as well as a |
210 | \&\f(CW\*(C`tcp\-port\*(C'\fR is non-zero, the node can act both as a client as well as a |
| 202 | server. |
211 | server. |
| … | |
… | |
| 236 | you some overview over the protocol. |
245 | you some overview over the protocol. |
| 237 | .SS "Anatomy of a \s-1VPN\s0 packet" |
246 | .SS "Anatomy of a \s-1VPN\s0 packet" |
| 238 | .IX Subsection "Anatomy of a VPN packet" |
247 | .IX Subsection "Anatomy of a VPN packet" |
| 239 | The exact layout and field lengths of a \s-1VPN\s0 packet is determined at |
248 | The exact layout and field lengths of a \s-1VPN\s0 packet is determined at |
| 240 | compile time and doesn't change. The same structure is used for all |
249 | compile time and doesn't change. The same structure is used for all |
| 241 | transport protocols, be it \s-1RAWIP\s0 or \s-1TCP\s0. |
250 | transport protocols, be it \s-1RAWIP\s0 or \s-1TCP.\s0 |
| 242 | .PP |
251 | .PP |
| 243 | .Vb 3 |
252 | .Vb 3 |
| 244 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
253 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
| 245 | \& | HMAC | TYPE | SRCDST | DATA | |
254 | \& | HMAC | TYPE | SRCDST | DATA | |
| 246 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
255 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
| 247 | .Ve |
256 | .Ve |
| 248 | .PP |
257 | .PP |
| 249 | The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth |
258 | The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth |
| 250 | request packets), in which case it is set to all zeroes. The checksum |
259 | request packets), in which case it is set to all zeroes. The \s-1MAC\s0 itself is |
| 251 | itself is calculated over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. |
260 | calculated over the \s-1TYPE, SRCDST\s0 and \s-1DATA\s0 fields in all cases. |
| 252 | .PP |
261 | .PP |
| 253 | The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet |
262 | The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet |
| 254 | (e.g. \s-1RESET\s0, \s-1COMPRESSED/UNCOMPRESSED\s0 \s-1DATA\s0, \s-1PING\s0, \s-1AUTH\s0 \s-1REQUEST/RESPONSE\s0, |
263 | (e.g. \s-1RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
| 255 | \&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.). |
264 | CONNECT REQUEST/INFO\s0 etc.). |
| 256 | .PP |
265 | .PP |
| 257 | \&\s-1SRCDST\s0 is a three byte field which contains the source and destination |
266 | \&\s-1SRCDST\s0 is a three byte field which contains the source and destination |
| 258 | node IDs (12 bits each). |
267 | node IDs (12 bits each). |
| 259 | .PP |
268 | .PP |
| 260 | The \s-1DATA\s0 portion differs between each packet type, naturally, and is the |
269 | The \s-1DATA\s0 portion differs between each packet type, naturally, and is the |
| … | |
… | |
| 273 | \&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
282 | \&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
| 274 | initialization and starts at some random 31 bit value. \s-1GVPE\s0 currently uses |
283 | initialization and starts at some random 31 bit value. \s-1GVPE\s0 currently uses |
| 275 | a sliding window of 512 packets/sequence numbers to detect reordering, |
284 | a sliding window of 512 packets/sequence numbers to detect reordering, |
| 276 | duplication and replay attacks. |
285 | duplication and replay attacks. |
| 277 | .PP |
286 | .PP |
| 278 | The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV\s0 (or, |
287 | The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV \s0(or, |
| 279 | equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO\s0, encrypted with the block cipher, |
288 | equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO,\s0 encrypted with the block cipher, |
| 280 | unless \s-1RAND\s0 size is decreased or increased over the default value). |
289 | unless \s-1RAND\s0 size is decreased or increased over the default value). |
| 281 | .PP |
290 | .PP |
| 282 | The random prefix itself is generated by using \s-1AES\s0 in \s-1CTR\s0 mode with a |
291 | The random prefix itself is generated by using \s-1AES\s0 in \s-1CTR\s0 mode with a |
| 283 | random key and starting value, which should make them unpredictable even |
292 | random key and starting value, which should make them unpredictable even |
| 284 | before encrypting them again. The sequence number additionally ensures |
293 | before encrypting them again. The sequence number additionally ensures |
| … | |
… | |
| 288 | Before nodes can exchange packets, they need to establish authenticity of |
297 | Before nodes can exchange packets, they need to establish authenticity of |
| 289 | the other side and a key. Every node has a private \s-1RSA\s0 key and the public |
298 | the other side and a key. Every node has a private \s-1RSA\s0 key and the public |
| 290 | \&\s-1RSA\s0 keys of all other nodes. |
299 | \&\s-1RSA\s0 keys of all other nodes. |
| 291 | .PP |
300 | .PP |
| 292 | When a node wants to establish a connection to another node, it sends an |
301 | When a node wants to establish a connection to another node, it sends an |
| 293 | RSA-OEAP-encrypted challenge and an \s-1ECDH\s0 key. The other node replies with |
302 | RSA-OEAP-encrypted challenge and an \s-1ECDH \s0(curve25519) key. The other node |
| 294 | it's own \s-1ECDH\s0 key and a \s-1HKDF\s0 of the challange and both \s-1ECDH\s0 keys to proof |
303 | replies with its own \s-1ECDH\s0 key and a \s-1HKDF\s0 of the challenge and both \s-1ECDH\s0 |
| 295 | it's identity. |
304 | keys to prove its identity. |
| 296 | .PP |
305 | .PP |
| 297 | The remote node enganges in exactly the same protocol. When both nodes |
306 | The remote node enganges in exactly the same protocol. When both nodes |
| 298 | have exchanged their challenge and verified the response, they calculate a |
307 | have exchanged their challenge and verified the response, they calculate a |
| 299 | cipher key and a \s-1HMAC\s0 key and start exchanging data packets. |
308 | cipher key and a \s-1HMAC\s0 key and start exchanging data packets. |
| 300 | .PP |
309 | .PP |
| … | |
… | |
| 304 | \& RSA\-OAEP (SEQNO MAC CIPHER SALT EXTRA\-AUTH) ECDH1 |
313 | \& RSA\-OAEP (SEQNO MAC CIPHER SALT EXTRA\-AUTH) ECDH1 |
| 305 | .Ve |
314 | .Ve |
| 306 | .PP |
315 | .PP |
| 307 | That is, it encrypts (with the public key of the remote node) an initial |
316 | That is, it encrypts (with the public key of the remote node) an initial |
| 308 | sequence number for data packets, key material for the \s-1HMAC\s0 key, key |
317 | sequence number for data packets, key material for the \s-1HMAC\s0 key, key |
| 309 | material for the cipher key, a salt used by the \s-1HKDF\s0 (as shown later) and |
318 | material for the cipher key, a salt used by the \s-1HKDF \s0(as shown later) and |
| 310 | some extra random bytes that are unused except for authentication. It also |
319 | some extra random bytes that are unused except for authentication. It also |
| 311 | sends the public key of a curve25519 exchange. |
320 | sends the public key of a curve25519 exchange. |
| 312 | .PP |
321 | .PP |
| 313 | The remote node decrypts the \s-1RSA\s0 data, generates it's own \s-1ECDH\s0 key (\s-1ECDH2\s0), and |
322 | The remote node decrypts the \s-1RSA\s0 data, generates its own \s-1ECDH\s0 key (\s-1ECDH2\s0), |
| 314 | replies with: |
323 | and replies with: |
| 315 | .PP |
324 | .PP |
| 316 | .Vb 1 |
325 | .Vb 1 |
| 317 | \& HKDF\-Expand (HKDF\-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2 |
326 | \& HKDF\-Expand (HKDF\-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2 |
| 318 | .Ve |
327 | .Ve |
| 319 | .PP |
328 | .PP |
| 320 | That is, it extracts from the decrypted \s-1RSA\s0 challenge, using it's \s-1ECDH\s0 |
329 | That is, it extracts from the decrypted \s-1RSA\s0 challenge, using its \s-1ECDH\s0 |
| 321 | key as salt, and then expands using the requesting node's \s-1ECDH1\s0 key. The |
330 | key as salt, and then expands using the requesting node's \s-1ECDH1\s0 key. The |
| 322 | resulting has is returned as a proof that the node could decrypt the \s-1RSA\s0 |
331 | resulting hash is returned as a proof that the node could decrypt the \s-1RSA\s0 |
| 323 | challenge data, together with the \s-1ECDH\s0 key. |
332 | challenge data, together with the \s-1ECDH\s0 key. |
| 324 | .PP |
333 | .PP |
| 325 | After both nodes have done this to each other, they calculate the shared |
334 | After both nodes have done this to each other, they calculate the shared |
| 326 | \&\s-1ECDH\s0 secrets, cipher and \s-1HMAC\s0 keys for the session (each |
335 | \&\s-1ECDH\s0 secret, cipher and \s-1HMAC\s0 keys for the session (each node generates two |
| 327 | node generates two cipher and \s-1HMAC\s0 keys, one for sending and one for |
336 | cipher and \s-1HMAC\s0 keys, one for sending and one for receiving). |
| 328 | receiving). |
|
|
| 329 | .PP |
337 | .PP |
| 330 | The \s-1HMAC\s0 key for sending is generated as follow: |
338 | The \s-1HMAC\s0 key for sending is generated as follow: |
| 331 | .PP |
339 | .PP |
| 332 | .Vb 1 |
340 | .Vb 1 |
| 333 | \& HMAC_KEY = HKDF\-Expand (HKDF\-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE) |
341 | \& HMAC_KEY = HKDF\-Expand (HKDF\-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE) |
| 334 | .Ve |
342 | .Ve |
| 335 | .PP |
343 | .PP |
| 336 | It extracts from \s-1MAC\s0 and \s-1ECDH_SECRET\s0 using the \fIremote\fR \s-1SALT\s0, then |
344 | It extracts from \s-1MAC\s0 and \s-1ECDH_SECRET\s0 using the \fIremote\fR \s-1SALT,\s0 then |
| 337 | expands using a static info string. |
345 | expands using a static info string. |
| 338 | .PP |
346 | .PP |
| 339 | The cipher key is generated in the same way, except using the \s-1CIPHER\s0 part |
347 | The cipher key is generated in the same way, except using the \s-1CIPHER\s0 part |
| 340 | of the original challenge. |
348 | of the original challenge. |
| 341 | .PP |
349 | .PP |
| 342 | The result of this process is to authenticate each node to the other |
350 | The result of this process is to authenticate each node to the other |
| 343 | node, while exchanging keys using both \s-1RSA\s0 and \s-1ECDH\s0, the latter providing |
351 | node, while exchanging keys using both \s-1RSA\s0 and \s-1ECDH,\s0 the latter providing |
| 344 | perfect forward secrecy. |
352 | perfect forward secrecy. |
| 345 | .PP |
353 | .PP |
| 346 | The protocol has been overdesigned where this was possible without |
354 | The protocol has been overdesigned where this was possible without |
| 347 | increasing implementation complexity, in an attempt to protect against |
355 | increasing implementation complexity, in an attempt to protect against |
| 348 | implementation or protocol failures. For example, if the \s-1ECDH\s0 challenge |
356 | implementation or protocol failures. For example, if the \s-1ECDH\s0 challenge |
| 349 | was found to be flawed, perfect forward secrecy would be lost, but |
357 | was found to be flawed, perfect forward secrecy would be lost, but the |
| 350 | the data would still be protected. Likewise, standard algorithms and |
358 | data would likely still be protected. Likewise, standard algorithms and |
| 351 | implementations are used where possible. |
359 | implementations are used where possible. |
| 352 | .SS "Retrying" |
360 | .SS "Retrying" |
| 353 | .IX Subsection "Retrying" |
361 | .IX Subsection "Retrying" |
| 354 | When there is no response to an auth request, the node will send auth |
362 | When there is no response to an auth request, the node will send auth |
| 355 | requests in bursts with an exponential back-off. After some time it will |
363 | requests in bursts with an exponential back-off. After some time it will |
| … | |
… | |
| 391 | .IX Item "If no such router exists, then GVPE will simply send the packet to the node with the highest priority available." |
399 | .IX Item "If no such router exists, then GVPE will simply send the packet to the node with the highest priority available." |
| 392 | .IP "Failing all that, the packet will be dropped." 4 |
400 | .IP "Failing all that, the packet will be dropped." 4 |
| 393 | .IX Item "Failing all that, the packet will be dropped." |
401 | .IX Item "Failing all that, the packet will be dropped." |
| 394 | .PD |
402 | .PD |
| 395 | .PP |
403 | .PP |
| 396 | A host can usually declare itself unreachable directly by setting it's |
404 | A host can usually declare itself unreachable directly by setting its |
| 397 | port number(s) to zero. It can declare other hosts as unreachable by using |
405 | port number(s) to zero. It can declare other hosts as unreachable by using |
| 398 | a config-file that disables all protocols for these other hosts. Another |
406 | a config-file that disables all protocols for these other hosts. Another |
| 399 | option is to disable all protocols on that host in the other config files. |
407 | option is to disable all protocols on that host in the other config files. |
| 400 | .PP |
408 | .PP |
| 401 | If two hosts cannot connect to each other because their \s-1IP\s0 address(es) |
409 | If two hosts cannot connect to each other because their \s-1IP\s0 address(es) |
| … | |
… | |
| 407 | connection to the other peer, which is usually possible even when both |
415 | connection to the other peer, which is usually possible even when both |
| 408 | hosts are behind a \s-1NAT\s0 gateway. |
416 | hosts are behind a \s-1NAT\s0 gateway. |
| 409 | .PP |
417 | .PP |
| 410 | Routing via other nodes works because the \s-1SRCDST\s0 field is not encrypted, |
418 | Routing via other nodes works because the \s-1SRCDST\s0 field is not encrypted, |
| 411 | so the router can just forward the packet to the destination host. Since |
419 | so the router can just forward the packet to the destination host. Since |
| 412 | each host uses it's own private key, the router will not be able to |
420 | each host uses its own private key, the router will not be able to |
| 413 | decrypt or encrypt packets, it will just act as a simple router and |
421 | decrypt or encrypt packets, it will just act as a simple router and |
| 414 | protocol translator. |
422 | protocol translator. |
