… | |
… | |
127 | .\} |
127 | .\} |
128 | .rm #[ #] #H #V #F C |
128 | .rm #[ #] #H #V #F C |
129 | .\" ======================================================================== |
129 | .\" ======================================================================== |
130 | .\" |
130 | .\" |
131 | .IX Title "GVPE.PROTOCOL 7" |
131 | .IX Title "GVPE.PROTOCOL 7" |
132 | .TH GVPE.PROTOCOL 7 "2004-06-11" "1.7" "GNU Virtual Private Ethernet" |
132 | .TH GVPE.PROTOCOL 7 "2005-03-15" "1.8" "GNU Virtual Private Ethernet" |
133 | .SH "The GNU-VPE Protocol" |
133 | .SH "The GNU-VPE Protocols" |
134 | .IX Header "The GNU-VPE Protocol" |
134 | .IX Header "The GNU-VPE Protocols" |
|
|
135 | .SH "Overview" |
|
|
136 | .IX Header "Overview" |
|
|
137 | \&\s-1GVPE\s0 can make use of a number of protocols. One of them is the \s-1GNU\s0 \s-1VPE\s0 |
|
|
138 | protocol which is used to authenticate tunnels and send encrypted data |
|
|
139 | packets. This protocol is described in more detail the second part of this |
|
|
140 | document. |
|
|
141 | .PP |
|
|
142 | The first part of this document describes the transport protocols which |
|
|
143 | are used by \s-1GVPE\s0 to send it's data packets over the network. |
|
|
144 | .SH "PART 1: Tansport protocols" |
|
|
145 | .IX Header "PART 1: Tansport protocols" |
|
|
146 | .Sh "\s-1RAW\s0 \s-1IP\s0" |
|
|
147 | .IX Subsection "RAW IP" |
|
|
148 | .Sh "\s-1ICMP\s0" |
|
|
149 | .IX Subsection "ICMP" |
|
|
150 | .Sh "\s-1UDP\s0" |
|
|
151 | .IX Subsection "UDP" |
|
|
152 | .Sh "\s-1TCP\s0" |
|
|
153 | .IX Subsection "TCP" |
|
|
154 | .Sh "\s-1DNS\s0" |
|
|
155 | .IX Subsection "DNS" |
|
|
156 | .SH "PART 2: The GNU VPE protocol" |
|
|
157 | .IX Header "PART 2: The GNU VPE protocol" |
|
|
158 | This section, unfortunately, is not yet finished, although the protocol |
|
|
159 | is stable (until bugs in the cryptography are found, which will likely |
|
|
160 | completely change the following description). Nevertheless, it should give |
|
|
161 | you some overview over the protocol. |
135 | .Sh "Anatomy of a \s-1VPN\s0 packet" |
162 | .Sh "Anatomy of a \s-1VPN\s0 packet" |
136 | .IX Subsection "Anatomy of a VPN packet" |
163 | .IX Subsection "Anatomy of a VPN packet" |
137 | The exact layout and field lengths of a \s-1VPN\s0 packet is determined at |
164 | The exact layout and field lengths of a \s-1VPN\s0 packet is determined at |
138 | compiletime and doesn't change. The same structure is used for all |
165 | compiletime and doesn't change. The same structure is used for all |
139 | protocols, be it rawip or tcp. |
166 | transort protocols, be it \s-1RAWIP\s0 or \s-1TCP\s0. |
140 | .PP |
167 | .PP |
141 | .Vb 3 |
168 | .Vb 3 |
142 | \& +------+------+--------+------+ |
169 | \& +------+------+--------+------+ |
143 | \& | HMAC | TYPE | SRCDST | DATA | |
170 | \& | HMAC | TYPE | SRCDST | DATA | |
144 | \& +------+------+--------+------+ |
171 | \& +------+------+--------+------+ |
145 | .Ve |
172 | .Ve |
146 | .PP |
173 | .PP |
147 | The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth |
174 | The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth |
148 | request packets), in which case it is set to all zeroes. The checksum |
175 | request packets), in which case it is set to all zeroes. The checksum |
149 | itself is over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. |
176 | itself is calculated over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. |
150 | .PP |
177 | .PP |
151 | The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet |
178 | The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet |
152 | (e.g. \s-1RESET\s0, \s-1COMPRESSED/UNCOMPRESSED\s0 \s-1DATA\s0, \s-1PING\s0, \s-1AUTH\s0 \s-1REQUEST/RESPONSE\s0, |
179 | (e.g. \s-1RESET\s0, \s-1COMPRESSED/UNCOMPRESSED\s0 \s-1DATA\s0, \s-1PING\s0, \s-1AUTH\s0 \s-1REQUEST/RESPONSE\s0, |
153 | \&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.). |
180 | \&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.). |
154 | .PP |
181 | .PP |
155 | \&\s-1SRCDST\s0 is a three byte field which contains the source and destination |
182 | \&\s-1SRCDST\s0 is a three byte field which contains the source and destination |
156 | node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
183 | node ids (12 bits each). The protocol does not yet scale well beyond 30+ |
157 | hosts, since all hosts connect to each other on startup. But if restarts |
184 | hosts, since all hosts must connect to each other once on startup. But if |
158 | are rare or tolerable and most connections are on demand, larger networks |
185 | restarts are rare or tolerable and most connections are on demand, much |
159 | are possible. |
186 | larger networks are feasible. |
160 | .PP |
187 | .PP |
161 | The \s-1DATA\s0 portion differs between each packet type, naturally, and is the |
188 | The \s-1DATA\s0 portion differs between each packet type, naturally, and is the |
162 | only part that can be encrypted. Data packets contain more fields, as |
189 | only part that can be encrypted. Data packets contain more fields, as |
163 | shown: |
190 | shown: |
164 | .PP |
191 | .PP |
… | |
… | |
171 | \&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of |
198 | \&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of |
172 | the data for encryption purposes. |
199 | the data for encryption purposes. |
173 | .PP |
200 | .PP |
174 | \&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
201 | \&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection |
175 | initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses |
202 | initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses |
176 | a sliding window of 512 packets to detect reordering, duplication and |
203 | a sliding window of 512 packets/sequence numbers to detect reordering, |
177 | reply attacks. |
204 | duplication and reply attacks. |
178 | .Sh "The authentification protocol" |
205 | .Sh "The authentification protocol" |
179 | .IX Subsection "The authentification protocol" |
206 | .IX Subsection "The authentification protocol" |
180 | Before hosts can exchange packets, they need to establish authenticity of |
207 | Before hosts can exchange packets, they need to establish authenticity of |
181 | the other side and a key. Every host has a private \s-1RSA\s0 key and the public |
208 | the other side and a key. Every host has a private \s-1RSA\s0 key and the public |
182 | \&\s-1RSA\s0 keys of all other hosts. |
209 | \&\s-1RSA\s0 keys of all other hosts. |
… | |
… | |
194 | hash and the id, which will expire after 120 seconds), it will start to |
221 | hash and the id, which will expire after 120 seconds), it will start to |
195 | accept data packets from the destination host. |
222 | accept data packets from the destination host. |
196 | .PP |
223 | .PP |
197 | This means that a host can only initate a simplex connection, telling the |
224 | This means that a host can only initate a simplex connection, telling the |
198 | other side the key it has to use when it sends packets. The challenge |
225 | other side the key it has to use when it sends packets. The challenge |
199 | reply is only used to set the current \s-1IP\s0 address and protocol parameters. |
226 | reply is only used to set the current \s-1IP\s0 address of the other side and |
|
|
227 | protocol parameters. |
200 | .PP |
228 | .PP |
201 | The protocol here is completely symmetric, so to be able to send packets |
229 | This protocol is completely symmetric, so to be able to send packets the |
202 | the destination host must send a challenge in the exact same way as |
230 | destination host must send a challenge in the exact same way as already |
203 | already described (so, in essence, two simplex connections are created per |
231 | described (so, in essence, two simplex connections are created per host |
204 | host pair). |
232 | pair). |
205 | .Sh "Retrying" |
233 | .Sh "Retrying" |
206 | .IX Subsection "Retrying" |
234 | .IX Subsection "Retrying" |
207 | When there is no response to an auth request, the host will send auth |
235 | When there is no response to an auth request, the host will send auth |
208 | requests in bursts with an exponential backoff. After some time it will |
236 | requests in bursts with an exponential backoff. After some time it will |
209 | resort to \s-1PING\s0 packets, which are very small (8 byte) and lightweight (no |
237 | resort to \s-1PING\s0 packets, which are very small (8 bytes) and lightweight |
210 | \&\s-1RSA\s0 operations). A host that receives ping requests from an unconnected |
238 | (no \s-1RSA\s0 operations required). A host that receives ping requests from an |
211 | peer will respond by trying to create a connection. |
239 | unconnected peer will respond by trying to create a connection. |
212 | .PP |
240 | .PP |
213 | In addition to the exponential backoff, there is a global rate-limit on |
241 | In addition to the exponential backoff, there is a global rate-limit on |
214 | a per-ip base. It allows long bursts but will limit total packet rate to |
242 | a per-IP base. It allows long bursts but will limit total packet rate to |
215 | something like one control packet every ten seconds, to avoid accidental |
243 | something like one control packet every ten seconds, to avoid accidental |
216 | floods due to protocol problems (like a rsa key file mismatch between two |
244 | floods due to protocol problems (like a \s-1RSA\s0 key file mismatch between two |
217 | hosts). |
245 | hosts). |
218 | .Sh "Routing and Protocol translation" |
246 | .Sh "Routing and Protocol translation" |
219 | .IX Subsection "Routing and Protocol translation" |
247 | .IX Subsection "Routing and Protocol translation" |
220 | The gvpe routing algorithm is easy: there isn't any routing. \s-1GVPE\s0 always |
248 | The gvpe routing algorithm is easy: there isn't any routing. \s-1GVPE\s0 always |
221 | tries to establish direct connections, if the protocol abilities of the |
249 | tries to establish direct connections, if the protocol abilities of the |