* 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

* New in versino 0.1.11

* 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.