changelog, Makefile.in: finalise 0.3.4

SECURITY: fixed fix to buffer handling

The implementation of buf_remaining_space in 92795040 was entirely
broken.  It failed to take buf->size into account at all !

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog, Makefile.in: finalise 0.3.3

buffers: Rename buffer_if.len to buffer_if.alloclen.

This field contains the total amount of space allocated, starting at
base, which may be less than the amount of space available after
start.

Rename it to help avoid confusion.  This also enabled me to review
every site where this variable was used to verify that the length
checks are all now correct.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

buffers: Introduce buf_remaining_space

This calculates the remaining space available to append to a buffer.

Use it in tun_afterpoll and udp_afterpoll (no functional change),
slip_unstuff and buf_append (fixes what appear to be latent bugs).

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

ipaddr_to_string: SECURITY: Do not allocate

ipaddr_to_string is used in many places including runtime logging.
Handling its memory allocation is annoyingly fiddly.  Indeed there is
at least one possible memory leak, which represents a potential denial
of service bug.

None of the callers keep the answers for any length of time.

So make it return the next one of a series of round-robin buffers,
instead, and remove all the freeing at all the call sites.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

udp: SECURITY: Pass correct size argument to recvfrom

Otherwise we risk overflowing the buffer.  This is a critical security
problem.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog, Makefile.in: finalise 0.3.3~beta1

site: transport peers: Use source of NAK packets as reply address

If we get a NAK from our current peer and initiate a key exchange, we
should take the source address of the NAK as a hint for the peer's
public address.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: transport peers: MSG1: use transport_compute_setupinit_peers

This implies a functional change: now we start out with the data
transport peers.  For a mobile peer this is a bugfix; for a non-mobile
peer it implies no functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: transport_peers: Rename incoming_packet_addr

Rename the prod_hint_addr argument; we are going to use it for other
things too.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: transport peers: Break out transport_resolve_complete,_tardy

Make two new functions
  transport_resolve_complete
  transport_resolve_complete_tardy
which encapsulate the transport peers manipulations for these two
situations.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

test-example: Provide clean target in Makefile

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

make-secnet-sites: Put our path component at the beginning

