X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ian/git?p=secnet.git;a=blobdiff_plain;f=NOTES;h=84453dfbf12cc7abd1bb66267107dfa037b7aae9;hp=ae65e4cecf58759b67b66278bda916a58decc5f6;hb=78d458950e6cec7e8fce890362e54e4e9ba5c635;hpb=3454dce4c6909648b711a59b57c5a527036b2a8e

diff --git a/NOTES b/NOTES
index ae65e4c..84453df 100644
--- a/NOTES
+++ b/NOTES
@@ -60,6 +60,17 @@ explicit option. NB packets may be routed if the source OR the
 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
@@ -113,6 +124,22 @@ networks a b c ...
 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:
@@ -166,6 +193,11 @@ i? is appropriate index for receiver
 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
@@ -215,9 +247,7 @@ retransmit or confirm reception. It is suggested that this message be
 sent when a key times out, or the tunnel is forcibly terminated for
 some reason.
 
-XXX not yet implemented.
-
-8) i?,i?,NAK/msg8
+8) i?,i?,NAK (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
@@ -240,3 +270,9 @@ Keepalives are probably a good idea.
 **** Protocol sub-goal 3: send a packet
 
 9) i?,i?,msg0,(send-packet/msg9,packet)_k
+
+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.
+
+10) i?,i?,msg8,A,B,nA,nB,msg?