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