Otherwise installing the modern `ipaddr' python module (as found eg
python-ipaddr.deb) breaks secnet, because it will appear on the path
before our own copy of the Cendio Systems AB one.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog, Makefile.in: finalise 0.3.2

changelog, Makefile.in: finalise 0.3.2~beta1

site: Force use of configured name only if we are mobile

In c22c3541 we arranged to honour our local configured name for the
peer even if the peer initiated the key setup.  Previously we used the
address on the incoming packets.

However, this change can break some half-broken configurations, which
would otherwise mostly work.  Some of these configurations may even be
deliberate, as a kind of poor version of the mobile site feature.

But, if we are a mobile site it is very unlikely that we have a broken
name or address (or at least, if we do, that things would work well).

So, for now, restrict this new behaviour to the situation where we are
mobile.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog: Document additional name resolution

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Do name resolution on peer-initiated key setup too

The current arrangement locks in the peer address used for key
exchange, for the lifetime of the key.

Most configurations do not have the secnet bind to a particular
address.  And secnet takes no particular care about the source address
on its packets.  The result is that secnet might reply from a
different address.  (Also NAT might cause this effect.)

But (unless the peer is mobile) it is not ideal to use an address
other than the configured address.  In particular, if we are mobile
then the network environment, and our routing to the peer, might
change so that the previous source address is not valid.  This could
result in an extended failure (of up to the key expiry lifetime).

Arguably this is a configuration error, but there is another reason to
dislike the current behaviour: it has the rather odd property that if
an opponent (or incompetent middlebox) reroutes/NATs the packets
during key exchange, the entire dataflow (at least in one direction)
might end up sent via a bizarre route (or, if the environment changes,
not delivered).

We still want to use the peer's address as a hint though: otherwise we
would have to stall a peer-initiated key setup while resolution takes
place.

So:

 * Initiate a peer address lookup when we get an incoming MSG1, if we
   have a configured name or address.  We do this in parallel with the
   key exchange.  (As a result it is possible that a peer address
   lookup might complete well after the key exchange has finished.)

 * Except, when the incoming MSG1 has crossed with ours, we must
   already have done the the lookup so do not do it again.

 * And, in this latter case do not unconditionally record the incoming
   peer address; instead, treat it as a "msgok"; otherwise we might
   unjustifiably overwrite an address we got from the configuration
   with the incoming address from the packet.

 * The two points above mean moving the transport_record_peer from
   process_msg1 into its two call sites, since the logic now needs to
   differ between them.

 * Handle the results of the MSG1-prompted peer address lookup.  In
   SITE_RESOLVE we do as we did before.  In most of the other states,
   we record the address and use it for future communications.

 * If the resolution fails with a non-mobile site, keep using the
   apparently-working peer address(es).

 * With a mobile site the currently working peer address might stop
   working so this is not acceptable.  In that case, make arrangements
   that a failed peer address lookup will be retried quickly - but in
   the meantime, there is no need to halt the packet flow.

 * If the attempt to submit the resolver query fails, just use the
   apparent peer address as before.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Changes in v2:
  * Run the resolution after entering the new state, not before.
    Otherwise if we get the callback reentrantly, we get a bit
    confused.

site: Log when resolution completes

This helps with debugging dns and reentrancy problems.

Also, assert in ensure_resolving that we have an address.  This makes
it slightly clearer that callers are expected to have checked this.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
New patch in v2 of the series.

site: Make local_mobile be a site state variable

We are going to want to know whether we are mobile to decide how to
handle certain name resolution failures.

Also fix a typo in a comment.

No functional change in this patch.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Explicitly track name resolution status

Introduce a new variable st->resolving which tracks whether we have an
outstanding name resolution request.  This makes it safe to (try to)
start name resolution (via the new function ensure_resolving) multiple
times etc.

No resulting functional change from just this patch.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Changes in v2:
  * Do slightly complicated dance with st->resolving, which is needed
    because of the reentrancy hazard posted by resolver->request.  In
    v1 of the series there was a bug here which could cause the site
    state machine to lock up.

site: Fix bugs when resolver request submission fails

Previously, if adns_submit failed:
 - the struct query in resolver.c was leaked
 - nothing was logged
 - the return value from resolver->request was ignored so the site
   state machine would hang

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
Changes in v2:
  * Fixed typo in commit message.

site: Document some reentrancy hazards in comments

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
---
New patch in v2 of the series.

When printing version (eg during startup), use value from git-describe

Thus include git commit id where applicable.

Some complications in the Makefile[.in] are needed to ensure that the
version is regenerated iff required.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog: Document logging and security fix

site logging: Log peer addresses on timeout

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

comm: Introduce comm_addr_to_string

Convenience function for calling addr_to_string.  Use it where
appropriate.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site logging: Break out logtimeout

We're going to add something to log peer addresses on timeout, so we
need to centralise these two timeout logging calls.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site logging: introduce vslog

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site logging: Use [v]slilog_part in slog

Eliminates a pointless log message assembly buffer.

No ultimate functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site logging: Break out event_log_priority

We're going to want to call this in more places.  While we're at it,
line the switch statement up more prettily.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile.in: introduce -Wunused-function

And delete the two unused logging functions log_multi and syslog_log.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

log: Introduce slilog_part; abolish log_if->logfn

[v]Message provides a facility for sending messages to the system log
which are assembled out of pieces.  This is quite useful.  Generalise
it to other logger interfaces too:
  * Move the functionality out of vMessage into a new function
    vslilog_part.  Provide slilog_part too.
  * Move the assembly buffer: it was a static variable (used only
    for the system log); now it is a member of the log_if.  (Yes,
    the log_if, not the private state, because it applies for all
    loggers and is used by common code ie vslilog_part.)
  * Initialise log_if->buff[0] everywhere.
  * Rename LOG_MESSAGE_BUFLEN from MESSAGE_BUFLEN since now it
    has to live in secnet.h.

Also, remove log_if->logfn.  All the call sites use vlogfn.  Doing
this in this patch makes it easy to see that we haven't missed any
places where we should be initialising log_if->buff[0].

We currently have -Wunused ie -Wunused-functions, so for now we leave
the pointless definitions of the various loggers' logfns.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: SECURITY: Properly update full peer address array

If we already have the maximum number of peer addresses, do not
stuff the peer address into the wrong slot.

If a site instance is configured with the maximum permissible limit on
the number of mobile peer addresses (ie with mobile-peers-max set to
5), this overruns the transport peers array.  In such a configuration
this is a security problem.  It looks like a denial of service and
privilege escalation can't be ruled out.  Configurations without
mobile peers are not affected.

Otherwise it simply means the address is ignored.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

secnet.h: Change bool_t to a C99 _Bool

This will (a) stop misleading readers of the code (b) make it possible
to write code expecting an implicit !! to be applied to assignments to
booleans (c) possibly make secnet smaller or faster.

I don't expect this to produce any functional change, but I haven't
reviewed every bool_t in secnet to check.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

debian/changelog: Start new version 0.3.2~~

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Makefile.in: Improve push rune in release checklist

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog, Makefile.in: finalise 0.3.1

changelog, Makefile.in: finalise 0.3.1~beta3

Makefile.in: pass -Wno-unused-parameter explicitly

One would think that -Wno-unused would suffice.  However, in gcc 4.8.2
it doesn't, even though it does in 4.7.2.  This is arguably a bug in
gcc (filed as Debian #747345), but it looks like we will have to work
around it.

This avoids this error message:
 util.c:202:29: error: unused parameter 'phase' [-Werror=unused-parameter]
and several like it.

Reported-by: Stephen Early <sde@individualpubs.co.uk>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
CC: Stephen Early <sde@individualpubs.co.uk>

netlink: fix const-correctness of ip_fast_csum fallback

211cd627 corrected the constness of ip_csum and ip_fast_csum.  But the
latter has two implementations, and we missed the C fallback.  This
resulted in the following compile error on non-i386 platforms:
  netlink.c:606:2: error: passing argument 1 of `ip_fast_csum'
  discards `const' qualifier from pointer target type [-Werror]

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
CC: Stephen Early <sde@individualpubs.co.uk>

changelog, Makefile.in: finalise 0.3.1~beta2

netlink: Generate ICMP correctly if point-to-point

In point-to-point configurations, we need to make sure that ICMP we
generate (a) has the right source address (we have to borrow the
address of the peer or the local host, depending) and (b) is delivered
in the right direction (back to wherever the bad packet came from).

To this end netlink_icmp_tmpl now takes an explicit ICMP source
address parameter, for netlink_icmp_simple to provide the correct
address.

We replicate a small amount of logic from netlink_incoming (the choice
between netlink_client_deliver, netlink_host_deliver, and
netlink_packet_forward/netlink_packet_deliver).  But netlink_incoming
is not suitable because it is intended only for packets from outside
secnet.  For example, in a non-ptp configuration it will reject
packets whose source address is secnet's address.  And writing it out
again is arguably clearer anyway.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Move local_address into struct netlink

All the actual netlinks have this, and proper ICMP generation on
point-to-point links is going to need it.

The dummy "null" netlink previously didn't have this parameter; now,
it is mandatory.  This is an incompatible configuration change, but
only for configurations which contain a null netlink - which we think
is only done for testing or debugging.

No other functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Plumb "sender" through to ICMP generation

In order for a point-to-point netlink to correctly construct and
deliver ICMP, it needs to know which way the original packet was
going.  So provide the ICMP generation code with this information, in
the form of the "sender" client.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Break out sender_name

We are going to want to add another call site.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: rename "client" to "sender" in many places

In the bulk of the netlink code, the name "client" was used to refer
to the originating netlink_client (or NULL if the packet was
originated from the host or netlink itself).

This is a bit confusing.  Rename the variable to "sender", describing
its function rather than its type.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog, Makefile.in: finalise 0.3.1~beta1

site: Negotiate (configurable) MTU

Calculate the inter-site mtu for each virtual link to a peer site, and
honour it.  This is the maximum of our desired mtu, and the peer's.

Here our desired MTU is normally our local kernel netlink mtu, but it
can be configured separately.

Extend MSG3/MSG4 optional data to contain an MTU advertisement.

The result is that overall it is possible to set an mtu-target which
is lower than the vpn's conventional mtu and expect shorter
on-the-wire packets to a particular site - provided that site's peers
are all upgraded.

In this patch we also update NOTES for the new protocol and README for
the new configuration option.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Remove clone-and-hack of signature verification

process_msg3 and process_msg4 shared some signature checking etc.
code.  Move it into a common function.  No functional change other
than to error messages.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Advise netlink clients of the local link MTU

From the netlink client's point of view this is advisory: it may be
that other peers (perhaps reached via that netlink) would prefer a
larger or smaller MTU.

This information will be consumed in later patches.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: fix IP length check (SECURITY)

This would erroneously abort on some very short packets.

This is a DoS vulnerability, exposed to internal sites only.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Only complain about initial frags for us

secnet has no reassembly code and logs whenever it receives fragments.
Change this to only log when receiving initial fragments; this reduces
noise in the log.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

fragmentation: Fragment packets as required

netlink now honours its clients' and its local link's declared mtus.
If the packet is too large, it fragments it if possible, or perhaps
sends an ICMP Frag Needed error.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

util.h: Provide MIN and MAX macros

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Provide MDEBUG macro

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Break out netlink_host_deliver

Provide a helper function for calling deliver_to_host, and use it at
the two call sites.

A side effect is that packets which came via point-to-point links are
properly counted.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Abolish client param to netlink_icmp_simple

This parameter is not used (and some call sites pass NULL, anyway).

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

fragmentation: Rename "frag_off" field to "frag"

This 16-bit superfield contains all of the fragmentation info, not
just the offset.

No functional change.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Make ip_csum and ip_fast_csum const-correct

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Be more conservative about ICMP errors

Default to not sending ICMP error messages for unknown incoming ICMP
type codes.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Set "unused" in ICMP header (SECURITY)

Previously, the "unused" field in our ICMP messages was left
uninitialised (!)

This is a security problem, at least in principle, as the field would
as a result contain bits of previous packets.  In practice, the
information leaked could be IP options, TCP ports and sequence
numbers, or UDP ports, length and/or checksum, or similar information
for other protocols, so the impact is limited.

Set the field to 0.  Also, make provision for netlink_icmp_simple's
callers to be able to specify a different value, if desired.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

fragmentation: Fix fragmentation field check

When an incoming packet is for secnet itself, secnet checks the
fragmentation field in the IP header.

(Contrary to the spec, secnet discards fragmented packets addressed to
its own private address; however, this is a tolerable defect as secnet
never sends packets of its own apart from ICMP errors and ICMP Echo
Reply.)

However, secnet would incorrectly check the reserved flag bit in the
16-bit fragmentation superfield.  Fix this.  Also introduce some
manifest constants for the bits in the 16-bit fragmentation
superfield.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

slip: Drop packets >mtu (SECURITY)

Trying to send them to the kernel crashes userv-ipif.
This is a DoS vulnerability, exposed to internal sites only.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

test-example: USE mtu of 1400 not 500 (!)

500 is less than the IPv4 minimum MTU.  1400 is the conventional value
on the SGO VPN and is a plausible choice for vpns running mostly over
reasonably sane ethernets.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

test-example: Provide test which uses unshare(8)

This allows more realistic testing, with the "outside" copy of secnet
in a separate environment with its own instance of the network stack.

We have to go through some contortions to get the user a shell in the
"outside" environment, since unshare -n also breaks AF_UNIX, and we
want to keep the terminal secnet is invoked in just for secnet.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Remove a newline from p-t-p startup message

Another newline will be printed later, after the routes.  With one
link per tunnel it's better to make these messages (of which there are
many) one line each.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Avoid crash with clientless netlink

In some pathological configurations, it can happen that a packet is
received from the kernel by a netlink which has no clients (that is,
where netlink_inst_reg has not been called).

Don't crash when this happens; instead, print a log message including
the source and destination addresses.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

netlink: Break out netlink_client_deliver

Provide a helper function for calling client->deliver, and use it at
the two call sites.  We are going to fix a bug in this area and want
to bring the implementations together so we have only one place to
fix.

A side effect is that packets via point-to-point links are properly
counted.

I have verified that I caught all of the call sites by experimentally
changing the field name from "deliver" to "deliverx" in netlink.h, and
inspecting the locations of the resulting compiler errors.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Fix formatting error in secnet.8 manpage.

more release checklist changes

Updates to release checklist in Makefile.in.

Release of 0.3.0.  No code changes since 0.3.0~beta3.

changelog, Makefile: finalise 0.3.0~beta3

changelog: 0.3.0~beta3~~iwj1

site: Initialise st->scratch with SETUP_BUFFER_LEN space.

Otherwise, if we're unlucky, we end up trying to construt a PROD
packet before we have ever used buffer_copy on scratch, which causes
an assertion failure ("buf->size <= buf->len - amount" at util.c:257).

Reported-by: Simon Tatham <anakin@pobox.com>
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog: Mention netlink short packet discard.

netlink: Safely discard short packets

Short packets arriving at the netlink should not be processed.

Previously, we suffered buffer read overruns.  In principle this might
be some kind of security problem, as it might make it possible to read
and have returned parts of the buffer which were used previously for
other data.  I haven't analysed this possibility in any detail.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

changelog: Describe 0.3.0~beta2

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: New PROD message

We introduce a new message PROD which requests that the peer initiate
a key exchange with us, if it doesn't already have a key.

This helps significantly reduce a possible "dead period" when one end
of a connection is restarted during key exchange.  The dead period is
now limited to the time taken for the interrupted key exchange to time
out.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

slip: Buffer management (max_start_pad) fixes

Nothing in slip.c calls buffer_init for the first packet.  We don't
normally notice this because userv-ipif _both_ prints a confirmation
END byte right away, _and_ bookends packets with ENDs.

But this should be fixed.  Otherwise we fail an assertion when we try
to prepend things to the first data packet.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

udp.c: call buffer_init

Nothing in udp.c call buffer_init.  This might result in start padding
underflows (assertion failures) if packets come in via routes that
don't strip (much) off the front and then go out via routes that do
add lots at the front.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

max_start_pad: calculate globally, not via client graph

There is quite a lot of plumbing of max_start_pad values from one
place to another.  Sadly this plumbing is not complete, which can lead
to crashes as the start padding is exhausted.  And completing it is a
lot of work which would be difficult to get correct, even if that's
possible in principle.

Instead, we take a different approach.  We calculate a single global
max_pad_start value that can be used everywhere.  It is the sum of:

 * Headers that "site" instances might need add to the start of
   packets (source and destination site indices, message type both
   inside and outside the encryption;

 * Anything that "transform" instances might need to add to the start
   of packets.  This depends on the transforms, but since it isn't a
   priori predictable which path any particular incoming packet might
   take, we have to take the worst case.

   These transform instances are applied only by "site" and each
   packet goes through at most on "forward" transform instance.

 * Anything that "comm" instances might need to add.  This is
   currently only needed for the proxy feature.

This is based on the assumption that a packet may follow one of these
paths:

    comm -->- site_incoming --.         ,-- site_outgoing -->- comm
                               \       /
                                netlink
                               /       \
    tun/slip ----->-----------'         `------>---------- tun/slip

