ViewVC Help
View File | Revision Log | Show Annotations | Download File
/cvs/gvpe/doc/gvpe.protocol.7
(Generate patch)

Comparing gvpe/doc/gvpe.protocol.7 (file contents):
Revision 1.1 by pcg, Fri Jun 11 15:56:13 2004 UTC vs.
Revision 1.7 by pcg, Fri Jun 3 05:07:31 2005 UTC

1.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.14 1.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.3
2.\" 2.\"
3.\" Standard preamble: 3.\" Standard preamble:
4.\" ======================================================================== 4.\" ========================================================================
5.de Sh \" Subsection heading 5.de Sh \" Subsection heading
6.br 6.br
… …
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-04-21" "1.9" "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
138protocol which is used to authenticate tunnels and send encrypted data
139packets. This protocol is described in more detail the second part of this
140document.
141.PP
142The first part of this document describes the transport protocols which
143are used by \s-1GVPE\s0 to send it's data packets over the network.
144.SH "PART 1: Transport protocols"
145.IX Header "PART 1: Transport protocols"
146\&\s-1GVPE\s0 offers a range of transport protocols that can be used to interchange
147data between nodes. Protocols differ in their overhead, speed,
148reliability, and robustness.
149.PP
150The following sections describe each transport protocol in more
151detail. They are sorted by overhead/efficiency, the most efficient
152transport is listed first:
153.Sh "\s-1RAW\s0 \s-1IP\s0"
154.IX Subsection "RAW IP"
155This protocol is the best choice, performance\-wise, as the minimum
156overhead per packet is only 38 bytes.
157.PP
158It works by sending the \s-1VPN\s0 payload using raw ip frames (using the
159protocol set by \f(CW\*(C`ip\-proto\*(C'\fR).
160.PP
161Using raw ip frames has the drawback that many firewalls block \*(L"unknown\*(R"
162protocols, so this transport only works if you have full \s-1IP\s0 connectivity
163between nodes.
164.Sh "\s-1ICMP\s0"
165.IX Subsection "ICMP"
166This protocol offers very low overhead (minimum 42 bytes), and can
167sometimes tunnel through firewalls when other protocols cannot.
168.PP
169It works by prepending a \s-1ICMP\s0 header with type \f(CW\*(C`icmp\-type\*(C'\fR and a code
170of \f(CW255\fR. The default \f(CW\*(C`icmp\-type\*(C'\fR is \f(CW\*(C`echo\-reply\*(C'\fR, so the resulting
171packets look like echo replies, which looks rather strange to network
172admins.
173.PP
174This transport should only be used if other transports (i.e. raw ip) are
175not available or undesirable (due to their overhead).
176.Sh "\s-1UDP\s0"
177.IX Subsection "UDP"
178This is a good general choice for the transport protocol as \s-1UDP\s0 packets
179tunnel well through most firewalls and routers, and the overhead per
180packet is moderate (minimum 58 bytes).
181.PP
182It should be used if \s-1RAW\s0 \s-1IP\s0 is not available.
183.Sh "\s-1TCP\s0"
184.IX Subsection "TCP"
185This protocol is a very bad choice, as it not only has high overhead (more
186than 60 bytes), but the transport also retries on it's own, which leads
187to congestion when the link has moderate packet loss (as both the \s-1TCP\s0
188transport and the tunneled traffic will retry, increasing congestion more
189and more). It also has high latency and is quite inefficient.
190.PP
191It's only useful when tunneling through firewalls that block better
192protocols. If a node doesn't have direct internet access but a \s-1HTTP\s0 proxy
193that supports the \s-1CONNECT\s0 method it can be used to tunnel through a web
194proxy. For this to work, the \f(CW\*(C`tcp\-port\*(C'\fR should be \f(CW443\fR (\f(CW\*(C`https\*(C'\fR), as
195most proxies do not allow connections to other ports.
196.PP
197It is an abuse of the usage a proxy was designed for, so make sure you are
198allowed to use it for \s-1GVPE\s0.
199.PP
200This protocol also has server and client sides. If the \f(CW\*(C`tcp\-port\*(C'\fR is set
201to zero, other nodes cannot connect to this node directly (and \f(CW\*(C`tcp\-port\*(C'\fR
202zero cannot be used). If the \f(CW\*(C`tcp\-port\*(C'\fR is non\-zero, the node can act
203both as a client as well as a server.
204.Sh "\s-1DNS\s0"
205.IX Subsection "DNS"
206\&\fB\s-1WARNING:\s0\fR Parsing and generating \s-1DNS\s0 packets is rather tricky. The code
207almost certainly contains buffer overflows and other, likely exploitable,
208bugs. You have been warned.
209.PP
210This is the worst choice of transport protocol with respect to overhead
211(overhead can be 2\-3 times higher than the transferred data), and latency
212(which can be many seconds). Some \s-1DNS\s0 servers might not be prepared to
213handle the traffic and drop or corrupt packets. The client also has to
214constantly poll the server for data, so the client will constantly create
215traffic even if it doesn't need to transport packets.
216.PP
217In addition, the same problems as the \s-1TCP\s0 transport also plague this
218protocol.
219.PP
220Most configuration needs to be done by editing \f(CW\*(C`src/vpn_dns.C\*(C'\fR directly.
221.PP
222It's only use is to tunnel through firewalls that do not allow direct
223internet access. Similar to using a \s-1HTTP\s0 proxy (as the \s-1TCP\s0 transport
224does), it uses a local \s-1DNS\s0 server/forwarder (given by the \f(CW\*(C`dns\-forw\-host\*(C'\fR
225configuration value) as a proxy to send and receive data as a client,
226and a \f(CW\*(C`NS\*(C'\fR record pointing to the \s-1GVPE\s0 server (as given by the
227\&\f(CW\*(C`dns\-hostname\*(C'\fR directive).
228.PP
229The only good side of this protocol is that it can tunnel through most
230firewalls undetected, iff the local \s-1DNS\s0 server/forwarder is sane (which is
231true for most routers, wlan gateways and nameservers).
232.SH "PART 2: The GNU VPE protocol"
233.IX Header "PART 2: The GNU VPE protocol"
234This section, unfortunately, is not yet finished, although the protocol
235is stable (until bugs in the cryptography are found, which will likely
236completely change the following description). Nevertheless, it should give
237you some overview over the protocol.
135.Sh "Anatomy of a \s-1VPN\s0 packet" 238.Sh "Anatomy of a \s-1VPN\s0 packet"
136.IX Subsection "Anatomy of a VPN packet" 239.IX Subsection "Anatomy of a VPN packet"
137The exact layout and field lengths of a \s-1VPN\s0 packet is determined at 240The exact layout and field lengths of a \s-1VPN\s0 packet is determined at
138compiletime and doesn't change. The same structure is used for all 241compiletime and doesn't change. The same structure is used for all
139protocols, be it rawip or tcp. 242transort protocols, be it \s-1RAWIP\s0 or \s-1TCP\s0.
140.PP 243.PP
141.Vb 3 244.Vb 3
142\& +------+------+--------+------+ 245\& +------+------+--------+------+
143\& | HMAC | TYPE | SRCDST | DATA | 246\& | HMAC | TYPE | SRCDST | DATA |
144\& +------+------+--------+------+ 247\& +------+------+--------+------+
145.Ve 248.Ve
146.PP 249.PP
147The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth 250The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth
148request packets), in which case it is set to all zeroes. The checksum 251request packets), in which case it is set to all zeroes. The checksum
149itself is over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. 252itself is calculated over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases.
150.PP 253.PP
151The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet 254The \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, 255(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.). 256\&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.).
154.PP 257.PP
155\&\s-1SRCDST\s0 is a three byte field which contains the source and destination 258\&\s-1SRCDST\s0 is a three byte field which contains the source and destination
156node ids (12 bits each). The protocol does not yet scale well beyond 30+ 259node ids (12 bits each). The protocol does not yet scale well beyond 30+
157hosts, since all hosts connect to each other on startup. But if restarts 260hosts, since all hosts must connect to each other once on startup. But if
158are rare or tolerable and most connections are on demand, larger networks 261restarts are rare or tolerable and most connections are on demand, much
159are possible. 262larger networks are feasible.
160.PP 263.PP
161The \s-1DATA\s0 portion differs between each packet type, naturally, and is the 264The \s-1DATA\s0 portion differs between each packet type, naturally, and is the
162only part that can be encrypted. Data packets contain more fields, as 265only part that can be encrypted. Data packets contain more fields, as
163shown: 266shown:
164.PP 267.PP
… …
171\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of 274\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of
172the data for encryption purposes. 275the data for encryption purposes.
173.PP 276.PP
174\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection 277\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection
175initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses 278initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses
176a sliding window of 512 packets to detect reordering, duplication and 279a sliding window of 512 packets/sequence numbers to detect reordering,
177reply attacks. 280duplication and reply attacks.
178.Sh "The authentification protocol" 281.Sh "The authentification protocol"
179.IX Subsection "The authentification protocol" 282.IX Subsection "The authentification protocol"
180Before hosts can exchange packets, they need to establish authenticity of 283Before hosts can exchange packets, they need to establish authenticity of
181the other side and a key. Every host has a private \s-1RSA\s0 key and the public 284the 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. 285\&\s-1RSA\s0 keys of all other hosts.
… …
194hash and the id, which will expire after 120 seconds), it will start to 297hash and the id, which will expire after 120 seconds), it will start to
195accept data packets from the destination host. 298accept data packets from the destination host.
196.PP 299.PP
197This means that a host can only initate a simplex connection, telling the 300This means that a host can only initate a simplex connection, telling the
198other side the key it has to use when it sends packets. The challenge 301other side the key it has to use when it sends packets. The challenge
199reply is only used to set the current \s-1IP\s0 address and protocol parameters. 302reply is only used to set the current \s-1IP\s0 address of the other side and
303protocol parameters.
200.PP 304.PP
201The protocol here is completely symmetric, so to be able to send packets 305This protocol is completely symmetric, so to be able to send packets the
202the destination host must send a challenge in the exact same way as 306destination host must send a challenge in the exact same way as already
203already described (so, in essence, two simplex connections are created per 307described (so, in essence, two simplex connections are created per host
204host pair). 308pair).
205.Sh "Retrying" 309.Sh "Retrying"
206.IX Subsection "Retrying" 310.IX Subsection "Retrying"
207When there is no response to an auth request, the host will send auth 311When there is no response to an auth request, the host will send auth
208requests in bursts with an exponential backoff. After some time it will 312requests in bursts with an exponential backoff. After some time it will
209resort to \s-1PING\s0 packets, which are very small (8 byte) and lightweight (no 313resort 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 314(no \s-1RSA\s0 operations required). A host that receives ping requests from an
211peer will respond by trying to create a connection. 315unconnected peer will respond by trying to create a connection.
212.PP 316.PP
213In addition to the exponential backoff, there is a global rate-limit on 317In addition to the exponential backoff, there is a global rate-limit on
214a per-ip base. It allows long bursts but will limit total packet rate to 318a per-IP base. It allows long bursts but will limit total packet rate to
215something like one control packet every ten seconds, to avoid accidental 319something like one control packet every ten seconds, to avoid accidental
216floods due to protocol problems (like a rsa key file mismatch between two 320floods due to protocol problems (like a \s-1RSA\s0 key file mismatch between two
217hosts). 321hosts).
218.Sh "Routing and Protocol translation" 322.Sh "Routing and Protocol translation"
219.IX Subsection "Routing and Protocol translation" 323.IX Subsection "Routing and Protocol translation"
220The gvpe routing algorithm is easy: there isn't any routing. \s-1GVPE\s0 always 324The gvpe routing algorithm is easy: there isn't any routing. \s-1GVPE\s0 always
221tries to establish direct connections, if the protocol abilities of the 325tries to establish direct connections, if the protocol abilities of the

Diff Legend

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