ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/gvpe/doc/gvpe.protocol.7.pod
(Generate patch)

Comparing gvpe/doc/gvpe.protocol.7.pod (file contents):
Revision 1.12 by root, Fri Jul 19 21:13:44 2013 UTC vs.
Revision 1.13 by root, Sat Apr 26 19:05:56 2014 UTC

… …
6protocol which is used to authenticate tunnels and send encrypted data 6protocol which is used to authenticate tunnels and send encrypted data
7packets. This protocol is described in more detail the second part of this 7packets. This protocol is described in more detail the second part of this
8document. 8document.
9 9
10The first part of this document describes the transport protocols which 10The first part of this document describes the transport protocols which
11are used by GVPE to send it's data packets over the network. 11are used by GVPE to send its data packets over the network.
12 12
13=head1 PART 1: Transport protocols 13=head1 PART 1: Transport protocols
14 14
15GVPE offers a wide range of transport protocols that can be used to 15GVPE offers a wide range of transport protocols that can be used to
16interchange data between nodes. Protocols differ in their overhead, speed, 16interchange data between nodes. Protocols differ in their overhead, speed,
… …
54It should be used if RAW IP is not available. 54It should be used if RAW IP is not available.
55 55
56=head2 TCP 56=head2 TCP
57 57
58This protocol is a very bad choice, as it not only has high overhead (more 58This protocol is a very bad choice, as it not only has high overhead (more
59than 60 bytes), but the transport also retries on it's own, which leads 59than 60 bytes), but the transport also retries on its own, which leads
60to congestion when the link has moderate packet loss (as both the TCP 60to congestion when the link has moderate packet loss (as both the TCP
61transport and the tunneled traffic will retry, increasing congestion more 61transport and the tunneled traffic will retry, increasing congestion more
62and more). It also has high latency and is quite inefficient. 62and more). It also has high latency and is quite inefficient.
63 63
64It's only useful when tunneling through firewalls that block better 64It's only useful when tunneling through firewalls that block better
… …
162Before nodes can exchange packets, they need to establish authenticity of 162Before nodes can exchange packets, they need to establish authenticity of
163the other side and a key. Every node has a private RSA key and the public 163the other side and a key. Every node has a private RSA key and the public
164RSA keys of all other nodes. 164RSA keys of all other nodes.
165 165
166When a node wants to establish a connection to another node, it sends an 166When a node wants to establish a connection to another node, it sends an
167RSA-OEAP-encrypted challenge and an ECDH key. The other node replies with 167RSA-OEAP-encrypted challenge and an ECDH (curve25519) key. The other node
168it's own ECDH key and a HKDF of the challange and both ECDH keys to proof 168replies with its own ECDH key and a HKDF of the challenge and both ECDH
169it's identity. 169keys to prove its identity.
170 170
171The remote node enganges in exactly the same protocol. When both nodes 171The remote node enganges in exactly the same protocol. When both nodes
172have exchanged their challenge and verified the response, they calculate a 172have exchanged their challenge and verified the response, they calculate a
173cipher key and a HMAC key and start exchanging data packets. 173cipher key and a HMAC key and start exchanging data packets.
174 174
… …
180sequence number for data packets, key material for the HMAC key, key 180sequence number for data packets, key material for the HMAC key, key
181material for the cipher key, a salt used by the HKDF (as shown later) and 181material for the cipher key, a salt used by the HKDF (as shown later) and
182some extra random bytes that are unused except for authentication. It also 182some extra random bytes that are unused except for authentication. It also
183sends the public key of a curve25519 exchange. 183sends the public key of a curve25519 exchange.
184 184
185The remote node decrypts the RSA data, generates it's own ECDH key (ECDH2), and 185The remote node decrypts the RSA data, generates its own ECDH key (ECDH2),
186replies with: 186and replies with:
187 187
188 HKDF-Expand (HKDF-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2 188 HKDF-Expand (HKDF-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2
189 189
190That is, it extracts from the decrypted RSA challenge, using it's ECDH 190That is, it extracts from the decrypted RSA challenge, using its ECDH
191key as salt, and then expands using the requesting node's ECDH1 key. The 191key as salt, and then expands using the requesting node's ECDH1 key. The
192resulting has is returned as a proof that the node could decrypt the RSA 192resulting hash is returned as a proof that the node could decrypt the RSA
193challenge data, together with the ECDH key. 193challenge data, together with the ECDH key.
194 194
195After both nodes have done this to each other, they calculate the shared 195After both nodes have done this to each other, they calculate the shared
196ECDH secrets, cipher and HMAC keys for the session (each 196ECDH secret, cipher and HMAC keys for the session (each node generates two
197node generates two cipher and HMAC keys, one for sending and one for 197cipher and HMAC keys, one for sending and one for receiving).
198receiving).
199 198
200The HMAC key for sending is generated as follow: 199The HMAC key for sending is generated as follow:
201 200
202 HMAC_KEY = HKDF-Expand (HKDF-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE) 201 HMAC_KEY = HKDF-Expand (HKDF-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE)
203 202
… …
212perfect forward secrecy. 211perfect forward secrecy.
213 212
214The protocol has been overdesigned where this was possible without 213The protocol has been overdesigned where this was possible without
215increasing implementation complexity, in an attempt to protect against 214increasing implementation complexity, in an attempt to protect against
216implementation or protocol failures. For example, if the ECDH challenge 215implementation or protocol failures. For example, if the ECDH challenge
217was found to be flawed, perfect forward secrecy would be lost, but 216was found to be flawed, perfect forward secrecy would be lost, but the
218the data would still be protected. Likewise, standard algorithms and 217data would likely still be protected. Likewise, standard algorithms and
219implementations are used where possible. 218implementations are used where possible.
220 219
221=head2 Retrying 220=head2 Retrying
222 221
223When there is no response to an auth request, the node will send auth 222When there is no response to an auth request, the node will send auth
… …
271 270
272=item Failing all that, the packet will be dropped. 271=item Failing all that, the packet will be dropped.
273 272
274=back 273=back
275 274
276A host can usually declare itself unreachable directly by setting it's 275A host can usually declare itself unreachable directly by setting its
277port number(s) to zero. It can declare other hosts as unreachable by using 276port number(s) to zero. It can declare other hosts as unreachable by using
278a config-file that disables all protocols for these other hosts. Another 277a config-file that disables all protocols for these other hosts. Another
279option is to disable all protocols on that host in the other config files. 278option is to disable all protocols on that host in the other config files.
280 279
281If two hosts cannot connect to each other because their IP address(es) 280If two hosts cannot connect to each other because their IP address(es)
… …
287connection to the other peer, which is usually possible even when both 286connection to the other peer, which is usually possible even when both
288hosts are behind a NAT gateway. 287hosts are behind a NAT gateway.
289 288
290Routing via other nodes works because the SRCDST field is not encrypted, 289Routing via other nodes works because the SRCDST field is not encrypted,
291so the router can just forward the packet to the destination host. Since 290so the router can just forward the packet to the destination host. Since
292each host uses it's own private key, the router will not be able to 291each host uses its own private key, the router will not be able to
293decrypt or encrypt packets, it will just act as a simple router and 292decrypt or encrypt packets, it will just act as a simple router and
294protocol translator. 293protocol translator.
295 294
296 295

Diff Legend

– Removed lines
+ Added lines
< Changed lines
> Changed lines