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

Comparing gvpe/doc/vpe.protocol.7 (file contents):
Revision 1.1 by pcg, Wed Oct 15 01:02:27 2003 UTC vs.
Revision 1.2 by pcg, Wed Oct 15 06:06:41 2003 UTC

1.\" Automatically generated by Pod::Man v1.37, Pod::Parser v1.13 1.\" Automatically generated by Pod::Man v1.34, Pod::Parser v1.13
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 "VPE.PROTOCOL 7" 131.IX Title "VPE.PROTOCOL 7"
132.TH VPE.PROTOCOL 7 "2003-04-15" "0.9" "Virtual Private Ethernet" 132.TH VPE.PROTOCOL 7 "2003-10-14" "1.2" "Virtual Private Ethernet"
133.SH "The VPE Protocol" 133.SH "The VPE Protocol"
134.IX Header "The VPE Protocol" 134.IX Header "The VPE Protocol"
135.Sh "Anatomy of a \s-1VPN\s0 packet" 135.Sh "Anatomy of a \s-1VPN\s0 packet"
136.IX Subsection "Anatomy of a VPN packet" 136.IX Subsection "Anatomy of a VPN packet"
137The exact layout and field lengths of a \s-1VPN\s0 packet is determined at 137The exact layout and field lengths of a \s-1VPN\s0 packet is determined at
… …
142\& +------+------+--------+------+ 142\& +------+------+--------+------+
143\& | HMAC | TYPE | SRCDST | DATA | 143\& | HMAC | TYPE | SRCDST | DATA |
144\& +------+------+--------+------+ 144\& +------+------+--------+------+
145.Ve 145.Ve
146.PP 146.PP
147The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in 147The \s-1HMAC\s0 field is present in all packets, even if not used (e.g. in auth
148authentification packets), in which case it is set to all zeroes. The 148request packets), in which case it is set to all zeroes. The checksum
149checksum itself is over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases. 149itself is over the \s-1TYPE\s0, \s-1SRCDST\s0 and \s-1DATA\s0 fields in all cases.
150.PP 150.PP
151The \s-1TYPE\s0 field is a single byte and determines the purpose of the packet 151The \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, 152(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.). 153\&\s-1CONNECT\s0 \s-1REQUEST/INFO\s0 etc.).
154.PP 154.PP
… …
157hosts, since all hosts connect to each other on startup. But if restarts 157hosts, since all hosts connect to each other on startup. But if restarts
158are rare or tolerable and most connections are on demand, larger networks 158are rare or tolerable and most connections are on demand, larger networks
159are possible. 159are possible.
160.PP 160.PP
161The \s-1DATA\s0 portion differs between each packet type, naturally, and is the 161The \s-1DATA\s0 portion differs between each packet type, naturally, and is the
162only part that can be encrypted encrypted. Data packets contain more 162only part that can be encrypted. Data packets contain more fields, as
163fields, as shown: 163shown:
164.PP 164.PP
165.Vb 3 165.Vb 3
166\& +------+------+--------+------+-------+------+ 166\& +------+------+--------+------+-------+------+
167\& | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA | 167\& | HMAC | TYPE | SRCDST | RAND | SEQNO | DATA |
168\& +------+------+--------+------+-------+------+ 168\& +------+------+--------+------+-------+------+
169.Ve 169.Ve
170.PP 170.PP
171\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of the data 171\&\s-1RAND\s0 is a sequence of fully random bytes, used to increase the entropy of
172for encryption purposes. 172the data for encryption purposes.
173.PP 173.PP
174\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection 174\&\s-1SEQNO\s0 is a 32\-bit sequence number. It is negotiated at every connection
175initialization and starts at some random value. 175initialization and starts at some random 31 bit value. \s-1VPE\s0 currently uses
176a sliding window of 512 packets to detect reordering, duplication and
177reply attacks.
176.Sh "The authentification protocol" 178.Sh "The authentification protocol"
177.IX Subsection "The authentification protocol" 179.IX Subsection "The authentification protocol"
178Before hosts can exchange packets, they need to establish authenticity of 180Before hosts can exchange packets, they need to establish authenticity of
179the other side and a key. Every host has a private \s-1RSA\s0 key and the public 181the other side and a key. Every host has a private \s-1RSA\s0 key and the public
180\&\s-1RSA\s0 keys of all other hosts. 182\&\s-1RSA\s0 keys of all other hosts.
181.PP 183.PP
182A host establishes a simplex connection by sending the other host a \s-1RSA\s0 184A host establishes a simplex connection by sending the other host a
183challenge containing the random digest and encryption keys (different) 185\&\s-1RSA\s0 encrypted challenge containing a random challenge (consisting of
184to use when sending packets, plus more randomness plus some \s-1PKCS1_OAEP\s0 186the encryption key to use when sending packets, more random data and
185padding plus a random 16 byte id. The destination host will respond by 187\&\s-1PKCS1_OAEP\s0 padding) and a random 16 byte \*(L"challenge\-id\*(R" (used to detect
188duplicate auth packets). The destination host will respond by replying
186replying with an (unencrypted) \s-1RIPEMD160\s0 hash of the decrypted data, which 189with an (unencrypted) \s-1RIPEMD160\s0 hash of the decrypted challenge, which
187will authentify that host. The destination host will also set the outgoing 190will authentify that host. The destination host will also set the outgoing
188encryption parameters as given in the packet. 191encryption parameters as given in the packet.
189.PP 192.PP
190When the source host receives a correct auth reply (by verifying the 193When the source host receives a correct auth reply (by verifying the
191hash and the id, which will expire after 20 seconds). it will start to 194hash and the id, which will expire after 120 seconds), it will start to
192accept data packets from the destination host. The protocol is completely 195accept data packets from the destination host.
193symmetric, so to be able to send packets the destination host must send a 196.PP
194challenge in the exact same way as already described. 197This 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
199reply is only used to set the current \s-1IP\s0 address and protocol parameters.
200.PP
201The protocol here is completely symmetric, so to be able to send packets
202the destination host must send a challenge in the exact same way as
203already described (so, in essence, two simplex connections are created per
204host pair).
195.Sh "Retrying" 205.Sh "Retrying"
196.IX Subsection "Retrying" 206.IX Subsection "Retrying"
197When there is no response to an auth request, the host will send auth 207When there is no response to an auth request, the host will send auth
198requests in bursts with an exponential backoff. After some time it will 208requests in bursts with an exponential backoff. After some time it will
199resort to \s-1PING\s0 packets, which are very small (8 byte) and lightweight (no 209resort to \s-1PING\s0 packets, which are very small (8 byte) and lightweight (no

Diff Legend

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