1 | =head1 The GNU-VPE Protocol |
1 | =head1 The GNU-VPE Protocols |
|
|
2 | |
|
|
3 | =head1 Overview |
|
|
4 | |
|
|
5 | GVPE can make use of a number of protocols. One of them is the GNU VPE |
|
|
6 | protocol which is used to authenticate tunnels and send encrypted data |
|
|
7 | packets. This protocol is described in more detail the second part of this |
|
|
8 | document. |
|
|
9 | |
|
|
10 | The first part of this document describes the transport protocols which |
|
|
11 | are used by GVPE to send it's data packets over the network. |
|
|
12 | |
|
|
13 | =head1 PART 1: Tansport protocols |
|
|
14 | |
|
|
15 | =head2 RAW IP |
|
|
16 | |
|
|
17 | =head2 ICMP |
|
|
18 | |
|
|
19 | =head2 UDP |
|
|
20 | |
|
|
21 | =head2 TCP |
|
|
22 | |
|
|
23 | =head2 DNS |
|
|
24 | |
|
|
25 | =head1 PART 2: The GNU VPE protocol |
|
|
26 | |
|
|
27 | This section, unfortunately, is not yet finished, although the protocol |
|
|
28 | is stable (until bugs in the cryptography are found, which will likely |
|
|
29 | completely change the following description). Nevertheless, it should give |
|
|
30 | you some overview over the protocol. |
2 | |
31 | |
3 | =head2 Anatomy of a VPN packet |
32 | =head2 Anatomy of a VPN packet |
4 | |
33 | |
5 | The exact layout and field lengths of a VPN packet is determined at |
34 | The exact layout and field lengths of a VPN packet is determined at |
6 | compiletime and doesn't change. The same structure is used for all |
35 | compiletime and doesn't change. The same structure is used for all |
7 | protocols, be it rawip or tcp. |
36 | transort protocols, be it RAWIP or TCP. |
8 | |
37 | |
9 | +------+------+--------+------+ |
38 | +------+------+--------+------+ |
10 | | HMAC | TYPE | SRCDST | DATA | |
39 | | HMAC | TYPE | SRCDST | DATA | |
11 | +------+------+--------+------+ |
40 | +------+------+--------+------+ |
12 | |
41 | |
13 | The HMAC field is present in all packets, even if not used (e.g. in auth |
42 | The HMAC field is present in all packets, even if not used (e.g. in auth |
14 | request packets), in which case it is set to all zeroes. The checksum |
43 | request packets), in which case it is set to all zeroes. The checksum |
15 | itself is over the TYPE, SRCDST and DATA fields in all cases. |
44 | itself is calculated over the TYPE, SRCDST and DATA fields in all cases. |
16 | |
45 | |
17 | The TYPE field is a single byte and determines the purpose of the packet |
46 | 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, |
47 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
19 | CONNECT REQUEST/INFO etc.). |
48 | CONNECT REQUEST/INFO etc.). |
20 | |
49 | |
21 | SRCDST is a three byte field which contains the source and destination |
50 | SRCDST is a three byte field which contains the source and destination |
22 | node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
51 | node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
23 | hosts, since all hosts connect to each other on startup. But if restarts |
52 | hosts, since all hosts must connect to each other once on startup. But if |
24 | are rare or tolerable and most connections are on demand, larger networks |
53 | restarts are rare or tolerable and most connections are on demand, much |
25 | are possible. |
54 | larger networks are feasible. |
26 | |
55 | |
27 | The DATA portion differs between each packet type, naturally, and is the |
56 | The DATA portion differs between each packet type, naturally, and is the |
28 | only part that can be encrypted. Data packets contain more fields, as |
57 | only part that can be encrypted. Data packets contain more fields, as |
29 | shown: |
58 | shown: |
30 | |
59 | |
… | |
… | |
35 | RAND is a sequence of fully random bytes, used to increase the entropy of |
64 | RAND is a sequence of fully random bytes, used to increase the entropy of |
36 | the data for encryption purposes. |
65 | the data for encryption purposes. |
37 | |
66 | |
38 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
67 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
39 | initialization and starts at some random 31 bit value. VPE currently uses |
68 | initialization and starts at some random 31 bit value. VPE currently uses |
40 | a sliding window of 512 packets to detect reordering, duplication and |
69 | a sliding window of 512 packets/sequence numbers to detect reordering, |
41 | reply attacks. |
70 | duplication and reply attacks. |
42 | |
71 | |
43 | =head2 The authentification protocol |
72 | =head2 The authentification protocol |
44 | |
73 | |
45 | Before hosts can exchange packets, they need to establish authenticity of |
74 | Before hosts can exchange packets, they need to establish authenticity of |
46 | the other side and a key. Every host has a private RSA key and the public |
75 | the other side and a key. Every host has a private RSA key and the public |
… | |
… | |
59 | hash and the id, which will expire after 120 seconds), it will start to |
88 | hash and the id, which will expire after 120 seconds), it will start to |
60 | accept data packets from the destination host. |
89 | accept data packets from the destination host. |
61 | |
90 | |
62 | This means that a host can only initate a simplex connection, telling the |
91 | 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 |
92 | 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. |
93 | reply is only used to set the current IP address of the other side and |
|
|
94 | protocol parameters. |
65 | |
95 | |
66 | The protocol here is completely symmetric, so to be able to send packets |
96 | This protocol is completely symmetric, so to be able to send packets the |
67 | the destination host must send a challenge in the exact same way as |
97 | destination host must send a challenge in the exact same way as already |
68 | already described (so, in essence, two simplex connections are created per |
98 | described (so, in essence, two simplex connections are created per host |
69 | host pair). |
99 | pair). |
70 | |
100 | |
71 | =head2 Retrying |
101 | =head2 Retrying |
72 | |
102 | |
73 | When there is no response to an auth request, the host will send auth |
103 | When there is no response to an auth request, the host will send auth |
74 | requests in bursts with an exponential backoff. After some time it will |
104 | requests in bursts with an exponential backoff. After some time it will |
75 | resort to PING packets, which are very small (8 byte) and lightweight (no |
105 | resort to PING packets, which are very small (8 bytes) and lightweight |
76 | RSA operations). A host that receives ping requests from an unconnected |
106 | (no RSA operations required). A host that receives ping requests from an |
77 | peer will respond by trying to create a connection. |
107 | unconnected peer will respond by trying to create a connection. |
78 | |
108 | |
79 | In addition to the exponential backoff, there is a global rate-limit on |
109 | In addition to the exponential backoff, there is a global rate-limit on |
80 | a per-ip base. It allows long bursts but will limit total packet rate to |
110 | a per-IP base. It allows long bursts but will limit total packet rate to |
81 | something like one control packet every ten seconds, to avoid accidental |
111 | something like one control packet every ten seconds, to avoid accidental |
82 | floods due to protocol problems (like a rsa key file mismatch between two |
112 | floods due to protocol problems (like a RSA key file mismatch between two |
83 | hosts). |
113 | hosts). |
84 | |
114 | |
85 | =head2 Routing and Protocol translation |
115 | =head2 Routing and Protocol translation |
86 | |
116 | |
87 | The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
117 | The gvpe routing algorithm is easy: there isn't any routing. GVPE always |