[ViewVC] Diff of: cvs/gvpe/doc/gvpe.5.pod

Comparing gvpe/doc/gvpe.5.pod (file contents):
Revision 1.9 by pcg, Mon Sep 1 06:06:11 2008 UTC vs.
Revision 1.13 by root, Wed Nov 2 06:58:35 2016 UTC

…		…
50		50
51	=back	51	=back
52		52
53	=head2 GVPE DESIGN GOALS	53	=head2 GVPE DESIGN GOALS
54		54
55	=over 4	55	=over 4
56		56
57	=item SIMPLE DESIGN	57	=item SIMPLE DESIGN
58		58
59	Cipher, HMAC algorithms and other key parameters must be selected	59	Cipher, HMAC algorithms and other key parameters must be selected
60	at compile time - this makes it possible to only link in algorithms	60	at compile time - this makes it possible to only link in algorithms
…		…
66	only a single type of buffer and it's always of fixed length.	66	only a single type of buffer and it's always of fixed length.
67		67
68	=item EASY TO SETUP	68	=item EASY TO SETUP
69		69
70	A few lines of config (the config file is shared unmodified between all	70	A few lines of config (the config file is shared unmodified between all
71	hosts) and a single run of C<gvpectrl> to generate the keys suffices to	71	hosts) and generating an RSA key-pair on each node suffices to make it
72	make it work.	72	work.
73		73
74	=item MAC-BASED SECURITY	74	=item MAC-BASED SECURITY
75		75
76	Since every host has it's own private key, other hosts cannot spoof	76	Since every host has it's own private key, other hosts cannot spoof
77	traffic from this host. That makes it possible to filter packet by MAC	77	traffic from this host. That makes it possible to filter packet by MAC
…		…
117		117
118	./configure --enable-hmac-length=4 --enable-rand-length=0	118	./configure --enable-hmac-length=4 --enable-rand-length=0
119		119
120	Minimize the header overhead of VPN packets (the above will result in	120	Minimize the header overhead of VPN packets (the above will result in
121	only 4 bytes of overhead over the raw ethernet frame). This is a insecure	121	only 4 bytes of overhead over the raw ethernet frame). This is a insecure
122	configuration because a HMAC length of 4 makes collision attacks based on	122	configuration because a HMAC length of 4 makes collision attacks almost
123	the birthday paradox pretty easy.	123	trivial.
124		124
125	=head2 MINIMIZE CPU TIME REQUIRED	125	=head2 MINIMIZE CPU TIME REQUIRED
126		126
127	./configure --enable-cipher=bf --enable-digest=md4	127	./configure --enable-cipher=bf --enable-digest=md4
128		128
…		…
130	gvpe. MD4 has been broken and is quite insecure, though, so using another	130	gvpe. MD4 has been broken and is quite insecure, though, so using another
131	digest algorithm is recommended.	131	digest algorithm is recommended.
132		132
133	=head2 MAXIMIZE SECURITY	133	=head2 MAXIMIZE SECURITY
134		134
135	./configure --enable-hmac-length=16 --enable-rand-length=8 --enable-digest=sha1	135	./configure --enable-hmac-length=16 --enable-rand-length=12 --enable-digest=ripemd610
136		136
137	This uses a 16 byte HMAC checksum to authenticate packets (I guess 8-12	137	This uses a 16 byte HMAC checksum to authenticate packets (I guess 8-12
138	would also be pretty secure ;) and will additionally prefix each packet	138	would also be pretty secure ;) and will additionally prefix each packet
139	with 8 bytes of random data. In the long run, people should move to	139	with 12 bytes of random data.
140	SHA-256 and beyond).
141		140
142	In general, remember that AES-128 seems to be as secure but faster than	141	In general, remember that AES-128 seems to be as secure but faster than
143	AES-192 or AES-256, more randomness helps against sniffing and a longer	142	AES-192 or AES-256, more randomness helps against sniffing and a longer
144	HMAC helps against spoofing. MD4 is a fast digest, SHA1, RIPEMD160, SHA256	143	HMAC helps against spoofing. MD4 is a fast digest, SHA1, RIPEMD160, SHA256
145	are consecutively better, and Blowfish is a fast cipher (and also quite	144	are consecutively better, and Blowfish is a fast cipher (and also quite
…		…
190	By enabling routing on the gateway host that runs C<gvpe> all nodes will	189	By enabling routing on the gateway host that runs C<gvpe> all nodes will
191	be able to reach the other nodes. You can, of course, also use proxy ARP	190	be able to reach the other nodes. You can, of course, also use proxy ARP
192	or other means of pseudo-bridging, or (best) full routing - the choice is	191	or other means of pseudo-bridging, or (best) full routing - the choice is
193	yours.	192	yours.
194		193
195	=head2 STEP 2: create the RSA key pairs for all hosts	194	=head2 STEP 2: create the RSA key pair for each node
196		195
197	Run the following command to generate all key pairs for all nodes (that	196	Next you have to generate the RSA keys for the nodes. While you can set
198	might take a while):	197	up GVPE so you can generate all keys on a single host and centrally
		198	distribute all keys, it is safer to generate the key for each node on the
		199	node, so that the secret/private key does not have to be copied over the
		200	network.
199		201
		202	To do so, run the following command to generate a key pair:
		203
200	gvpectrl -c /etc/gvpe -g	204	gvpectrl -c /etc/gvpe -g nodekey
201		205
202	This command will put the public keys into C<<	206	This will create two files, F<nodekey> and F<nodekey.privkey>. The former
203	/etc/gvpe/pubkeys/I<nodename> >> and the private keys into C<<	207	should be copied to F<< /etc/gvpe/pubkey/I<nodename> >> on the host where
204	/etc/gvpe/hostkeys/I<nodename> >>.	208	your config file is (you will have to create the F<pubkey> directory
		209	first):
		210
		211	scp nodekey confighost:/etc/gvpe/pubkey/nodename
		212
		213	The private key F<nodekey.privkey> should be moved to F</etc/gvpe/hostkey>:
		214
		215	mkdir -p /etc/gvpe
		216	mv nodekey.privkey /etc/gvpe/hostkey
205		217
206	=head2 STEP 3: distribute the config files to all nodes	218	=head2 STEP 3: distribute the config files to all nodes
207		219
208	Now distribute the config files and private keys to the other nodes. This	220	Now distribute the config files and public keys to the other nodes.
209	should be done in two steps, since only the private keys meant for a node
210	should be distributed (so each node has only it's own private key).
211		221
212	The example uses rsync-over-ssh	222	The example uses rsync-over-ssh to copy the config file and all the public
		223	keys:
213		224
214	First all the config files without the hostkeys should be distributed:
215
216	rsync -avzessh /etc/gvpe first.example.net:/etc/. --exclude hostkeys	225	rsync -avzessh /etc/gvpe first.example.net:/etc/. --exclude hostkey
217	rsync -avzessh /etc/gvpe 133.55.82.9:/etc/. --exclude hostkeys	226	rsync -avzessh /etc/gvpe 133.55.82.9:/etc/. --exclude hostkey
218	rsync -avzessh /etc/gvpe third.example.net:/etc/. --exclude hostkeys	227	rsync -avzessh /etc/gvpe third.example.net:/etc/. --exclude hostkey
219		228
220	Then the hostkeys should be copied:
221
222	rsync -avzessh /etc/gvpe/hostkeys/first first.example.net:/etc/hostkey
223	rsync -avzessh /etc/gvpe/hostkeys/second 133.55.82.9:/etc/hostkey
224	rsync -avzessh /etc/gvpe/hostkeys/third third.example.net:/etc/hostkey
225
226	You should now check the configuration by issuing the command C<gvpectrl -c	229	You should now check the configuration by issuing the command C<gvpectrl
227	/etc/gvpe -s> on each node and verify it's output.	230	-c /etc/gvpe -s> on each node and verify it's output.
228		231
229	=head2 STEP 4: starting gvpe	232	=head2 STEP 4: starting gvpe
230		233
231	You should then start gvpe on each node by issuing a command like:	234	You should then start gvpe on each node by issuing a command like:
232		235
…		…
247		250
248	=head2 STEP 5: enjoy	251	=head2 STEP 5: enjoy
249		252
250	... and play around. Sending a -HUP (C<gvpectrl -kHUP>) to the daemon	253	... and play around. Sending a -HUP (C<gvpectrl -kHUP>) to the daemon
251	will make it try to connect to all other nodes again. If you run it from	254	will make it try to connect to all other nodes again. If you run it from
252	inittab, as is recommended, C<gvpectrl -k> (or simply C<killall gvpe>) will	255	inittab C<gvpectrl -k> (or simply C<killall gvpe>) will kill the daemon,
253	kill the daemon, start it again, making it read it's configuration files	256	start it again, making it read it's configuration files again.
254	again.	257
		258	To run the GVPE daemon permanently from your SysV init, you can add it to
		259	your F<inittab>, e.g.:
		260
		261	t1:2345:respawn:/bin/sh -c "exec nice -n-20 /path/to/gvpe -D node >/var/log/gvpe.log 2>&1"
		262
		263	For systems using systemd, you can use a unit file similar to this one:
		264
		265	[Unit]
		266	Description=gvpe
		267	After=network.target
		268	Before=remote-fs.target
		269
		270	[Service]
		271	ExecStart=/path/to/gvpe -D node
		272	KillMode=process
		273	Restart=always
		274
		275	[Install]
		276	WantedBy=multi-user.target
255		277
256	=head1 SEE ALSO	278	=head1 SEE ALSO
257		279
258	gvpe.osdep(5) for OS-dependent information, gvpe.conf(5), gvpectrl(8),	280	gvpe.osdep(5) for OS-dependent information, gvpe.conf(5), gvpectrl(8),
259	and for a description of the transports, protocol, and routing algorithm,	281	and for a description of the transports, protocol, and routing algorithm,

Diff Legend

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

Comparing gvpe/doc/gvpe.5.pod (file contents): Revision 1.9 by pcg, Mon Sep 1 06:06:11 2008 UTC vs. Revision 1.13 by root, Wed Nov 2 06:58:35 2016 UTC

Diff Legend

Comparing gvpe/doc/gvpe.5.pod (file contents):
Revision 1.9 by pcg, Mon Sep 1 06:06:11 2008 UTC vs.
Revision 1.13 by root, Wed Nov 2 06:58:35 2016 UTC