From f410760bdc83cc8b31e5202717db064a209d1504 Mon Sep 17 00:00:00 2001 From: zzz Date: Sat, 19 Feb 2022 11:23:12 -0500 Subject: [PATCH] Prop. 159 more updates --- i2p2www/spec/proposals/159-ssu2.rst | 71 +++++++++++++++++++---------- 1 file changed, 46 insertions(+), 25 deletions(-) diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index 42ffbb50..c5def397 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-18 + :lastupdated: 2022-02-19 :status: Open :target: 0.9.55 @@ -2654,18 +2654,18 @@ ciphertexts. The following messages are defined: -==== ================ ===== -Type Message Notes -==== ================ ===== - 0 SessionRequest - 1 SessionCreated - 2 SessionConfirmed - 6 Data - 7 PeerTest - 9 Retry - 10 Token Request -n/a HolePunch -==== ================ ===== +==== ================ ============= ============= +Type Message Header Length Header Encr. Length +==== ================ ============= ============= + 0 SessionRequest 32 64 + 1 SessionCreated 32 64 + 2 SessionConfirmed 16 16 + 6 Data 16 16 + 7 PeerTest 32 32 + 9 Retry 32 32 + 10 Token Request 32 32 +n/a HolePunch 0 0 +==== ================ ============= ============= @@ -3037,6 +3037,7 @@ the pending outbound connection and decrypt the connection ID using the k_header_1 for that connection, it is probably not necessary. If Bob has issues with his NAT or packet routing, it is probably better to let the connection fail. +This design relies on endpoints retaining a stable address for the duration of the handshake. See the Inbound Packet Handling sesion below for additional guidelines. @@ -3056,7 +3057,7 @@ Header Encryption KDF // take the next-to-last 12 bytes of the packet iv = packet[len-24:len-13] - k_header_1 = header protection key 1 + k_header_1 = header encryption key 1 data = {0, 0, 0, 0, 0, 0, 0, 0} mask = ChaCha20.encrypt(k_header_1, iv, data) @@ -3065,7 +3066,7 @@ Header Encryption KDF // take the last 12 bytes of the packet iv = packet[len-12:len-1] - k_header_2 = header protection key 2 + k_header_2 = header encryption key 2 data = {0, 0, 0, 0, 0, 0, 0, 0} mask = ChaCha20.encrypt(k_header_2, iv, data) @@ -3080,7 +3081,7 @@ Header Encryption KDF packet[16:63] = ChaCha20.encrypt(k_header_2, iv, packet[16:63]) - // For Retry only: + // For Retry, Token Request, and Peer Test only: iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0} // encrypt the third part of the header @@ -3529,6 +3530,11 @@ Notes - The unique X value in the initial ChaCha20 block ensure that the ciphertext is different for every session. +- To provide probing resistance, Bob should not send a Retry message + in response to a Session Request message unless the + message type, protocol version, and network ID fields in the Session Request message + are valid. + - Bob must reject connections where the timestamp value is too far off from the current time. Call the maximum delta time "D". Bob must maintain a local cache of previously-used handshake values and reject duplicates, to prevent @@ -3553,24 +3559,29 @@ Notes (Distribution to be determined, see Appendix A.) TODO UNLESS minimum packet size is enforced for PMTU. -- On any error, including AEAD, DH, timestamp, apparent replay, or key +- On any error, including AEAD, DH, apparent replay, or key validation failure, Bob must halt further message processing and drop the message without responding. +- Bob MAY send a Retry message containing a Termination block with a + clock skew reason code if the timestamp in the DateTime block is too + far skewed. + - DoS Mitigation: DH is a relatively expensive operation. As with the previous NTCP protocol, routers should take all necessary measures to prevent CPU or connection exhaustion. Place limits on maximum active connections and maximum connection setups in progress. Enforce read timeouts (both per-read and total for "slowloris"). Limit repeated or simultaneous connections from the same source. Maintain blacklists for sources that repeatedly fail. - Do not respond to AEAD failure. + Do not respond to AEAD failure. Alternatively, respond with a Retry message + before the DH operation and AEAD validation. - "ver" field: The overall Noise protocol, extensions, and SSU2 protocol including payload specifications, indicating SSU2. This field may be used to indicate support for future changes. - The network ID field is used to quickly identify cross-network connections. - If this field is nonzero, and does not match Bob's network ID, + If this field is does not match Bob's network ID, Bob should disconnect and block future connections. - Bob must drop the message if the Source Connection ID equals @@ -4508,12 +4519,17 @@ total more than that, the requirement is met with only those two blocks. Notes ````` -- To limit the magnitude of any amplification attack that can be mounted using spoofed source addresses, - the Retry message must not contain large amounts of padding. - It is recommended that the Retry message be no larger than three times the size - of the message it is responding to. - Alternatively, use a simple method such as adding a random amount of padding - in the range 1-64 bytes. +- To provide probing resistance, a router should not send a Retry message + in response to a Session Request or Token Request message unless the + message type, protocol version, and network ID fields in the Request message + are valid. + +- To limit the magnitude of any amplification attack that can be mounted using spoofed source addresses, + the Retry message must not contain large amounts of padding. + It is recommended that the Retry message be no larger than three times the size + of the message it is responding to. + Alternatively, use a simple method such as adding a random amount of padding + in the range 1-64 bytes. KDF for Token Request @@ -4634,6 +4650,11 @@ The minimum payload size is 8 bytes. Notes ````` +- To provide probing resistance, a router should not send a Retry message + in response to a Token Request message unless the + message type, protocol version, and network ID fields in the Token Request message + are valid. + - This is NOT a standard Noise message and is not part of the handshake. It is not bound to the Session Request message other than by connection IDs.