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 Path-MTU discovery for each tunnel, and fragmentation/DF support in
   9 netlink code.
  10
  11 Separation of device drivers from IP router code - driver produces a
  12 stream of packets (which has a tag indicating type and parameters).
  13 Router module can be connected to stream to multiplex it between
  14 different tunnels.
  15
  16 Support for dynamic creation of streams/tunnels to cope with laptops,
  17 etc.
  18
  19 See also file "TODO".
  20
  21 * Planned for version 0.1.14
  22
  23 RFC1812-compliance in netlink.c
  24
  25 * New in version 0.1.13
  26
  27 site.c code cleaned up; no externally visible changes
  28
  29 secnet now calls setsid() after becoming a daemon.
  30
  31 secnet now supports TUN on Solaris 2.5 and above (and possibly other
  32 STREAMS-based systems as well).
  33
  34 The TUN code now tries to auto-detect the type of "TUN" in use
  35 (BSD-style, Linux-style or STREAMS-style).  If your configuration file
  36 specifies "tun-old" then it defaults to BSD-style; however, since
  37 "tun-old" will be removed in a future release, you should change your
  38 configuration file to specify "tun" and if there's a problem also
  39 specify the flavour in use.
  40
  41 Example:
  42 netlink tun-old {
  43         ...
  44 };
  45 should be rewritten as
  46 netlink tun {
  47         flavour "bsd";
  48         ...
  49 };
  50
  51 The flavours currently defined are "bsd", "linux" and "streams".
  52
  53 The TUN code can now be configured to configure interfaces and
  54 add/delete routes using one of several methods: invoking a
  55 "linux"-style ifconfig/route command, a "bsd"-style ifconfig/route
  56 command, "solaris-2.5"-style ifconfig/route command or calling ioctl()
  57 directly.  These methods can be selected using the "ifconfig-type" and
  58 "route-type" options.
  59
  60 Example:
  61 netlink tun {
  62         ifconfig-type "ioctl";
  63         route-type "ioctl";
  64         ...
  65 };
  66
  67 The ioctl-based method is now the default for Linux systems.
  68
  69 Magic numbers used within secnet are now collected in the header file
  70 "magic.h".
  71
  72 netlink now uses ICMP type=0 code=13 for 'administratively prohibited'
  73 instead of code 9. See RFC1812 section 5.2.7.1.
  74
  75 The UDP comm module now supports a proxy server, "udpforward".  This
  76 runs on a machine which is directly accessible by secnet and which can
  77 send packets to appropriate destinations.  It's useful when the proxy
  78 machine doesn't support source- and destination-NAT.  The proxy server
  79 is specified using the "proxy" key in the UDP module configuration;
  80 parameters are IP address (string) and port number.
  81
  82 Bugfix: ipset_to_subnet_list() in ipaddr.c now believed to work in all
  83 cases, including 0.0.0.0/0
  84
  85 * New in version 0.1.12
  86
  87 IMPORTANT: fix calculation of 'now' in secnet.c; necessary for correct
  88 operation.
  89
  90 (Only interesting for people building and modifying secnet by hand:
  91 the Makefile now works out most dependencies automatically.)
  92
  93 The netlink code no longer produces an internal routing table sorted
  94 by netmask length.  Instead, netlink instances have a 'priority'; the
  95 table of routes is sorted by priority.  Devices like laptops that have
  96 tunnels that must sometimes 'mask' parts of other tunnels should be
  97 given higher priorities.  If a priority is not specified it is assumed
  98 to be zero.
  99
 100 Example usage:
 101 site laptop { ...
 102         link netlink {
 103                 route "192.168.73.74/31";
 104                 priority 10;
 105         };
 106 };
 107
 108 * New in version 0.1.11
 109
 110 Lists of IP addresses in the configuration file can now include
 111 exclusions as well as inclusions.  For example, you can specify all
 112 the hosts on a subnet except one as follows:
 113
 114 networks "192.168.73.0/24","!192.168.73.70";
 115
 116 (If you were only allowed inclusions, you'd have to specify that like
 117 this:
 118 networks "192.168.73.71/32","192.168.73.68/31","192.168.73.64/30",
 119         "192.168.73.72/29","192.168.73.80/28","192.168.73.96/27",
 120         "192.168.73.0/26","192.168.73.128/25";
 121 )
 122
 123 secnet now ensures that it invokes userv-ipif with a non-overlapping
 124 list of subnets.
 125
 126 There is a new command-line option, --sites-key or -s, that enables
 127 the configuration file key that's checked to determine the list of
 128 active sites (default "sites") to be changed.  This enables a single
 129 configuration file to contain multiple cofigurations conveniently.
 130
 131 NAKs are now sent when packets arrive that are not understood.  The
 132 tunnel code initiates a key setup if it sees a NAK.  Future
 133 developments should include configuration options that control this.
 134
 135 The tunnel code notifies its peer when secnet is terminating, so the
 136 peer can close the session.
 137
 138 The netlink "exclude-remote-networks" option has now been replaced by
 139 a "remote-networks" option; instead of specifying networks that no
 140 site may access, you specify the set of networks that remote sites are
 141 allowed to access. A sensible example: "192.168.0.0/16",
 142 "172.16.0.0/12", "10.0.0.0/8", "!your-local-network"
 143
 144 * New in version 0.1.10
 145
 146 WARNING: THIS VERSION MAKES A CHANGE TO THE CONFIGURATION FILE FORMAT
 147 THAT IS NOT BACKWARD COMPATIBLE.  However, in most configurations the
 148 change only affects the sites.conf file, which is generated by the
 149 make-secnet-sites script; after you regenerate your sites.conf using
 150 version 0.1.10, everything should continue to work.
 151
 152 Netlink devices now interact slightly differently with the 'site'
 153 code.  When you invoke a netlink closure like 'tun' or 'userv-ipif',
 154 you get another closure back.  You then invoke this closure (usually
 155 in the site definitions) to specify things like routes and options.
 156 The result of this invocation should be used as the 'link' option in
 157 site configurations.
 158
 159 All this really means is that instead of site configurations looking
 160 like this:
 161
 162 foo {
 163         name "foo";
 164         networks "a", "b", "c";
 165         etc.
 166 };
 167
 168 ...they look like this:
 169
 170 foo {
 171         name "foo";
 172         link netlink { routes "a", "b", "c"; };
 173         etc.
 174 };
 175
 176 This change was made to enable the 'site' code to be completely free
 177 of any knowledge of the contents of the packets it transmits.  It
 178 should now be possible in the future to tunnel other protocols like
 179 IPv6, IPX, raw Ethernet frames, etc. without changing the 'site' code
 180 at all.
 181
 182 Point-to-point netlink devices work slightly differently; when you
 183 apply the 'tun', 'userv-ipif', etc. closure and specify the
 184 ptp-address option, you must also specify the 'routes' option.  The
 185 result of this invocation should be passed directly to the 'link'
 186 option of the site configuration.  You can do things like this:
 187
 188 sites site {
 189         name "foo";
 190         link tun {
 191                 networks "192.168.73.76/32";
 192                 local-address "192.168.73.76"; # IP address of interface
 193                 ptp-address "192.168.73.75"; # IP address of other end of link
 194                 routes "192.168.73.74/32";
 195                 mtu 1400;
 196                 buffer sysbuffer();
 197         };
 198         etc.
 199 };
 200
 201 The route dump obtained by sending SIGUSR1 to secnet now includes
 202 packet counts.
 203
 204 Point-to-point mode has now been tested.
 205
 206 tun-old has now been tested, and the annoying 'untested' message has
 207 been removed.  Thanks to SGT and JDA.
 208
 209 secnet now closes its stdin, stdout and stderr just after
 210 backgrounding.
 211
 212 Bugfix: specifying network "0.0.0.0/0" (or "default") now works
 213 correctly.
 214
 215 * New in version 0.1.9
 216
 217 The netlink code may now generate ICMP responses to ICMP messages that
 218 are not errors, eg. ICMP echo-request.  This makes Windows NT
 219 traceroute output look a little less strange.
 220
 221 configure.in and config.h.bot now define uint32_t etc. even on systems
 222 without stdint.h and inttypes.h (needed for Solaris 2.5.1)
 223
 224 GNU getopt is included for systems that lack it.
 225
 226 We check for LOG_AUTHPRIV before trying to use it in log.c (Solaris
 227 2.5.1 doesn't have it.)
 228
 229 Portable snprintf.c from http://www.ijs.si/software/snprintf/ is
 230 included for systems that lack snprintf/vsnprintf.
 231
 232 make-secnet-sites.py renamed to make-secnet-sites and now installed in
 233 $prefix/sbin/make-secnet-sites; ipaddr.py library installed in
 234 $prefix/share/secnet/ipaddr.py.  make-secnet-sites searches
 235 /usr/local/share/secnet and /usr/share/secnet for ipaddr.py
 236
 237 * New in version 0.1.8
 238
 239 Netlink devices now support a 'point-to-point' mode.  In this mode the
 240 netlink device does not require an IP address; instead, the IP address
 241 of the other end of the tunnel is specified using the 'ptp-address'
 242 option.  Precisely one site must be configured to use the netlink
 243 device. (I haven't had a chance to test this because 0.1.8 turned into
 244 a 'quick' release to enable secnet to cope with the network problems
 245 affecting connections going via LINX on 2001-10-16.)
 246
 247 The tunnel code in site.c now initiates a key setup if the
 248 reverse-transform function fails (wrong key, bad MAC, too much skew,
 249 etc.) - this should make secnet more reliable on dodgy links, which
 250 are much more common than links with active attackers...  (an attacker
 251 can now force a new key setup by replaying an old packet, but apart
 252 from minor denial of service on slow links or machines this won't
 253 achieve them much).  This should eventually be made configurable.
 254
 255 The sequence number skew detection code in transform.c now only
 256 complains about 'reverse skew' - replays of packets that are too
 257 old. 'Forward skew' (gaps in the sequence numbers of received packets)
 258 is now tolerated silently, to cope with large amounts of packet loss.