| 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 | GVPE offers a range of transport protocols that can be used to interchange |
|
|
16 | data between nodes. Protocols differ in their overhead, speed, |
|
|
17 | reliability, and robustness. |
|
|
18 | |
|
|
19 | The following sections describe each transport protocol in more |
|
|
20 | detail. They are sorted by overhead/efficiency, the most efficient |
|
|
21 | transprot is listed first: |
|
|
22 | |
|
|
23 | =head2 RAW IP |
|
|
24 | |
|
|
25 | This protocol is the best choice, performance-wise, as the minimum |
|
|
26 | overhead per packet is only 38 bytes. |
|
|
27 | |
|
|
28 | It works by sending the VPN payload using raw ip frames (using the |
|
|
29 | protocol set by C<ip-proto>). |
|
|
30 | |
|
|
31 | Using raw ip frames has the drawback that many firewalls block "unknown" |
|
|
32 | protocols, so this transport only works if you have full IP connectivity |
|
|
33 | between nodes. |
|
|
34 | |
|
|
35 | =head2 ICMP |
|
|
36 | |
|
|
37 | This protocol offers very low overhead (minimum 42 bytes), and can |
|
|
38 | sometimes tunnel through firewalls when other protocols cannot. |
|
|
39 | |
|
|
40 | It works by prepending a ICMP header with type C<icmp-type> and a code |
|
|
41 | of C<255>. The default C<icmp-type> is C<echo-reply>, so the resulting |
|
|
42 | packets look like echo replies, which looks rather strange to network |
|
|
43 | admins. |
|
|
44 | |
|
|
45 | This transport should only be used if other transports (i.e. raw ip) are |
|
|
46 | not available or undesirable (due to their overhead). |
|
|
47 | |
|
|
48 | =head2 UDP |
|
|
49 | |
|
|
50 | This is a good general choice for the transport protocol as UDP packets |
|
|
51 | tunnel well through most firewalls and routers, and the overhead per |
|
|
52 | packet is moderate (minimum 58 bytes). |
|
|
53 | |
|
|
54 | It should be used if RAW IP is not available. |
|
|
55 | |
|
|
56 | =head2 TCP |
|
|
57 | |
|
|
58 | This protocol is a very bad choice, as it not only has high overhead (more |
|
|
59 | than 60 bytes), but the transport also retries on it's own, which leads |
|
|
60 | to congestion when the link has moderate packet loss (as both the TCP |
|
|
61 | transport and the tunneled traffic will retry, increasing congestion more |
|
|
62 | and more). It also has high latency and is quite inefficient. |
|
|
63 | |
|
|
64 | It's only useful when tunneling through firewalls that block better |
|
|
65 | protocols. If a node doesn't have direct internet access but a HTTP proxy |
|
|
66 | that supports the CONNECT method it can be used to tunnel through a web |
|
|
67 | proxy. For this to work, the C<tcp-port> should be C<443> (C<https>), as |
|
|
68 | most proxies do not allow connections to other ports. |
|
|
69 | |
|
|
70 | It is an abuse of the usage a proxy was designed for, so make sure you are |
|
|
71 | allowed to use it for GVPE. |
|
|
72 | |
|
|
73 | This protocol also has server and client sides. If the C<tcp-port> is set |
|
|
74 | to zero, other nodes cannot connect to this node directly (and C<tcp-port> |
|
|
75 | zero cannot be used). If the C<tcp-port> is non-zero, the node can act |
|
|
76 | both as a client as well as a server. |
|
|
77 | |
|
|
78 | =head2 DNS |
|
|
79 | |
|
|
80 | B<WARNING:> Parsing and generating DNS packets is rather tricky. The code |
|
|
81 | almost certainly contains buffer overflows and other, likely exploitable, |
|
|
82 | bugs. You have been warned. |
|
|
83 | |
|
|
84 | This is the worst choice of transport protocol with respect to overhead |
|
|
85 | (overhead can be 2-3 times higher than the transferred data), and latency |
|
|
86 | (which can be many seconds). Some DNS servers might not be prepared to |
|
|
87 | handle the traffic and drop or corrupt packets. The client also has to |
|
|
88 | constantly poll the server for data, so the client will constantly create |
|
|
89 | traffic even if it doesn't need to transport packets. |
|
|
90 | |
|
|
91 | In addition, the same problems as the TCP transport also plague this |
|
|
92 | protocol. |
|
|
93 | |
|
|
94 | Most configuration needs to be done by editing C<src/vpn_dns.C> directly. |
|
|
95 | |
|
|
96 | It's only use is to tunnel through firewalls that do not allow direct |
|
|
97 | internet access. Similar to using a HTTP proxy (as the TCP transport |
|
|
98 | does), it uses a local DNS server/forwarder (given by the C<dns-forw-host> |
|
|
99 | configuration value) as a proxy to send and receive data as a client, |
|
|
100 | and a C<NS> record pointing to the GVPE server (as given by the |
|
|
101 | C<dns-hostname> directive). |
|
|
102 | |
|
|
103 | The only good side of this protocol is that it can tunnel through most |
|
|
104 | firewalls undetected, iff the local DNS server/forwarder is sane (which is |
|
|
105 | true for most routers, wlan gateways and nameservers). |
|
|
106 | |
|
|
107 | =head1 PART 2: The GNU VPE protocol |
|
|
108 | |
|
|
109 | This section, unfortunately, is not yet finished, although the protocol |
|
|
110 | is stable (until bugs in the cryptography are found, which will likely |
|
|
111 | completely change the following description). Nevertheless, it should give |
|
|
112 | you some overview over the protocol. |
| 2 | |
113 | |
| 3 | =head2 Anatomy of a VPN packet |
114 | =head2 Anatomy of a VPN packet |
| 4 | |
115 | |
| 5 | The exact layout and field lengths of a VPN packet is determined at |
116 | 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 |
117 | compiletime and doesn't change. The same structure is used for all |
| 7 | protocols, be it rawip or tcp. |
118 | transort protocols, be it RAWIP or TCP. |
| 8 | |
119 | |
| 9 | +------+------+--------+------+ |
120 | +------+------+--------+------+ |
| 10 | | HMAC | TYPE | SRCDST | DATA | |
121 | | HMAC | TYPE | SRCDST | DATA | |
| 11 | +------+------+--------+------+ |
122 | +------+------+--------+------+ |
| 12 | |
123 | |
| 13 | The HMAC field is present in all packets, even if not used (e.g. in auth |
124 | 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 |
125 | 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. |
126 | itself is calculated over the TYPE, SRCDST and DATA fields in all cases. |
| 16 | |
127 | |
| 17 | The TYPE field is a single byte and determines the purpose of the packet |
128 | 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, |
129 | (e.g. RESET, COMPRESSED/UNCOMPRESSED DATA, PING, AUTH REQUEST/RESPONSE, |
| 19 | CONNECT REQUEST/INFO etc.). |
130 | CONNECT REQUEST/INFO etc.). |
| 20 | |
131 | |
| 21 | SRCDST is a three byte field which contains the source and destination |
132 | 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+ |
133 | 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 |
134 | 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 |
135 | restarts are rare or tolerable and most connections are on demand, much |
| 25 | are possible. |
136 | larger networks are feasible. |
| 26 | |
137 | |
| 27 | The DATA portion differs between each packet type, naturally, and is the |
138 | 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 |
139 | only part that can be encrypted. Data packets contain more fields, as |
| 29 | shown: |
140 | shown: |
| 30 | |
141 | |
| … | |
… | |
| 35 | RAND is a sequence of fully random bytes, used to increase the entropy of |
146 | RAND is a sequence of fully random bytes, used to increase the entropy of |
| 36 | the data for encryption purposes. |
147 | the data for encryption purposes. |
| 37 | |
148 | |
| 38 | SEQNO is a 32-bit sequence number. It is negotiated at every connection |
149 | 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 |
150 | initialization and starts at some random 31 bit value. VPE currently uses |
| 40 | a sliding window of 512 packets to detect reordering, duplication and |
151 | a sliding window of 512 packets/sequence numbers to detect reordering, |
| 41 | reply attacks. |
152 | duplication and reply attacks. |
| 42 | |
153 | |
| 43 | =head2 The authentification protocol |
154 | =head2 The authentification protocol |
| 44 | |
155 | |
| 45 | Before hosts can exchange packets, they need to establish authenticity of |
156 | 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 |
157 | 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 |
170 | hash and the id, which will expire after 120 seconds), it will start to |
| 60 | accept data packets from the destination host. |
171 | accept data packets from the destination host. |
| 61 | |
172 | |
| 62 | This means that a host can only initate a simplex connection, telling the |
173 | 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 |
174 | 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. |
175 | reply is only used to set the current IP address of the other side and |
|
|
176 | protocol parameters. |
| 65 | |
177 | |
| 66 | The protocol here is completely symmetric, so to be able to send packets |
178 | 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 |
179 | 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 |
180 | described (so, in essence, two simplex connections are created per host |
| 69 | host pair). |
181 | pair). |
| 70 | |
182 | |
| 71 | =head2 Retrying |
183 | =head2 Retrying |
| 72 | |
184 | |
| 73 | When there is no response to an auth request, the host will send auth |
185 | 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 |
186 | 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 |
187 | resort to PING packets, which are very small (8 bytes) and lightweight |
| 76 | RSA operations). A host that receives ping requests from an unconnected |
188 | (no RSA operations required). A host that receives ping requests from an |
| 77 | peer will respond by trying to create a connection. |
189 | unconnected peer will respond by trying to create a connection. |
| 78 | |
190 | |
| 79 | In addition to the exponential backoff, there is a global rate-limit on |
191 | 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 |
192 | 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 |
193 | 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 |
194 | floods due to protocol problems (like a RSA key file mismatch between two |
| 83 | hosts). |
195 | hosts). |
| 84 | |
196 | |
| 85 | =head2 Routing and Protocol translation |
197 | =head2 Routing and Protocol translation |
| 86 | |
198 | |
| 87 | The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
199 | The gvpe routing algorithm is easy: there isn't any routing. GVPE always |
