NEWS

   1 * Planned for the future
   2
   3 Netlink device that implements an Ethernet bridge.
   4
   5 Modular transform code: choice of block ciphers, modes, sequence
   6 numbers / timestamps, etc. similar to IWJ's udptunnel
   7
   8 * New in version 0.1.11
   9
  10 Lists of IP addresses in the configuration file can now include
  11 exclusions as well as inclusions.  For example, you can specify all
  12 the hosts on a subnet except one as follows:
  13
  14 networks "192.168.73.0/24","!192.168.73.70";
  15
  16 (If you were only allowed inclusions, you'd have to specify that like
  17 this:
  18 networks "192.168.73.71/32","192.168.73.68/31","192.168.73.64/30",
  19         "192.168.73.72/29","192.168.73.80/28","192.168.73.96/27",
  20         "192.168.73.0/26","192.168.73.128/25";
  21 )
  22
  23 secnet now ensures that it invokes userv-ipif with a non-overlapping
  24 list of subnets.
  25
  26 There is a new command-line option, --sites-key or -s, that enables
  27 the configuration file key that's checked to determine the list of
  28 active sites (default "sites") to be changed.  This enables a single
  29 configuration file to contain multiple cofigurations conveniently.
  30
  31 NAKs are now sent when packets arrive that are not understood.  The
  32 tunnel code initiates a key setup if it sees a NAK.  Future
  33 developments should include configuration options that control this.
  34
  35 The tunnel code notifies its peer when secnet is terminating, so the
  36 peer can close the session.
  37
  38 The netlink "exclude-remote-networks" option has now been replaced by
  39 a "remote-networks" option; instead of specifying networks that no
  40 site may access, you specify the set of networks that remote sites are
  41 allowed to access. A sensible example: "192.168.0.0/16",
  42 "172.16.0.0/12", "10.0.0.0/8", "!your-local-network"
  43
  44 * New in version 0.1.10
  45
  46 WARNING: THIS VERSION MAKES A CHANGE TO THE CONFIGURATION FILE FORMAT
  47 THAT IS NOT BACKWARD COMPATIBLE.  However, in most configurations the
  48 change only affects the sites.conf file, which is generated by the
  49 make-secnet-sites script; after you regenerate your sites.conf using
  50 version 0.1.10, everything should continue to work.
  51
  52 Netlink devices now interact slightly differently with the 'site'
  53 code.  When you invoke a netlink closure like 'tun' or 'userv-ipif',
  54 you get another closure back.  You then invoke this closure (usually
  55 in the site definitions) to specify things like routes and options.
  56 The result of this invocation should be used as the 'link' option in
  57 site configurations.
  58
  59 All this really means is that instead of site configurations looking
  60 like this:
  61
  62 foo {
  63         name "foo";
  64         networks "a", "b", "c";
  65         etc.
  66 };
  67
  68 ...they look like this:
  69
  70 foo {
  71         name "foo";
  72         link netlink { routes "a", "b", "c"; };
  73         etc.
  74 };
  75
  76 This change was made to enable the 'site' code to be completely free
  77 of any knowledge of the contents of the packets it transmits.  It
  78 should now be possible in the future to tunnel other protocols like
  79 IPv6, IPX, raw Ethernet frames, etc. without changing the 'site' code
  80 at all.
  81
  82 Point-to-point netlink devices work slightly differently; when you
  83 apply the 'tun', 'userv-ipif', etc. closure and specify the
  84 ptp-address option, you must also specify the 'routes' option.  The
  85 result of this invocation should be passed directly to the 'link'
  86 option of the site configuration.  You can do things like this:
  87
  88 sites site {
  89         name "foo";
  90         link tun {
  91                 networks "192.168.73.76/32";
  92                 local-address "192.168.73.76"; # IP address of interface
  93                 ptp-address "192.168.73.75"; # IP address of other end of link
  94                 routes "192.168.73.74/32";
  95                 mtu 1400;
  96                 buffer sysbuffer();
  97         };
  98         etc.
  99 };
 100
 101 The route dump obtained by sending SIGUSR1 to secnet now includes
 102 packet counts.
 103
 104 Point-to-point mode has now been tested.
 105
 106 tun-old has now been tested, and the annoying 'untested' message has
 107 been removed.  Thanks to SGT and JDA.
 108
 109 secnet now closes its stdin, stdout and stderr just after
 110 backgrounding.
 111
 112 Bugfix: specifying network "0.0.0.0/0" (or "default") now works
 113 correctly.
 114
 115 * New in version 0.1.9
 116
 117 The netlink code may now generate ICMP responses to ICMP messages that
 118 are not errors, eg. ICMP echo-request.  This makes Windows NT
 119 traceroute output look a little less strange.
 120
 121 configure.in and config.h.bot now define uint32_t etc. even on systems
 122 without stdint.h and inttypes.h (needed for Solaris 2.5.1)
 123
 124 GNU getopt is included for systems that lack it.
 125
 126 We check for LOG_AUTHPRIV before trying to use it in log.c (Solaris
 127 2.5.1 doesn't have it.)
 128
 129 Portable snprintf.c from http://www.ijs.si/software/snprintf/ is
 130 included for systems that lack snprintf/vsnprintf.
 131
 132 make-secnet-sites.py renamed to make-secnet-sites and now installed in
 133 $prefix/sbin/make-secnet-sites; ipaddr.py library installed in
 134 $prefix/share/secnet/ipaddr.py.  make-secnet-sites searches
 135 /usr/local/share/secnet and /usr/share/secnet for ipaddr.py
 136
 137 * New in version 0.1.8
 138
 139 Netlink devices now support a 'point-to-point' mode.  In this mode the
 140 netlink device does not require an IP address; instead, the IP address
 141 of the other end of the tunnel is specified using the 'ptp-address'
 142 option.  Precisely one site must be configured to use the netlink
 143 device. (I haven't had a chance to test this because 0.1.8 turned into
 144 a 'quick' release to enable secnet to cope with the network problems
 145 affecting connections going via LINX on 2001-10-16.)
 146
 147 The tunnel code in site.c now initiates a key setup if the
 148 reverse-transform function fails (wrong key, bad MAC, too much skew,
 149 etc.) - this should make secnet more reliable on dodgy links, which
 150 are much more common than links with active attackers...  (an attacker
 151 can now force a new key setup by replaying an old packet, but apart
 152 from minor denial of service on slow links or machines this won't
 153 achieve them much).  This should eventually be made configurable.
 154
 155 The sequence number skew detection code in transform.c now only
 156 complains about 'reverse skew' - replays of packets that are too
 157 old. 'Forward skew' (gaps in the sequence numbers of received packets)
 158 is now tolerated silently, to cope with large amounts of packet loss.