	    swIPe Release 1.0 for SunOS 4.1.3 and 4.1.3_U1
            ==============================================

		Release notes written by ji, 6/5/94

First off, don't expect this to be easy! Read the two papers included
in the doc/ directory before you proceed. The code is still
exprerimental, and its interfaces are rather primitive and arcane.
Better user-level code, key management code, ports to other
architectures, bug reports, and suggestions for improvement are
welcome. We cannot, however, provide technical support or help you too
much. Send swIPe-related mail to swipe@cs.columbia.edu, and look for
the newsgroup alt.security.swipe (to be created some time soon).
Please be patient -- I wrote this code over a year ago, and only now
got around to packaging it up!

WARNING: This distribution differs slightly from the software
described in the swIPe paper. For example, there is no input
filtering, and we support only sneakernet key management.

If you are reading this file, you have already unpackaged the swIPe
distribution. Your should have the following files:

swipe/Makefile
swipe/doc/README
swipe/doc/COPYRIGHT
swipe/doc/swipe-id.txt
swipe/doc/swipe-usenix.ps
swipe/user/Makefile
swipe/user/doload
swipe/user/swprep
swipe/user/sswo
swipe/user/sswo.c
swipe/user/spr
swipe/user/spr.c
swipe/modload/Makefile
swipe/modload/mlsw.c
swipe/modload/swipemod.o
swipe/sys/netinet/debug.h
swipe/sys/netinet/if_sw.c
swipe/sys/netinet/if_sw.h
swipe/sys/netinet/ip_swipe.c
swipe/sys/netinet/ip_swipe.h
swipe/sys/netinet/ip_swipedes.c
swipe/sys/netinet/ip_swipemd5.c

Type make at the top-level directory to make the loadable module
(swipemod.o), the manual keying program (sswo), and the debugging tool
(spr). The swIPe distribution already comes with the binaries, so you
may skip the compilation!

Now, cd to user/ and type (as root)

	./doload

This will modload the swIPe code and create /dev/sw, the
character-special device that swIPe needs for its ioctls.

To use swIPe between two machines, say alice (10.0.0.89) and bob
(192.9.200.2), do the following, after loading swIPe on both.

On alice:

Configure the swIPe interface with the machine's primary IP address,
and a bogus destination address of 1.1.1.1. That address will be used
to trick the routing software into routing packets through the swIPe
interface.

alice# ifconfig sw0 10.0.0.89 1.1.1.1 up

Set up the policy and keys to use between alice and bob. Packets will
be authenticated (-a) and/or encrypted (-e). Keys are arbitrary length
ascii strings (if they contain spaces, they must be quoted so that the
shell passes them as one argument). If you have a way of generating
good random 128-bit strings, we suggest you simply hex-encode them when
supplying them as keys. Authentication and encryption use the same keys;
change sswo.c if this bothers you. The first key is the key to use
when sending packets to, and the second is the key to use when
receiving packets from the peer host. Notice that sswo does not take
hostnames -- only IP addresses. Again, feel free to change this.

alice# sswo -a -e alice-to-bob-key bob-to-alice-key 10.0.0.89 192.9.200.2

Finally, set up a route so that packets destined for bob will go
through the swIPe interface.

alice# route add host 192.9.200.2 1.1.1.1 1

Do the same on bob:

bob# ifconfig sw0 192.9.200.2 1.1.1.1 up
bob# sswo -a -e bob-to-alice-key alice-to-bob-key 192.9.200.2 10.0.0.89 
bob# route add host 10.0.0.89 1.1.1.1 1

Now, all traffic between alice and bob will be authenticated and
encrypted. When you rekey, even if you use the same keys, make sure to
rekey both machines in order to reset the sequence counter.

swIPe can also be used on a "gateway" machine (or even a pair of
gateway machines -- see the paper for details) to protect an internal
network. We shall briefly show how to configure frank (192.9.200.1) so
that the internal machine bob (192.9.200.2) can talk with the external
machine alice (10.0.0.89).

First, set up alice so that packets destined for bob are swIPed and
sent through frank. The first set of IP addresses defines the source
and destination of the real packet, and the second set of IP addresses
defines the endpoints of the secured tunnel.

alice# ifconfig sw0 10.0.0.89 1.1.1.1 up
alice# sswo -a -e alice-to-bob-via-frank bob-via-frank-to-alice \
	10.0.0.89 192.9.200.2 10.0.0.89 192.9.200.1
alice# route add host 192.9.200.2 1.1.1.1 1

On frank, things are slightly more complicated. First, let us
configure the interface:

frank# ifconfig sw0 192.9.200.1 1.1.1.1 up

Then, we have to specify the converse tunnel to alice, on behalf of bob.

frank# sswo -a -e bob-via-frank-to-alice alice-to-bob-via-frank \
	 192.9.200.2 10.0.0.89 192.9.200.1 10.0.0.89

Bob, of course, doesn't need to run swIPe, but it should be configured
to route packets for alice via frank. In most gateway situations, this
will be the case anyway.

There is no input filtering in this release. You can't use *just*
swIPe to build an all-purpose firewall yet. Rather, you should use it
on a bastion host to allow properly authenticated traffic in, while
using your traditional firewall mechanisms to protect you against
ordinary IP traffic. If you don't understand this, see Cheswick and
Bellovin's new book.

--
/ji
