X-Git-Url: https://git.distorted.org.uk/~mdw/secnet/blobdiff_plain/dd9209d1b2db57bda9123ad0c9796c79895ce187..refs/heads/mdw/xdh:/NOTES

diff --git a/NOTES b/NOTES
index 40cbf04..313a0ff 100644
--- 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.
+ * 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
@@ -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.
 
-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:
 
-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.)