On the inbound side, tun and slip have to set up the buffer with the
necessary start padding.

site_incoming only removes stuff from the beginning (since it uses
transform->reverse).  netlink doesn't add or remove anything.

It is site_outgoing and comm which may need to prepend things.  site
additionally calls transform->forwards.

If in the future a module appears which can take packets out of the
RHS of this diagram and feed them back into the left, it may have to
do something about the buffer.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

Use FORMAT everywhere, and fix up the errors it finds

Many printf-like variadic functions weren't properly decorated with
FORMAT annotations.  Add them everywhere.

It is not possible to annotate a function pointer type, so that
doesn't work for the function pointers in struct log_if.  However, we
have convenience wrapper functions slilog and vslilog, which are
appropriately decorated and therefore safer.  Change all call sites to
use those instead, and leave a comment.  (Rename the function pointer
variable names so that we don't miss any call sites.)

Fix the bugs that this new compiler checking reveals.  These are
nearly all in fatal error reporting, and not very scary.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: support multiple transforms

The "transform" key in site's dictionary argument can now be a list,
as well as just a single transform.

We use 16 bits of the capability mechanism to advertise the transforms
we support; the config is supposed to nominate a transform capability
number (from 0 to 15) for each transform closure - although the
default numbers are sufficient if you don't need to do parameter
rollover.

The receiver of MSG2 intersects the two bitmaps and chooses the best
transform, and states its choice in MSG3.

A protocol downgrade attack is prevented by the fact that the
capability bitmaps are advertised in the signed parts of MSG3 and
MSG4.  (If the one in MSG4 doesn't match what was in MSG2, the MSG4 is
rejected and presumably the key exchange fails.)

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site, transform: per-transform-instance max_start_pad

Replicate the max_start_pad value from the transform interface into
the instance interface.

Use the instance's version in site.c.

While we're at it, add an assertion to confirm that the value of
max_start_pad passed to buffer_init doesn't overrun the buffer.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site, netlink: abolish max_end_pad and min_end_pad

There is much code to compute these values, but they are never used
anywhere.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: dynamically create and destroy transform instances

Rather than making three transform instances at setup time, and then
using setkey on them, we create transform instances as needed and
destroy them when we delete their keys.

This is necessary because we are going to support multiple different
kinds of transform, so each one of the three transforms might be of
different kinds (supplied by different secnet modules) at different
times.

The variables current.transform, auxiliary_key.transform and
new_transform can all be NULL now.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Check transform errors; factor out transform handling

Make sure we always check the error return from transform->forwards
and ->backwards.  Otherwise logic errors in the site state machine
might result in us sending out packets with unencrypted insider
plaintext, or the like, due to the transform being unkeyed when we try
to use it.

Factor some repeated idioms for transform handling into a set of new
functions.  This will make the next patch much easier.

We arrange to pass dispose_transform a pointer to the actual state
variable where the transform is kept; this means that it can be
changed to update that pointer.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: interpret first 4 bytes of extrainfo as capabilities

Define the first four bytes of the additional data (after the nul in
site names in MSG1..4) in the sender's name field to be a capability
bitmask.  Currently no capability flags are defined.

To support this, replace extrainfo and its _len in struct parsedname
with a struct buffer_if.

We record the capabilities from MSG1 or MSG3, and check that they
haven't changed when processing MSG2..4, as applicable.  (Because
older secnets don't cope with flags in MSG1, we have to define two
kinds of capability flag: ones expected to be in MSG1, and ones which
can appear later in the exchange.)

