Import release 0.1.12

[secnet] / NEWS

* Planned for the future

Netlink device that implements an Ethernet bridge.

Modular transform code: choice of block ciphers, modes, sequence
numbers / timestamps, etc. similar to IWJ's udptunnel

Path-MTU discovery for each tunnel, and fragmentation/DF support in
netlink code.

* New in version 0.1.12

IMPORTANT: fix calculation of 'now' in secnet.c; necessary for correct
operation.

(Only interesting for people building and modifying secnet by hand:
the Makefile now works out most dependencies automatically.)

The netlink code no longer produces an internal routing table sorted
by netmask length.  Instead, netlink instances have a 'priority'; the
table of routes is sorted by priority.  Devices like laptops that have
tunnels that must sometimes 'mask' parts of other tunnels should be
given higher priorities.  If a priority is not specified it is assumed
to be zero.

Example usage:
site laptop { ...
	link netlink {
		route "192.168.73.74/31";
		priority 10;
	};
};

* New in version 0.1.11

Lists of IP addresses in the configuration file can now include
exclusions as well as inclusions.  For example, you can specify all
the hosts on a subnet except one as follows:

networks "192.168.73.0/24","!192.168.73.70";

(If you were only allowed inclusions, you'd have to specify that like
this:
networks "192.168.73.71/32","192.168.73.68/31","192.168.73.64/30",
	"192.168.73.72/29","192.168.73.80/28","192.168.73.96/27",
	"192.168.73.0/26","192.168.73.128/25";
)

secnet now ensures that it invokes userv-ipif with a non-overlapping
list of subnets.

There is a new command-line option, --sites-key or -s, that enables
the configuration file key that's checked to determine the list of
active sites (default "sites") to be changed.  This enables a single
configuration file to contain multiple cofigurations conveniently.

NAKs are now sent when packets arrive that are not understood.  The
tunnel code initiates a key setup if it sees a NAK.  Future
developments should include configuration options that control this.

The tunnel code notifies its peer when secnet is terminating, so the
peer can close the session.

The netlink "exclude-remote-networks" option has now been replaced by
a "remote-networks" option; instead of specifying networks that no
site may access, you specify the set of networks that remote sites are
allowed to access. A sensible example: "192.168.0.0/16",
"172.16.0.0/12", "10.0.0.0/8", "!your-local-network"

* New in version 0.1.10

WARNING: THIS VERSION MAKES A CHANGE TO THE CONFIGURATION FILE FORMAT
THAT IS NOT BACKWARD COMPATIBLE.  However, in most configurations the
change only affects the sites.conf file, which is generated by the
make-secnet-sites script; after you regenerate your sites.conf using
version 0.1.10, everything should continue to work.

Netlink devices now interact slightly differently with the 'site'
code.  When you invoke a netlink closure like 'tun' or 'userv-ipif',
you get another closure back.  You then invoke this closure (usually
in the site definitions) to specify things like routes and options.
The result of this invocation should be used as the 'link' option in
site configurations.

All this really means is that instead of site configurations looking
like this:

foo {
	name "foo";
	networks "a", "b", "c";
	etc.
};

...they look like this:

foo {
	name "foo";
	link netlink { routes "a", "b", "c"; };
	etc.
};

This change was made to enable the 'site' code to be completely free
of any knowledge of the contents of the packets it transmits.  It
should now be possible in the future to tunnel other protocols like
IPv6, IPX, raw Ethernet frames, etc. without changing the 'site' code
at all.

Point-to-point netlink devices work slightly differently; when you
apply the 'tun', 'userv-ipif', etc. closure and specify the
ptp-address option, you must also specify the 'routes' option.  The
result of this invocation should be passed directly to the 'link'
option of the site configuration.  You can do things like this:

sites site {
	name "foo";
	link tun {
		networks "192.168.73.76/32";
		local-address "192.168.73.76"; # IP address of interface
		ptp-address "192.168.73.75"; # IP address of other end of link
		routes "192.168.73.74/32";
		mtu 1400;
		buffer sysbuffer();
	};
	etc.
};

The route dump obtained by sending SIGUSR1 to secnet now includes
packet counts.

Point-to-point mode has now been tested.

tun-old has now been tested, and the annoying 'untested' message has
been removed.  Thanks to SGT and JDA.

secnet now closes its stdin, stdout and stderr just after
backgrounding.

Bugfix: specifying network "0.0.0.0/0" (or "default") now works
correctly.
		
* New in version 0.1.9

The netlink code may now generate ICMP responses to ICMP messages that
are not errors, eg. ICMP echo-request.  This makes Windows NT
traceroute output look a little less strange.

configure.in and config.h.bot now define uint32_t etc. even on systems
without stdint.h and inttypes.h (needed for Solaris 2.5.1)

GNU getopt is included for systems that lack it.

We check for LOG_AUTHPRIV before trying to use it in log.c (Solaris
2.5.1 doesn't have it.)

Portable snprintf.c from http://www.ijs.si/software/snprintf/ is
included for systems that lack snprintf/vsnprintf.

make-secnet-sites.py renamed to make-secnet-sites and now installed in
$prefix/sbin/make-secnet-sites; ipaddr.py library installed in
$prefix/share/secnet/ipaddr.py.  make-secnet-sites searches
/usr/local/share/secnet and /usr/share/secnet for ipaddr.py

* New in version 0.1.8

Netlink devices now support a 'point-to-point' mode.  In this mode the
netlink device does not require an IP address; instead, the IP address
of the other end of the tunnel is specified using the 'ptp-address'
option.  Precisely one site must be configured to use the netlink
device. (I haven't had a chance to test this because 0.1.8 turned into
a 'quick' release to enable secnet to cope with the network problems
affecting connections going via LINX on 2001-10-16.)

The tunnel code in site.c now initiates a key setup if the
reverse-transform function fails (wrong key, bad MAC, too much skew,
etc.) - this should make secnet more reliable on dodgy links, which
are much more common than links with active attackers...  (an attacker
can now force a new key setup by replaying an old packet, but apart
from minor denial of service on slow links or machines this won't
achieve them much).  This should eventually be made configurable.

The sequence number skew detection code in transform.c now only
complains about 'reverse skew' - replays of packets that are too
old. 'Forward skew' (gaps in the sequence numbers of received packets)
is now tolerated silently, to cope with large amounts of packet loss.