ec-field-test.c: Make the field-element type use internal format.

[secnet] / NOTES

diff --git a/NOTES b/NOTES
index 8619ee5..313a0ff 100644 (file)
--- a/NOTES
+++ b/NOTES
@@ -198,6 +198,8 @@ The optional additional data after the sender's name consists of some
 initial subset of the following list of items:
  * A 32-bit integer with a set of capability flags, representing the
    abilities of the sender.
 initial subset of the following list of items:
  * A 32-bit integer with a set of capability flags, representing the
    abilities of the sender.

+ * In MSG3/MSG4: a 16-bit integer being the sender's MTU, or zero.
+   (In other messages: nothing.)  See below.

  * More data which is yet to be defined and which must be ignored
    by receivers.
 The optional additional data after the receiver's name is not
  * More data which is yet to be defined and which must be ignored
    by receivers.
 The optional additional data after the receiver's name is not


@@ -216,13 +218,68 @@ Capability flag bits must be in one the following two categories:
    applicable.  They may also appear in MSG1, but this is not
    guaranteed.  MSG4 must advertise the same set as MSG2.
 
    applicable.  They may also appear in MSG1, but this is not
    guaranteed.  MSG4 must advertise the same set as MSG2.
 

-No capability flags are currently defined.  Unknown capability flags
-should be treated as late ones.
+Capability bits 8 to 31 are used by Secnet as default capability numbers
+for various features: bit 8 is for the original CBCMAC-based transform,
+and bit 9 for the new EAX transform; bit 10 for traditional finite-field
+Diffie--Hellman; bits 11 to 14 and 16 to 30 are reserved for future
+expansion.  The the low eight bits are reserved for local use, e.g., to
+allow migration from one set of parameters for a particular transform to
+a different, incompatible set of parameters for the same transform. Bit
+31, if advertised by both ends, indicates that a mobile end gets
+priority in case of crossed MSG1.
+
+Bit 15 is special: it signifies (a) that the sender is reporting all of
+its transforms and DH groups explicitly, and (b) that it uses all 32
+capability bits to do so.  Older Secnets only checked the low 16 bits
+for known capabilities.
+
+Whether a capability number is early depends on its meaning, rather than
+being a static property of its number.  That said, the mobile-end-gets
+priority bit (31) is always sent as an `early' capability bit.
+
+
+MTU handling
+
+In older versions of secnet, secnet was not capable of fragmentation
+or sending ICMP Frag Needed.  Administrators were expected to configure
+consistent MTUs across the network.
+
+It is still the case in the current version that the MTUs need to be
+configured reasonably coherently across the network: the allocated
+buffer sizes must be sufficient to cope with packets from all other
+peers.
+
+However, provided the buffers are sufficient, all packets will be
+processed properly: a secnet receiving a packet larger than the
+applicable MTU for its delivery will either fragment it, or reject it
+with ICMP Frag Needed.
+
+The MTU additional data field allows secnet to advertise an MTU to the
+peer.  This allows the sending end to handle overlarge packets, before
+they are transmitted across the underlying public network.  This can
+therefore be used to work around underlying network braindamage
+affecting large packets.
+
+If the MTU additional data field is zero or not present, then the peer
+should use locally-configured MTU information (normally, its local
+netlink MTU) instead.
+
+If it is nonzero, the peer may send packets up to the advertised size
+(and if that size is bigger than the peer's administratively
+configured size, the advertiser promises that its buffers can handle
+such a large packet).
+
+A secnet instance should not assume that just because it has
+advertised an mtu which is lower than usual for the vpn, the peer will
+honour it, unless the administrator knows that the peers are
+sufficiently modern to understand the mtu advertisement option.  So
+secnet will still accept packets which exceed the link MTU (whether
+negotiated or assumed).

 
 
 Messages:
 
 
 
 Messages:
 

-1) A->B: *,iA,msg1,A+,B+,nA
+1) A->B: i*,iA,msg1,A+,B+,nA

 
 i* must be encoded as 0.  (However, it is permitted for a site to use
 zero as its "index" for another site.)
 
 i* must be encoded as 0.  (However, it is permitted for a site to use
 zero as its "index" for another site.)


@@ -232,7 +289,7 @@ zero as its "index" for another site.)
 (The order of B and A reverses in alternate messages so that the same
 code can be used to construct them...)
 
 (The order of B and A reverses in alternate messages so that the same
 code can be used to construct them...)
 

-3) A->B: {iB,iA,msg3,A+,B+,nA,nB,g^x mod m}_PK_A^-1
+3) A->B: {iB,iA,msg3,A+,B+,[chosen-transform],nA,nB,g^x mod m}_PK_A^-1

 
 If message 1 was a replay then A will not generate message 3, because
 it doesn't recognise nA.
 
 If message 1 was a replay then A will not generate message 3, because
 it doesn't recognise nA.


@@ -291,3 +348,37 @@ vaguely recent version of secnet.  (In fact, there is no evidence in
 the git history of it ever being sent.)
 
 This message number is reserved.
 the git history of it ever being sent.)
 
 This message number is reserved.

+
+11) *,*,PROD,A,B
+
+Sent in response to a NAK from B to A.  Requests that B initiates a
+key exchange with A, if B is willing and lacks a transport key for A.
+(If B doesn't have A's address configured, implicitly supplies A's
+public address.)
+
+This is necessary because if one end of a link (B) is restarted while
+a key exchange is in progress, the following bad state can persist:
+the non-restarted end (A) thinks that the key is still valid and keeps
+sending packets, but B either doesn't realise that a key exchange with
+A is necessary or (if A is a mobile site) doesn't know A's public IP
+address.
+
+Normally in these circumstances B would send NAKs to A, causing A to
+initiate a key exchange.  However if A and B were already in the
+middle of a key exchange then A will not want to try another one until
+the first one has timed out ("setup-time" x "setup-retries") and then
+the key exchange retry timeout ("wait-time") has elapsed.
+
+However if B's setup has timed out, B would be willing to participate
+in a key exchange initiated by A, if A could be induced to do so.
+This is the purpose of the PROD packet.
+
+We send no more PRODs than we would want to send data packets, to
+avoid a traffic amplification attack.  We also send them only in state
+WAIT, as in other states we wouldn't respond favourably.  And we only
+honour them if we don't already have a key.
+
+With PROD, the period of broken communication due to a key exchange
+interrupted by a restart is limited to the key exchange total
+retransmission timeout, rather than also including the key exchange
+retry timeout.