The support for "Early" capabilities is intended to be used in the
future to support algorithm agility in key exchange.

We also advertise our own capabilities (currently, all-bits-zero) in
our own messages.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: use unaligned.h's functions, not pointer cast and ntohl

Switch site.c to using unaligned.h's functions for accessing
multi-byte values inside messages.  There were a few places where this
construction was used:
   something = ntohl(*(uint32_t*)(buf->start + offset));
It is much clearer to use this equivalent construction:
   something = get_uint32(buf->start + offset);

Also the packet's message type was extracted from the message using
get_uint32 and then put through ntohl.  This is, of course, wrong.
Currently all the message type codes are palindromes, so it doesn't
matter in practice.  Fix it anyway.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Extra info in name fields for MSG1, clearer processing

We change the parsing of the names in MSG1 packets to align it with
that used for MSG2..4, abolishing the simple memcmp-based "setupsig"
arrangement.

This means that MSG1 packets, like MSG2..4, can contain extra
information in the name fields.

This results in the following table of behaviours (where "old secnet"
is the version before we introduced additional data at all):
  MSG    Sent name          Old secnet           New secnet
  1      expected           ok                   ok
  1      expected\0extra    rejected             ok, extra data
  1      expected/suffix    rejected             rejected
  1      expect             rejected             rejected
  2-4    expected           ok                   ok
  2-4    expected\0extra    ok, extra ignored    ok, extra data
  2-4    expected/suffix    wrongly accepted     rejected
  2-4    expect             read overrun         rejected

