kytv/I2P_Website
1
0
Fork 0
forked from I2P_Developers/i2p.www
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Prop. 159 more updates

Browse Source
This commit is contained in:
zzz
2022-02-19 11:23:12 -05:00
parent 10e298b1ef
commit f410760bdc
1 changed files with 46 additions and 25 deletions
Download Patch File Download Diff File Expand all files Collapse all files

71
i2p2www/spec/proposals/159-ssu2.rst
View File

@@ -5,7 +5,7 @@ SSU2
:author: eyedeekay, orignal, zlatinb, zzz :author: eyedeekay, orignal, zlatinb, zzz
:created: 2021-09-12 :created: 2021-09-12
:thread: http://zzz.i2p/topics/2612 :thread: http://zzz.i2p/topics/2612
:lastupdated: 2022-02-18 :lastupdated: 2022-02-19
:status: Open :status: Open
:target: 0.9.55 :target: 0.9.55
@@ -2654,18 +2654,18 @@ ciphertexts.
The following messages are defined: The following messages are defined:
==== ================ ===== ==== ================ ============= =============
Type Message Notes Type Message Header Length Header Encr. Length
==== ================ ===== ==== ================ ============= =============
0 SessionRequest 0 SessionRequest 32 64
1 SessionCreated 1 SessionCreated 32 64
2 SessionConfirmed 2 SessionConfirmed 16 16
6 Data 6 Data 16 16
7 PeerTest 7 PeerTest 32 32
9 Retry 9 Retry 32 32
10 Token Request 10 Token Request 32 32
n/a HolePunch 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. 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 If Bob has issues with his NAT or packet routing, it is probably
better to let the connection fail. 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. 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 // take the next-to-last 12 bytes of the packet
iv = packet[len-24:len-13] 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} data = {0, 0, 0, 0, 0, 0, 0, 0}
mask = ChaCha20.encrypt(k_header_1, iv, data) mask = ChaCha20.encrypt(k_header_1, iv, data)
@@ -3065,7 +3066,7 @@ Header Encryption KDF
// take the last 12 bytes of the packet // take the last 12 bytes of the packet
iv = packet[len-12:len-1] 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} data = {0, 0, 0, 0, 0, 0, 0, 0}
mask = ChaCha20.encrypt(k_header_2, iv, data) 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]) 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} iv = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0}
// encrypt the third part of the header // 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 - The unique X value in the initial ChaCha20 block ensure that the ciphertext is
different for every session. 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 - 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 current time. Call the maximum delta time "D". Bob must maintain a local
cache of previously-used handshake values and reject duplicates, to prevent cache of previously-used handshake values and reject duplicates, to prevent
@@ -3553,24 +3559,29 @@ Notes
(Distribution to be determined, see Appendix A.) (Distribution to be determined, see Appendix A.)
TODO UNLESS minimum packet size is enforced for PMTU. 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 validation failure, Bob must halt further message processing and
drop the message without responding. 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, - 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. routers should take all necessary measures to prevent CPU or connection exhaustion.
Place limits on maximum active connections and maximum connection setups in progress. Place limits on maximum active connections and maximum connection setups in progress.
Enforce read timeouts (both per-read and total for "slowloris"). Enforce read timeouts (both per-read and total for "slowloris").
Limit repeated or simultaneous connections from the same source. Limit repeated or simultaneous connections from the same source.
Maintain blacklists for sources that repeatedly fail. 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 - "ver" field: The overall Noise protocol, extensions, and SSU2 protocol
including payload specifications, indicating SSU2. including payload specifications, indicating SSU2.
This field may be used to indicate support for future changes. This field may be used to indicate support for future changes.
- The network ID field is used to quickly identify cross-network connections. - 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 should disconnect and block future connections.
- Bob must drop the message if the Source Connection ID equals - 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 Notes
````` `````
- To limit the magnitude of any amplification attack that can be mounted using spoofed source addresses, - To provide probing resistance, a router should not send a Retry message
the Retry message must not contain large amounts of padding. in response to a Session Request or Token Request message unless the
It is recommended that the Retry message be no larger than three times the size message type, protocol version, and network ID fields in the Request message
of the message it is responding to. are valid.
Alternatively, use a simple method such as adding a random amount of padding
in the range 1-64 bytes. - 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 KDF for Token Request
@@ -4634,6 +4650,11 @@ The minimum payload size is 8 bytes.
Notes 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. - 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. It is not bound to the Session Request message other than by connection IDs.