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.8 by root, Sun Mar 6 19:40:27 2011 UTC vs.
Revision 1.14 by root, Sat Apr 26 19:07:22 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
… …
120 +------+------+--------+------+ 120 +------+------+--------+------+
121 | HMAC | TYPE | SRCDST | DATA | 121 | HMAC | TYPE | SRCDST | DATA |
122 +------+------+--------+------+ 122 +------+------+--------+------+
123 123
124The HMAC field is present in all packets, even if not used (e.g. in auth 124The HMAC field is present in all packets, even if not used (e.g. in auth
125request packets), in which case it is set to all zeroes. The checksum 125request packets), in which case it is set to all zeroes. The MAC itself is
126itself is calculated over the TYPE, SRCDST and DATA fields in all cases. 126calculated over the TYPE, SRCDST and DATA fields in all cases.
127 127
128The TYPE field is a single byte and determines the purpose of the packet 128The 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,
130CONNECT REQUEST/INFO etc.). 130CONNECT REQUEST/INFO etc.).
131 131
… …
142 142
143RAND is a sequence of fully random bytes, used to increase the entropy of 143RAND is a sequence of fully random bytes, used to increase the entropy of
144the data for encryption purposes. 144the data for encryption purposes.
145 145
146SEQNO is a 32-bit sequence number. It is negotiated at every connection 146SEQNO is a 32-bit sequence number. It is negotiated at every connection
147initialization and starts at some random 31 bit value. VPE currently uses 147initialization and starts at some random 31 bit value. GVPE currently uses
148a sliding window of 512 packets/sequence numbers to detect reordering, 148a sliding window of 512 packets/sequence numbers to detect reordering,
149duplication and replay attacks. 149duplication and replay attacks.
150 150
151The encryption is done on RAND+SEQNO+DATA in CBC mode with zero IV (or,
152equivalently, the IV is RAND+SEQNO, encrypted with the block cipher,
153unless RAND size is decreased or increased over the default value).
154
155The random prefix itself is generated by using AES in CTR mode with a
156random key and starting value, which should make them unpredictable even
157before encrypting them again. The sequence number additionally ensures
158that the IV is unique.
159
151=head2 The authentication protocol 160=head2 The authentication/key exchange protocol
152 161
153Before nodes can exchange packets, they need to establish authenticity of 162Before nodes can exchange packets, they need to establish authenticity of
154the 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
155RSA keys of all other nodes. 164RSA keys of all other nodes.
156 165
157A host establishes a simplex connection by sending the other node an 166When a node wants to establish a connection to another node, it sends an
158RSA encrypted challenge containing a random challenge (consisting of 167RSA-OEAP-encrypted challenge and an ECDH (curve25519) key. The other node
159the encryption key to use when sending packets, more random data and 168replies with its own ECDH key and a HKDF of the challenge and both ECDH
160PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect 169keys to prove its identity.
161duplicate auth packets). The destination node will respond by replying
162with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which
163will authenticate that node. The destination node will also set the
164outgoing encryption parameters as given in the packet.
165 170
166When the source node receives a correct auth reply (by verifying the 171The remote node enganges in exactly the same protocol. When both nodes
167hash and the id, which will expire after 120 seconds), it will start to 172have exchanged their challenge and verified the response, they calculate a
168accept data packets from the destination node. 173cipher key and a HMAC key and start exchanging data packets.
169 174
170This means that a node can only initiate a simplex connection, telling the 175In detail, the challenge consist of:
171other side the key it has to use when it sends packets. The challenge
172reply is only used to set the current IP address of the other side and
173protocol parameters.
174 176
175This protocol is completely symmetric, so to be able to send packets the 177 RSA-OAEP (SEQNO MAC CIPHER SALT EXTRA-AUTH) ECDH1
176destination node must send a challenge in the exact same way as already 178
177described (so, in essence, two simplex connections are created per node 179That is, it encrypts (with the public key of the remote node) an initial
178pair). 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
182some extra random bytes that are unused except for authentication. It also
183sends the public key of a curve25519 exchange.
184
185The remote node decrypts the RSA data, generates its own ECDH key (ECDH2),
186and replies with:
187
188 HKDF-Expand (HKDF-Extract (ECDH2, RSA), ECDH1, AUTH_DIGEST_SIZE) ECDH2
189
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
192resulting hash is returned as a proof that the node could decrypt the RSA
193challenge data, together with the ECDH key.
194
195After both nodes have done this to each other, they calculate the shared
196ECDH secret, cipher and HMAC keys for the session (each node generates two
197cipher and HMAC keys, one for sending and one for receiving).
198
199The HMAC key for sending is generated as follow:
200
201 HMAC_KEY = HKDF-Expand (HKDF-Extract (REMOTE_SALT, MAC ECDH_SECRET), info, HMAC_MD_SIZE)
202
203It extracts from MAC and ECDH_SECRET using the I<remote> SALT, then
204expands using a static info string.
205
206The cipher key is generated in the same way, except using the CIPHER part
207of the original challenge.
208
209The result of this process is to authenticate each node to the other
210node, while exchanging keys using both RSA and ECDH, the latter providing
211perfect forward secrecy.
212
213The protocol has been overdesigned where this was possible without
214increasing implementation complexity, in an attempt to protect against
215implementation or protocol failures. For example, if the ECDH challenge
216was found to be flawed, perfect forward secrecy would be lost, but the
217data would likely still be protected. Likewise, standard algorithms and
218implementations are used where possible.
179 219
180=head2 Retrying 220=head2 Retrying
181 221
182When 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
183requests in bursts with an exponential back-off. After some time it will 223requests in bursts with an exponential back-off. After some time it will
… …
203will try to connect every few seconds. 243will try to connect every few seconds.
204 244
205=head2 Routing and Protocol translation 245=head2 Routing and Protocol translation
206 246
207The GVPE routing algorithm is easy: there isn't much routing to speak 247The GVPE routing algorithm is easy: there isn't much routing to speak
208of: When routing packets to another node, GVPE trues the following 248of: When routing packets to another node, GVPE tries the following
209options, in order: 249options, in order:
210 250
211=over 4 251=over 4
212 252
213=item If the two nodes should be able to reach each other directly (common 253=item If the two nodes should be able to reach each other directly (common
… …
230 270
231=item Failing all that, the packet will be dropped. 271=item Failing all that, the packet will be dropped.
232 272
233=back 273=back
234 274
235A host can usually declare itself unreachable directly by setting it's 275A host can usually declare itself unreachable directly by setting its
236port 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
237a config-file that disables all protocols for these other hosts. Another 277a config-file that disables all protocols for these other hosts. Another
238option 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.
239 279
240If 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)
… …
246connection to the other peer, which is usually possible even when both 286connection to the other peer, which is usually possible even when both
247hosts are behind a NAT gateway. 287hosts are behind a NAT gateway.
248 288
249Routing via other nodes works because the SRCDST field is not encrypted, 289Routing via other nodes works because the SRCDST field is not encrypted,
250so 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
251each 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
252decrypt 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
253protocol translator. 293protocol translator.
254 294
255 295

Diff Legend

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