After the new secnet is widely deployed, we will be able to use the
extra data field in MSG1 for public key algorithm agility and public
key rollover.

Also, intend to introduce a new packet which (like MSG1) is addressed
by name rather than the site id; this change makes that easier too.

In detail, we:
 * Make site_incoming extract the message type earlier, and use
   the message type to choose how to check the address.
 * Abolish st->setupsig and st->setupsiglen;
 * Break out a function named_for_us, which uses unpick_msg
   and then checks the names;
 * Arrange to keep the unpicked message from named_for_us and
   reuse it in process_msg1.
 * Eliminate checking dest==0 for name-addressed packets.

This last point constitutes a change to the implemented protocol.  The
old code would treat a packet as name-addressed iff the destination
"index" was zero.  However, the requirement to send a zero in this
field is not documented.  After this patch, peers which send MSG1 with
a non-zero destination index will have their messages honoured rather
than discarded.  But we do document the restriction.

There is no other significant functional implication of this last
point.  Peers which send non-MSG1s with zero destination index will
have their packets rejected both before and afterwards (although there
may be a change in whether a NAK is sent and in logging) but anyway
those peers are broken because all of our generated indexes are
nonzero.

A downside of this change is that we will now unpick an incoming MSG1
repeatedly until we find which site instance wants it.  But this
unpicking is not particularly arduous.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: fix site name checking leaving room for expansion

