Prop. 159 minor updates

i2p2www/spec/proposals/159-ssu2.rst

@@ -5,7 +5,7 @@ SSU2
     :author: eyedeekay, orignal, zlatinb, zzz
     :created: 2021-09-12
     :thread: http://zzz.i2p/topics/2612
-    :lastupdated: 2022-03-22
+    :lastupdated: 2022-03-24
     :status: Open
     :target: 0.9.55
 
@@ -4517,7 +4517,8 @@ Unencrypted data (Poly1305 authentication tag not shown):
 
 
   Destination Connection ID :: The Source Connection ID
-                               received from Alice in Session Request
+                               received from Alice in Token Request
+                               or Session Request
 
   Packet Number :: Random number generated by Bob
 
@@ -4530,7 +4531,8 @@ Unencrypted data (Poly1305 authentication tag not shown):
   flag :: 1 byte, unused, set to 0 for future compatibility
 
   Source Connection ID :: The Destination Connection ID
-                          received from Alice in Session Request
+                          received from Alice in Token Request
+                          or Session Request
 
   Token :: 8 byte unsigned integer, randomly generated by Bob, nonzero,
            or zero if session is rejected and a termination block is included
@@ -4593,7 +4595,7 @@ Token Request (Type 10)
 Alice sends to Bob. Bob response with a Retry message.
 Size: 48 + payload size.
 
-If Alice does not have a valid token, Alice may send this message
+If Alice does not have a valid token, Alice should send this message
 instead of a Session Request, to avoid the asymmetric encryption
 overhead in generating a Session Request.
 
@@ -5068,6 +5070,13 @@ as in [NTCP2]_ (type, message id, short expiration).
 
 {% endhighlight %}
 
+Notes:
+
+- This is the same 9-byte I2NP header format used in NTCP2.
+
+- This is exactly the same format as the First Fragment block,
+  but the block type indicates that this is a complete message.
+
 
 First Fragment
 ```````````````
@@ -5106,6 +5115,11 @@ TODO include total length so that receiver can allocate a buffer?
 
 Notes:
 
+- This is the same 9-byte I2NP header format used in NTCP2.
+
+- This is exactly the same format as the I2NP Message block,
+  but the block type indicates that this is a the first fragment of a message.
+
 - Partial message length must be greater than zero.
 
 - As in SSU 1, it is recommended to send the last fragment first,
@@ -6042,7 +6056,7 @@ Total Timeout
 Recommended total timeout for the handshake is 20 seconds.
 
 
-Token
+Tokens
 =============
 
 The Token in the Session Request header is used for DoS mitigation.
@@ -6068,22 +6082,25 @@ A token sent in a New Token block in an established session
 may be used in a subsequent connection, and it
 expires at the time specified in that block.
 Expiration is specified by the sender; recommended values are
-one hour minimum, several hours or days maximum.
-A router should delete all its saved tokens if its IP, router hash, or keys change.
+one hour minimum, several hours maximum.
+
+If a router's IP or port changes, it must delete all saved tokens
+(both inbound and outbound) for the old IP or port, as they are no longer valid.
 Tokens may optionally be persisted across router restarts, implementation dependent.
 Acceptance of an unexpired token is not guaranteed; if Bob has forgotten or deleted
 his saved tokens, he will send a Retry to Alice.
+A router may choose to limit token storage, and remove the oldest stored tokens
+even if they have not expired.
 
 New Token blocks may be sent from Alice to Bob or Bob to Alice.
 They would typically be sent once, during or soon after session establishment.
 The token may be resent before or after expiration with a new expiration time,
 or a new token may be sent.
 Routers should assume that only the last token received is valid;
-there is no requirement to store multiple inbound or outbound tokens for the same router.
+there is no requirement to store multiple inbound or outbound tokens for the same IP/port.
 
-A token is bound to the combination of source IP/port, destination IP/port,
-static keys, and router hashes. A token received on IPv4 may not be used
-for IPv6 or vice versa.
+A token is bound to the combination of source IP/port and destination IP/port.
+A token received on IPv4 may not be used for IPv6 or vice versa.