… | |
… | |
8 | |
8 | |
9 | +------+------+--------+------+ |
9 | +------+------+--------+------+ |
10 | | HMAC | TYPE | SRCDST | DATA | |
10 | | HMAC | TYPE | SRCDST | DATA | |
11 | +------+------+--------+------+ |
11 | +------+------+--------+------+ |
12 | |
12 | |
13 | The HMAC field is present in all packets, even if not used (e.g. in |
13 | The HMAC field is present in all packets, even if not used (e.g. in auth |
14 | authentification packets), in which case it is set to all zeroes. The |
14 | request packets), in which case it is set to all zeroes. The checksum |
15 | checksum itself is over the TYPE, SRCDST and DATA fields in all cases. |
15 | itself is over the TYPE, SRCDST and DATA fields in all cases. |
16 | |
16 | |
17 | The TYPE field is a single byte and determines the purpose of the packet |
17 | The TYPE field is a single byte and determines the purpose of the packet |
18 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
18 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
19 | CONNECT REQUEST/INFO etc.). |
19 | CONNECT REQUEST/INFO etc.). |
20 | |
20 | |
… | |
… | |
23 | hosts, since all hosts connect to each other on startup. But if restarts |
23 | hosts, since all hosts connect to each other on startup. But if restarts |
24 | are rare or tolerable and most connections are on demand, larger networks |
24 | are rare or tolerable and most connections are on demand, larger networks |
25 | are possible. |
25 | are possible. |
26 | |
26 | |
27 | The DATA portion differs between each packet type, naturally, and is the |
27 | The DATA portion differs between each packet type, naturally, and is the |
28 | only part that can be encrypted encrypted. Data packets contain more |
28 | only part that can be encrypted. Data packets contain more fields, as |
29 | fields, as shown: |
29 | shown: |
30 | |
30 | |
31 | +------+------+--------+------+-------+------+ |
31 | +------+------+--------+------+-------+------+ |
32 | | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
32 | | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | |
33 | +------+------+--------+------+-------+------+ |
33 | +------+------+--------+------+-------+------+ |
34 | |
34 | |
35 | RAND is a sequence of fully random bytes, used to increase the entropy of the data |
35 | RAND is a sequence of fully random bytes, used to increase the entropy of |
36 | for encryption purposes. |
36 | the data for encryption purposes. |
37 | |
37 | |
38 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
38 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
39 | initialization and starts at some random value. |
39 | initialization and starts at some random 31 bit value. VPE currently uses |
|
|
40 | a sliding window of 512 packets to detect reordering, duplication and |
|
|
41 | reply attacks. |
40 | |
42 | |
41 | =head2 The authentification protocol |
43 | =head2 The authentification protocol |
42 | |
44 | |
43 | Before hosts can exchange packets, they need to establish authenticity of |
45 | Before hosts can exchange packets, they need to establish authenticity of |
44 | the other side and a key. Every host has a private RSA key and the public |
46 | the other side and a key. Every host has a private RSA key and the public |
45 | RSA keys of all other hosts. |
47 | RSA keys of all other hosts. |
46 | |
48 | |
47 | A host establishes a simplex connection by sending the other host a RSA |
49 | A host establishes a simplex connection by sending the other host a |
48 | challenge containing the random digest and encryption keys (different) |
50 | RSA encrypted challenge containing a random challenge (consisting of |
49 | to use when sending packets, plus more randomness plus some PKCS1_OAEP |
51 | the encryption key to use when sending packets, more random data and |
50 | padding plus a random 16 byte id. The destination host will respond by |
52 | PKCS1_OAEP padding) and a random 16 byte "challenge-id" (used to detect |
|
|
53 | duplicate auth packets). The destination host will respond by replying |
51 | replying with an (unencrypted) RIPEMD160 hash of the decrypted data, which |
54 | with an (unencrypted) RIPEMD160 hash of the decrypted challenge, which |
52 | will authentify that host. The destination host will also set the outgoing |
55 | will authentify that host. The destination host will also set the outgoing |
53 | encryption parameters as given in the packet. |
56 | encryption parameters as given in the packet. |
54 | |
57 | |
55 | When the source host receives a correct auth reply (by verifying the |
58 | When the source host receives a correct auth reply (by verifying the |
56 | hash and the id, which will expire after 20 seconds). it will start to |
59 | hash and the id, which will expire after 120 seconds), it will start to |
57 | accept data packets from the destination host. The protocol is completely |
60 | accept data packets from the destination host. |
58 | symmetric, so to be able to send packets the destination host must send a |
61 | |
59 | challenge in the exact same way as already described. |
62 | This means that a host can only initate a simplex connection, telling the |
|
|
63 | other side the key it has to use when it sends packets. The challenge |
|
|
64 | reply is only used to set the current IP address and protocol parameters. |
|
|
65 | |
|
|
66 | The protocol here is completely symmetric, so to be able to send packets |
|
|
67 | the destination host must send a challenge in the exact same way as |
|
|
68 | already described (so, in essence, two simplex connections are created per |
|
|
69 | host pair). |
60 | |
70 | |
61 | =head2 Retrying |
71 | =head2 Retrying |
62 | |
72 | |
63 | When there is no response to an auth request, the host will send auth |
73 | When there is no response to an auth request, the host will send auth |
64 | requests in bursts with an exponential backoff. After some time it will |
74 | requests in bursts with an exponential backoff. After some time it will |