Previously, secnet would only check that the site names sent by the
peer had the expected site names as prefixes.  This would be a
security bug on a vpn where one site name is the prefix of another
site name.

In fact, if the peer sends a short name, secnet will suffer a buffer
read overrun and maybe crash - although this is exploitable only for
DoS at worst, and not as an information leak.

(With reasonable peers, it won't cause packets to be mishandled,
because the next field after each name string is a 16-byte integer
giving a name or public key byte count, which would have to contain a
value greater than 8000 to look like printable characters.)

Fix this bug.

However, we use this as an opportunity to provide some space (in the
signed part of MSG2..4) for future extensions.  (At present there is
nothing in the parts of MSG3 and MSG4 covered by the signature which
is not supposedly entirely fixed - apart from the amount of
zero-padding at the MS end of our DH public exponent.  This is bad
because it provides no way to do transport protocol upgrade/downgrade
negotiation without leaving open a protocol version downgrade attack.)

After this change the name fields in MSG2..4 are, following the 16-bit
length, either just the characters of the name, or the name, followed
by a nul byte, followed by zero or more bytes of additional data.

Additional data beyond what the receiver expects (which currently
means any additional data), is to be ignored.

Let us work through some examples.  Suppose the expected site name is
"expected".  Here are the behaviours in relation to various names
being transmitted in the packet.  (This applies both to the local
name, and to the remote name; "rejected" means other instances of the
protocol engine get a go, and perhaps the instance with the correct
names will accept the message.)
  MSG    Sent name          Old secnet           New secnet
  1      expected           ok                   ok
  1      expected\0extra    rejected             rejected
  1      expected/suffix    rejected             rejected
  1      expect             rejected             rejected
  2-4    expected           ok                   ok
  2-4    expected\0extra    ok, extra ignored    ok, extra data
  2-4    expected/suffix    wrongly accepted     rejected
  2-4    expect             read overrun         rejected

