1 | .\" Automatically generated by Pod::Man 2.25 (Pod::Simple 3.20) |
1 | .\" Automatically generated by Pod::Man 2.28 (Pod::Simple 3.30) |
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-12" "2.24" "GNU Virtual Private Ethernet" |
136 | .TH GVPE.PROTOCOL 7 "2015-10-31" "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 |
261 | only part that can be encrypted. Data packets contain more fields, as |
270 | only part that can be encrypted. Data packets contain more fields, as |
262 | shown: |
271 | shown: |
263 | .PP |
272 | .PP |
264 | .Vb 3 |
273 | .Vb 3 |
265 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
274 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
266 | \& | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
275 | \& | HMAC | TYPE | SRCDST | SEQNO | DATA | |
267 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
276 | \& +\-\-\-\-\-\-+\-\-\-\-\-\-+\-\-\-\-\-\-\-\-+\-\-\-\-\-\-\-+\-\-\-\-\-\-+ |
268 | .Ve |
277 | .Ve |
269 | .PP |
278 | .PP |
270 | \&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of |
|
|
271 | the data for encryption purposes. |
|
|
272 | .PP |
|
|
273 | \&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
279 | \&\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-1VPE\s0 currently uses |
280 | 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, |
281 | a sliding window of 512 packets/sequence numbers to detect reordering, |
276 | duplication and replay attacks. |
282 | duplication and replay attacks. |
277 | .PP |
283 | .PP |
278 | The encryption is done on \s-1RAND+SEQNO+DATA\s0 in \s-1CBC\s0 mode with zero \s-1IV\s0 (or, |
284 | The encryption is done on \s-1SEQNO+DATA\s0 in \s-1CTR\s0 mode with \s-1IV\s0 generated from |
279 | equivalently, the \s-1IV\s0 is \s-1RAND+SEQNO\s0, encrypted with the block cipher, |
285 | the seqno (for \s-1AES:\s0 seqno || seqno || seqno || (u32)0), which ensures |
280 | unless \s-1RAND\s0 size is decreased or increased over the default value). |
286 | uniqueness for a given key. |
281 | .SS "The authentication protocol" |
287 | .SS "The authentication/key exchange protocol" |
282 | .IX Subsection "The authentication protocol" |
288 | .IX Subsection "The authentication/key exchange protocol" |
283 | Before nodes can exchange packets, they need to establish authenticity of |
289 | Before nodes can exchange packets, they need to establish authenticity of |
284 | the other side and a key. Every node has a private \s-1RSA\s0 key and the public |
290 | the other side and a key. Every node has a private \s-1RSA\s0 key and the public |
285 | \&\s-1RSA\s0 keys of all other nodes. |
291 | \&\s-1RSA\s0 keys of all other nodes. |
286 | .PP |
292 | .PP |
287 | A host establishes a simplex connection by sending the other node an \s-1RSA\s0 |
293 | When a node wants to establish a connection to another node, it sends an |
288 | encrypted challenge containing a random challenge (consisting of the |
294 | RSA-OEAP-encrypted challenge and an \s-1ECDH \s0(curve25519) key. The other node |
289 | encryption and authentication keys to use when sending packets, more |
295 | replies with its own \s-1ECDH\s0 key and a \s-1HKDF\s0 of the challenge and both \s-1ECDH\s0 |
290 | random data and \s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge-id\*(R" |
296 | keys to prove its identity. |
291 | (used to detect duplicate auth packets). The destination node will respond |
|
|
292 | by replying with an (unencrypted) hash of the decrypted challenge, which |
|
|
293 | will authenticate that node. The destination node will also set the |
|
|
294 | outgoing encryption parameters as given in the packet. |
|
|
295 | .PP |
297 | .PP |
296 | When the source node receives a correct auth reply (by verifying the |
298 | The remote node enganges in exactly the same protocol. When both nodes |
297 | hash and the id, which will expire after 120 seconds), it will start to |
299 | have exchanged their challenge and verified the response, they calculate a |
298 | accept data packets from the destination node. |
300 | cipher key and a \s-1HMAC\s0 key and start exchanging data packets. |
299 | .PP |
301 | .PP |
300 | This means that a node can only initiate a simplex connection, telling the |
302 | In detail, the challenge consist of: |
301 | other side the key it has to use when it sends packets. The challenge |
|
|
302 | reply is only used to set the current \s-1IP\s0 address of the other side and |
|
|
303 | protocol parameters. |
|
|
304 | .PP |
303 | .PP |
305 | This protocol is completely symmetric, so to be able to send packets the |
304 | .Vb 1 |
306 | destination node must send a challenge in the exact same way as already |
305 | \& RSA\-OAEP (SEQNO MAC CIPHER SALT EXTRA\-AUTH) ECDH1 |
307 | described (so, in essence, two simplex connections are created per node |
306 | .Ve |
308 | pair). |
307 | .PP |
|
|
308 | That is, it encrypts (with the public key of the remote node) an initial |
|
|
309 | sequence number for data packets, key material for the \s-1HMAC\s0 key, key |
|
|
310 | material for the cipher key, a salt used by the \s-1HKDF \s0(as shown later) and |
|
|
311 | some extra random bytes that are unused except for authentication. It also |
|
|
312 | sends the public key of a curve25519 exchange. |
|
|
313 | .PP |
|
|
314 | The remote node decrypts the \s-1RSA\s0 data, generates its own \s-1ECDH\s0 key (\s-1ECDH2\s0), |
|
|
315 | and replies with: |
|
|
316 | .PP |
|
|
317 | .Vb 1 |
|
|
318 | \& HKDF\-Expand (HKDF\-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2 |
|
|
319 | .Ve |
|
|
320 | .PP |
|
|
321 | That is, it extracts from the decrypted \s-1RSA\s0 challenge, using its \s-1ECDH\s0 |
|
|
322 | key as salt, and then expands using the requesting node's \s-1ECDH1\s0 key. The |
|
|
323 | resulting hash is returned as a proof that the node could decrypt the \s-1RSA\s0 |
|
|
324 | challenge data, together with the \s-1ECDH\s0 key. |
|
|
325 | .PP |
|
|
326 | After both nodes have done this to each other, they calculate the shared |
|
|
327 | \&\s-1ECDH\s0 secret, cipher and \s-1HMAC\s0 keys for the session (each node generates two |
|
|
328 | cipher and \s-1HMAC\s0 keys, one for sending and one for receiving). |
|
|
329 | .PP |
|
|
330 | The \s-1HMAC\s0 key for sending is generated as follow: |
|
|
331 | .PP |
|
|
332 | .Vb 1 |
|
|
333 | \& HMAC_KEY = HKDF\-Expand (HKDF\-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE) |
|
|
334 | .Ve |
|
|
335 | .PP |
|
|
336 | 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. |
|
|
338 | .PP |
|
|
339 | The cipher key is generated in the same way, except using the \s-1CIPHER\s0 part |
|
|
340 | of the original challenge. |
|
|
341 | .PP |
|
|
342 | 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 |
|
|
344 | perfect forward secrecy. |
|
|
345 | .PP |
|
|
346 | The protocol has been overdesigned where this was possible without |
|
|
347 | increasing implementation complexity, in an attempt to protect against |
|
|
348 | 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 the |
|
|
350 | data would likely still be protected. Likewise, standard algorithms and |
|
|
351 | implementations are used where possible. |
309 | .SS "Retrying" |
352 | .SS "Retrying" |
310 | .IX Subsection "Retrying" |
353 | .IX Subsection "Retrying" |
311 | When there is no response to an auth request, the node will send auth |
354 | When there is no response to an auth request, the node will send auth |
312 | requests in bursts with an exponential back-off. After some time it will |
355 | requests in bursts with an exponential back-off. After some time it will |
313 | resort to \s-1PING\s0 packets, which are very small (8 bytes + protocol header) |
356 | resort to \s-1PING\s0 packets, which are very small (8 bytes + protocol header) |
… | |
… | |
348 | .IX Item "If no such router exists, then GVPE will simply send the packet to the node with the highest priority available." |
391 | .IX Item "If no such router exists, then GVPE will simply send the packet to the node with the highest priority available." |
349 | .IP "Failing all that, the packet will be dropped." 4 |
392 | .IP "Failing all that, the packet will be dropped." 4 |
350 | .IX Item "Failing all that, the packet will be dropped." |
393 | .IX Item "Failing all that, the packet will be dropped." |
351 | .PD |
394 | .PD |
352 | .PP |
395 | .PP |
353 | A host can usually declare itself unreachable directly by setting it's |
396 | A host can usually declare itself unreachable directly by setting its |
354 | port number(s) to zero. It can declare other hosts as unreachable by using |
397 | port number(s) to zero. It can declare other hosts as unreachable by using |
355 | a config-file that disables all protocols for these other hosts. Another |
398 | a config-file that disables all protocols for these other hosts. Another |
356 | option is to disable all protocols on that host in the other config files. |
399 | option is to disable all protocols on that host in the other config files. |
357 | .PP |
400 | .PP |
358 | If two hosts cannot connect to each other because their \s-1IP\s0 address(es) |
401 | If two hosts cannot connect to each other because their \s-1IP\s0 address(es) |
… | |
… | |
364 | connection to the other peer, which is usually possible even when both |
407 | connection to the other peer, which is usually possible even when both |
365 | hosts are behind a \s-1NAT\s0 gateway. |
408 | hosts are behind a \s-1NAT\s0 gateway. |
366 | .PP |
409 | .PP |
367 | Routing via other nodes works because the \s-1SRCDST\s0 field is not encrypted, |
410 | Routing via other nodes works because the \s-1SRCDST\s0 field is not encrypted, |
368 | so the router can just forward the packet to the destination host. Since |
411 | so the router can just forward the packet to the destination host. Since |
369 | each host uses it's own private key, the router will not be able to |
412 | each host uses its own private key, the router will not be able to |
370 | decrypt or encrypt packets, it will just act as a simple router and |
413 | decrypt or encrypt packets, it will just act as a simple router and |
371 | protocol translator. |
414 | protocol translator. |