destination is marked as allowing routing [otherwise packets couldn't
get back from eg. chiark to a laptop at greenend]).
+[the even newer plan]
+
+secnet sites are configured to grant access to particular IP address
+ranges to the holder of a particular public key. The key can certify
+other keys, which will then be permitted to use a subrange of the IP
+address range of the certifying key.
+
+This means that secnet won't know in advance (i.e. at configuration
+time) how many tunnels it might be required to support, so we have to
+be able to create them (and routes, and so on) on the fly.
+
** VPN-level configuration
At a high level we just want to be able to indicate which groups of
pubkey x y z: x=keylen, y=encryption key, z=modulus
mobile: declare this to be a 'mobile' site
+** Logging etc.
+
+There are several possible ways of running secnet:
+
+'reporting' only: --version, --help, etc. command line options and the
+--just-check-config mode.
+
+'normal' run: perform setup in the foreground, and then background.
+
+'failed' run: setup in the foreground, and terminate with an error
+before going to background.
+
+'reporting' modes should never output anything except to stdout/stderr.
+'normal' and 'failed' runs output to stdout/stderr before
+backgrounding, then thereafter output only to log destinations.
+
** Protocols
*** Protocol environment:
Note that 'i' may be re-used from one session to the next, whereas 'n'
is always fresh.
+The protocol version selection stuff is not yet implemented: I'm not
+yet convinced it's a good idea. Instead, the initiator could try
+using its preferred protocol (which starts with a different magic
+number) and fall back if there's no reply.
+
Messages:
1) A->B: *,iA,msg1,A,B,protorange-A,nA
sent when a key times out, or the tunnel is forcibly terminated for
some reason.
-XXX not yet implemented.
+**** Protocol sub-goal 3: send a packet
+
+8) i?,i?,msg0,(send-packet/msg9,packet)_k
-8) i?,i?,NAK/msg8
+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.
+
+**** Other messages
+
+9) i?,i?,NAK (NAK is encoded as zero)
If the link-layer can't work out what to do with a packet (session has
-gone away, etc.) it can transmit a NAK back to the sender. The sender
-can then try to verify whether the session is alive by sending ping
-packets, and forget the key if it isn't. Potential denial-of-service
-if the attacker can stop the ping/pong packets getting through (the
-key will be forgotten and another key setup must take place), but if
-they can delete packets then we've lost anyway...
+gone away, etc.) it can transmit a NAK back to the sender.
-The attacker can of course forge NAKs since they aren't protected. But
-if they can only forge packets then they won't be able to stop the
-ping/pong working. Trust in NAKs can be rate-limited...
+This can alert the sender to the situation where the sender has a key
+but the receiver doesn't (eg because it has been restarted). The
+sender, on receiving the NAK, will try to initiate a key exchange.
-Alternative idea (which is actually implemented): if you receive a
-packet you can't decode, because there's no key established, then
-initiate key setup...
+Forged (or overly delayed) NAKs can cause wasted resources due to
+spurious key exchange initiation, but there is a limit on this because
+of the key exchange retry timeout.
-Keepalives are probably a good idea.
+10) i?,i?,msg8,A,B,nA,nB,msg?
-**** Protocol sub-goal 3: send a packet
+This is an obsolete form of NAK packet which is not sent by any even
+vaguely recent version of secnet. (In fact, there is no evidence in
+the git history of it ever being sent.)
-9) i?,i?,msg0,(send-packet/msg9,packet)_k
+This message number is reserved.
~ian / secnet.git / blobdiff