We will do the same for MSG1 in a later commit.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

NOTES: Remove unimplemented protocol negotiation

The protocol negotiation mechanism documented in NOTES is not
implemented.  Remove it from the document.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

NOTES: Remove paragraph about slow-to-prepare messages

NOTES contained this paragraph:

  Some messages may take a long time to prepare (software modexp on slow
  machines); this is a "please wait" message to indicate that a message
  is in preparation.

This paragraph was immediately after the description of the msg0(msg9)
packet - ie, the ordinary data packet.  It is therefore at the very
least misplaced.

In the git history this paragraph was introduced in "Import release
0.1.14" (4f5e39ec).  However, the diff for that commit (ie the diff
between 0.1.13 and 0.1.4) does not show any code which might
correspond to this comment.

There is not currently any code in site.c which responds to a message
of this kind.  I have had a quick look for code which sends such a
message and failed to find any.

So I think this paragraph represents a never-implemented intent, and
should be removed.  It certainly predates the "hacky parallelism" by a
long way.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

NOTES: Improve documentation of NAKs.

Improve the description of the function of NAK packets.

Document an ancient form of NAK, MSG8.

Add a missing heading "Other messages" and put the description of the
NAK message and of the obsolete NAK in it.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

site: Send NAKs for undecryptable data packets (msg0)

Packets which are not understood are supposed in general to produce
NAKs, to let the peer know that we don't have the key they were using.

However, previously this would only happen if the incoming packet had
a local site index which was not in use.  But it can happen that a
particular index value is reused by a recently restarted secnet.
Previously, in this case, data packets would simply be thrown away
undecryptable.

With this change, undecryptable data packets always generate a NAK.
(But we don't generate a NAK if the packet was decryptable, but
suffered from sequence number skew - if we did, then network glitches
would trigger spurious key exchanges.)

This is particularly relevant for mobile sites, as it can happen that
the fixed site doesn't have an address for the mobile site - so the
association will remain stuck in a broken state until the mobile site
is also restarted.

There is still a potential problem when a site is restarted mid key
exchange.  The peer will refuse to start a new key exchange (because
of the retry timeout) and the restarted site may not know it's
necessary.  This will be dealt with in a later patch.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

udp, util: Break out send_nak function

Move the code in udp.c which constructs NAKs into its own function
in util.c.  This will make it easier to reuse.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>

udp.c: Do not send NAKs in response to NAKs

If an incoming packet isn't name-addressed and has an invalid
destination site id, udp.c would send a NAK.  This is not a good idea
- if somehow the source site id was wrong too, it will result in a NAK
storm.

This is a security vulnerability as it can be used by an attacker to
trigger an unending NAK storm.

Also, improve the message printed when a NAK is sent by udp.c because
no site wanted to handle it.

Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>