From owner-freebsd-doc Sun Jul 15 23: 0:14 2001 Delivered-To: freebsd-doc@freebsd.org Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id C013A37B401 for ; Sun, 15 Jul 2001 23:00:07 -0700 (PDT) (envelope-from gnats@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.11.4/8.11.4) id f6G607o19744; Sun, 15 Jul 2001 23:00:07 -0700 (PDT) (envelope-from gnats) Date: Sun, 15 Jul 2001 23:00:07 -0700 (PDT) Message-Id: <200107160600.f6G607o19744@freefall.freebsd.org> To: freebsd-doc@freebsd.org Cc: From: Alex Kapranoff Subject: Re: docs/28916: DocBook conversion of doc/articles/ipsec-must Reply-To: Alex Kapranoff Sender: owner-freebsd-doc@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org The following reply was made to PR docs/28916; it has been noted by GNATS. From: Alex Kapranoff To: Dima Dorfman Cc: FreeBSD-gnats-submit@FreeBSD.ORG, honig@sprynet.com Subject: Re: docs/28916: DocBook conversion of doc/articles/ipsec-must Date: Mon, 16 Jul 2001 08:39:22 +0400 * Dima Dorfman [July 13 2001, 18:51]: > Alex Kapranoff writes: > > >Description: > > I added some content (mostly removing obsolete info and > > providing additional links) along with converting the text to > > DocBook. A review would be appreciated. > > Could you please > > (1) separate the content changes from the DocBook conversion, and > (2) send this in the form of a diff against the old version. > > (1) because content changes must be separate from markup changes (if > not for `cvs diff` convenience, for translators), and (2) because > sharballs for files already in the repository aren't very convenient > to work with. Yes, my fault. Thanks for the reminder. Below is the content diff for translators (there's a ja_JA.eucJP translation). And markup diff in this case is neither human-comprehendable nor space-saving. The main reason for me not to submit changes in the diff form was that it won't help anybody. You can easily generate it with `cvs diff', however, and see that 95% of lines are changed and therefore included in the diff (twice). And why do you say that sharballs are less convenient to work with? Seems that it's true only if the diff is readable. --- /usr/doc/en_US.ISO8859-1/articles/ipsec-must/article.sgml Wed Jun 13 18:16:55 2001 +++ article.html Mon Jul 16 08:22:26 2001 @@ -2,12 +2,12 @@ - Independent Verification of IPSec Functionality in FreeBSD + Independent Verification of IPsec Functionality in FreeBSD -

Independent Verification of IPsec Functionality Under FreeBSD 3.0

Independent Verification of IPsec Functionality in FreeBSD

You installed IPsec and it seems to be working. How do you know? I describe a method for experimentally verifying @@ -27,12 +27,12 @@

-
Encrypted data is uniformly distributed, ie, has maximal entropy - per symbol.
+
encrypted data is uniformly distributed, i.e., has maximal entropy + per symbol;

-
Raw, uncompressed data is typically redundant, i.e., has +
raw, uncompressed data is typically redundant, i.e., has sub-maximal entropy.

@@ -40,16 +40,17 @@
Suppose you could measure the entropy of the data to- and from- your network interface. Then you could see the difference between unencrypted data and encrypted data. This would be true even if some of the data - in "encrypted mode" was not encrypted ---as the outermost IP header must + in "encrypted mode" was not encrypted---as the outermost IP header must be, if the packet is to be routable.

MUST

Ueli Maurer's "Universal Statistical Test for Random Bit Generators" - ("MUST") quickly measures the entropy of a sample. It uses a - compression-like algorithm. The code is given below for a variant which measures successive - (~quarter megabyte) chunks of a file.
+ (MUST) + quickly measures the entropy of a sample. It uses a + compression-like algorithm. The code is given below for a variant which measures successive + (~quarter megabyte) chunks of a file.

Tcpdump
@@ -103,15 +104,15 @@
This experiment shows that IPsec does seem to be distributing the payload data uniformly, as encryption should. However, the - experiment described here can not detect many possible flaws in a + experiment described here can not detect many possible flaws in a system (none of which do I have any evidence for). These include poor key generation or exchange, data or keys being visible to others, use of weak algorithms, kernel subversion, etc. Study the source; know the code.
-
IPsec -Definition
+
IPsec---Definition
-
Internet Protocol security extensions to IP v 4; required for IP v6. A +
Internet Protocol security extensions to IPv4; required for IPv6. A protocol for negotiating encryption and authentication at the IP (host-to-host) level. SSL secures only one application socket; SSH secures only a login; PGP secures only a specified file or @@ -119,49 +120,34 @@
Installing IPsec
-
Starting from the BSD 3.0 stable release,
+
Most of the modern versions of FreeBSD have IPsec support + in their base source. So you'll probably will need to + include IPSEC option in your kernel config + and, after kernel rebuild and reinstall, configure IPsec + connections using setkey command.
-
-
-
install IPsec v0.04, rebuild, reinstall
-
-
-
run the administration tools (e.g, ipsecadm) and distribute - keys (or use Photuris for key exchange)
-
- -
-
set the routes (rt) up appropriately
-
-
- -
You may want to make an "ipsec_setup" script containing the - ipsecadm and rt commands which establish your IPsec - tunnel. You can run this script automatically at boottime from your - /etc/rc.local The ipsec_setup script will have to contain at - least two ipsecadm commands and one rt command to be - useful.
+
A comprehensive guide on running IPsec on FreeBSD is + provided in FreeBSD + Handbook.
usr/src/sys/i386/conf/KERNELNAME
-
This needs to be present in the kernel config file in order to run - IPsec. After adding it, run config, etc. and rebuild and +
This needs to be present in the kernel config file in order to be able + to capture network data with tcpdump. + Be sure to run config after adding this, and rebuild and reinstall.
-
# The `bpfilter' pseudo-device enables the Berkeley Packet Filter. Be -# aware of the legal and administrative consequences of enabling this -# option. Heh heh. The number of devices determines the maximum number of -# simultaneous BPF clients programs runnable. -pseudo-device bpfilter 2 #Berkeley packet filter - -# IPSEC -options IPSEC -options "MD5" -pseudo-device enc 1
+
device bpf +

Maurer's Universal Statistical Test (for block size=8 bits)
+ +
You can find the same code at + this link.