From c6b9004b2db6046c2ba3a8fbdb7033746a4ab492 Mon Sep 17 00:00:00 2001 From: zzz Date: Sun, 13 Mar 2022 11:21:08 -0400 Subject: [PATCH] Prop. 159 updates --- i2p2www/spec/proposals/159-ssu2.rst | 92 +++++++++++++++++++++-------- 1 file changed, 66 insertions(+), 26 deletions(-) diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index 5c4f85b5..ea1e8943 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/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-02-27 + :lastupdated: 2022-03-13 :status: Open :target: 0.9.55 @@ -4297,6 +4297,10 @@ Notes by any ACK, I2NP, First Fragment, or Follow-on Fragment block. If the requirement is not met, a Padding block must be included. +- Each packet number may only be used once. + When retransmitting I2NP messages or fragments, + a new packet number must be used. + KDF for Peer Test -------------------- @@ -4400,6 +4404,7 @@ Unencrypted data (Poly1305 authentication tag not shown): Payload ``````` +- DateTime block - Peer Test block - Padding block (optional) @@ -4500,6 +4505,8 @@ Unencrypted data (Poly1305 authentication tag not shown): Destination Connection ID :: The Source Connection ID received from Alice in Session Request + Packet Number :: Random number generated by Bob + type :: 9 ver :: 2 @@ -4508,8 +4515,6 @@ Unencrypted data (Poly1305 authentication tag not shown): flag :: 1 byte, unused, set to 0 for future compatibility - Packet Number :: Random number generated by Bob - Source Connection ID :: The Destination Connection ID received from Alice in Session Request @@ -4633,7 +4638,7 @@ Unencrypted data (Poly1305 authentication tag not shown): Destination Connection ID :: Randomly generated by Alice - id :: 1 byte, the network ID (currently 2, except for test networks) + Packet Number :: Random number generated by Alice type :: 10 @@ -4643,8 +4648,6 @@ Unencrypted data (Poly1305 authentication tag not shown): flag :: 1 byte, unused, set to 0 for future compatibility - Packet Number :: Random number generated by Alice - Source Connection ID :: Randomly generated by Alice, must not be equal to Destination Connection ID @@ -4834,6 +4837,13 @@ For time synchronization: {% endhighlight %} +Notes: + +Unlike in SSU 1, there is no timestamp in the packet header +for the data phase in SSU 2. +Implementations should periodically send DateTime blocks +in the data phase. + Options ``````` @@ -5084,12 +5094,14 @@ Notes: - Partial message length must be greater than zero. +- As in SSU 1, it is recommended to send the last fragment first, + so that the receiver knows the total number of fragments and can + efficiently allocate receive buffers. + Follow-on Fragment ```````````````````````` An additional fragment (fragment number greater than zero) of an I2NP message. -TODO just send offset instead of fragment number so we don't have to pre-fragment, -and can send as much data as will fit in each packet? .. raw:: html @@ -5121,6 +5133,10 @@ Notes: - Partial message length must be greater than zero. +- As in SSU 1, it is recommended to send the last fragment first, + so that the receiver knows the total number of fragments and can + efficiently allocate receive buffers. + - As in SSU 1, the maximum fragment number is 127, but the practical limit is 63 or less. Implementations may limit the maximum to what is practical for a maximum I2NP message size of about 64 KB, @@ -5223,7 +5239,7 @@ See Relay Process section below. relay tag :: 4 bytes, the itag from Charlie's RI timestamp :: Unix timestamp, unsigned seconds. Wraps around in 2106 - ver:: 1 byte SSU version to be used for the introduction: + ver :: 1 byte SSU version to be used for the introduction: 1: SSU 1 2: SSU 2 asz :: 1 byte IP address size (4 or 16) @@ -5288,7 +5304,7 @@ See Relay Process section below. blk :: 8 size :: 2 bytes, 6 flag :: 1 byte flags, Unused, set to 0 for future compatibility - code:: 1 byte status code: + code :: 1 byte status code: 0: accept 1: reject, reason unspecified 2: rejected by Bob, reason unspecified @@ -5305,7 +5321,7 @@ See Relay Process section below. relay tag :: 4 bytes, the itag from Charlie's RI timestamp :: Unix timestamp, unsigned seconds. Wraps around in 2106 - ver:: 1 byte SSU version to be used for the introduction: + ver :: 1 byte SSU version to be used for the introduction: 1: SSU 1 2: SSU 2 csz :: 1 byte IP address size (4 or 16) @@ -5390,7 +5406,7 @@ either in the same payload (if there's room), or in a previous message. relay tag :: 4 bytes, the itag from Charlie's RI timestamp :: Unix timestamp, unsigned seconds. Wraps around in 2106 - ver:: 1 byte SSU version to be used for the introduction: + ver :: 1 byte SSU version to be used for the introduction: 1: SSU 1 2: SSU 2 asz :: 1 byte IP address size (4 or 16) @@ -5480,7 +5496,7 @@ either in the same payload (if there's room), or in a previous message. blk :: 10 size :: 2 bytes, big endian, size of data to follow msg :: 1 byte message number 1-7 - code:: 1 byte status code: + code :: 1 byte status code: 0: accept 1: reject, reason unspecified 2: rejected by Bob, reason unspecified @@ -5495,10 +5511,10 @@ either in the same payload (if there's room), or in a previous message. For messages 1-4, the data below here is covered by the signature, if present, and Bob forwards it unmodified. - role:: 1 byte role of the signer: + role :: 1 byte role of the signer: 1: Alice 3: Charlie - ver:: 1 byte SSU version to be used for messages 5-7: + ver :: 1 byte SSU version to be used for messages 5-7: 1: SSU 1 2: SSU 2 nonce :: 4 byte test nonce, big endian @@ -5632,7 +5648,8 @@ See ack sections below for discussion. Address `````````````` 2 byte port and 4 or 16 byte IP address. -Alice's address, sent to Alice by Bob +Alice's address, sent to Alice by Bob, +or Bob's address, sent to Bob by Alice. .. raw:: html @@ -5684,8 +5701,14 @@ by Bob to protect the Session Created header. Relay Tag Request ``````````````````````` -In the Session Request message. -Bob may respond with a Relay Tag in the Session Created message. +This may be sent by Alice in a Session Request, Session Confirmed, or Data message. + +When sent in the Session Request, +Bob may respond with a Relay Tag in the Session Created message, +or may choose to wait until receiving Alice's RouterInfo in the +Session Confirmed to validate Alice's identity before responding in a Data message. +If Bob does not wish to relay for Alice, he does not send a Relay Tag block. + .. raw:: html @@ -5702,8 +5725,15 @@ Bob may respond with a Relay Tag in the Session Created message. Relay Tag ``````````` -In the Session Created message. -In response to a Relay Tag Request in the Session Request message. +This may be sent by Bob in a Session Confirmed or Data message, +in response to a Relay Tag Request from Alice. + +When the Relay Tag Request is sent in the Session Request, +Bob may respond with a Relay Tag in the Session Created message, +or may choose to wait until receiving Alice's RouterInfo in the +Session Confirmed to validate Alice's identity before responding in a Data message. +If Bob does not wish to relay for Alice, he does not send a Relay Tag block. + .. raw:: html @@ -5871,14 +5901,19 @@ Notes: Replay Prevention ===================== -Both Session Request and Session Created messages must contain DateTime blocks. +Token Request, Retry, Session Request, Session Created, and Peer Test messages must contain DateTime blocks. Both Alice and Bob validate that the time is within a valid skew (recommended +/- 2 minutes) -and for replay prevention. Bob should reject duplicate Session Request messages +and for replay prevention. Bob should reject duplicate +Token Request, Retry, and Session Request messages, even if the skew is valid, via a Bloom filter or other mechanism. -Routers should use standard flow control and retransmission mechanisms to +Duplicate Session Created and Session Confirmed messages will +not validate because the Noise handshake state will not be in the correct state to decrypt them. + +Routers should use the data message packet number to detect and drop duplicate data phase messages. +Each packet number should only be used once. @@ -6787,11 +6822,13 @@ Alice must verify that all three options are present and valid before connecting using the SSU2 protocol. When published as "SSU" with "s", "i", and "v" options, +and with "host" and "port" options, the router must accept incoming connections on that host and port for both SSU and SSU2 protocols, and automatically detect the protocol version. When published as "SSU2" with "s", "i", and "v" options, +and with "host" and "port" options, the router accepts incoming connections on that host and port for the SSU2 protocol only. @@ -6805,7 +6842,7 @@ in the "SSU2" address than the "SSU" address, so SSU2 is preferred. If multiple SSU2 RouterAddresses (either as "SSU" or "SSU2") are published in the same RouterInfo (for additional IP addresses or ports), all addresses specifying the same port must contain the identical SSU2 options and values. -In particular, all must contain the same static key and iv. +In particular, all must contain the same static key "s" and introduction key "i". @@ -6819,16 +6856,19 @@ so that Bob may validate the key after receiving Alice's RouterInfo in Session C - s=(Base64 key) As defined above for published addresses. +- i=(Base64 key) + As defined above for published addresses. + - v=2 As defined above for published addresses. -This router address will not contain "i", "host" or "port" options, +This router address will not contain "host" or "port" options, as these are not required for outbound SSU2 connections. The published cost for this address does not strictly matter, as it is inbound only; however, it may be helpful to other routers if the cost is set higher (lower priority) than other addresses. The suggested value is 14. -Alice may also simply add the "s" and "v" options to an existing published "SSU" address. +Alice may also simply add the "i" "s" and "v" options to an existing published "SSU" address.