diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index a19efe04..0383fed6 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -81,7 +81,7 @@ Design Goals implementation-dependent and may or may not be specified in the protocol itself. -- Obfuscate the contents of messages that aren't encrypted (Session Created and Confirmed), +- Obfuscate the contents of messages that aren't fully encrypted (Session Created and Confirmed), sufficiently so that DPI boxes and AV signatures can't easily classify them. Also ensure that the messages going to a single peer or set of peers do not have a similar pattern of bits. @@ -124,6 +124,9 @@ Design Goals - Maintain a max I2NP message size of approximately 32K, as in SSU. Increase to 64 KB? TBD +- Remove IP and port fields from the handshake, so that routers that don't know + their external IP and port will be able to connect. + - Include representatives of Java, C++, and Go router developers in the design. @@ -294,6 +297,7 @@ Address Validation --------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to @@ -774,6 +778,8 @@ Connection Migration ---------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. + The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an @@ -1213,27 +1219,18 @@ on any path. Use of IPv6 Flow Label and Migration `````````````````````````````````````````` -Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label -in compliance with [RFC6437], unless the local API does not allow +QUIC recommends endpoints that send data using IPv6 SHOULD apply an IPv6 flow label +in compliance with [RFC6437]_, unless the local API does not allow setting IPv6 flow labels. -The flow label generation MUST be designed to minimize the chances of -linkability with a previously used flow label, as a stable flow label -would enable correlating activity on multiple paths; see Section 9.5. - -[RFC6437] suggests deriving values using a pseudorandom function to -generate flow labels. Including the Destination Connection ID field -in addition to source and destination addresses when generating flow -labels ensures that changes are synchronized with changes in other -observable identifiers. A cryptographic hash function that combines -these inputs with a local secret is one way this might be -implemented. +Unfortunately, the Java API does not allow setting IPv6 flow labels. Security Considerations --------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. The goal of QUIC is to provide a secure transport connection. Section 21.1 provides an overview of those properties; subsequent @@ -2108,6 +2105,24 @@ Endpoints might also reveal sensitive information through other side channels, such as the timing of packets. +Relay Security +---------------- + +Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch + +SSU 1 and 2 TBD + + + + +Peer Test Security +--------------------- + +Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch + +SSU 1 and 2 TBD + + @@ -2143,6 +2158,10 @@ for inspiration, guidance, and code reuse: * Messages: Adapted from [SSU]_ +* I2NP Fragmentation: Adapted from [SSU]_ + +* Relay HTTP/1.1 200 OK Cache-Control: max-age=0, private, must-revalidate, no-transform Set-Cookie: i_like_gitea=4223694aeca7e11c; Path=/; HttpOnly; Secure; SameSite=Lax Set-Cookie: _csrf=feNNQl83jcoVLdLoFOiFyWKtbiI6MTc1MzI1NDc2MzE2NTcyMTM4MA; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax X-Frame-Options: SAMEORIGIN Date: Wed, 23 Jul 2025 07:12:43 GMT Content-Type: text/plain; charset=utf-8 Connection: close Transfer-Encoding: chunked X-Cache-Status: HIT X-Cache-Age: 0 38bf diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index a19efe04..0383fed6 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -81,7 +81,7 @@ Design Goals implementation-dependent and may or may not be specified in the protocol itself. -- Obfuscate the contents of messages that aren't encrypted (Session Created and Confirmed), +- Obfuscate the contents of messages that aren't fully encrypted (Session Created and Confirmed), sufficiently so that DPI boxes and AV signatures can't easily classify them. Also ensure that the messages going to a single peer or set of peers do not have a similar pattern of bits. @@ -124,6 +124,9 @@ Design Goals - Maintain a max I2NP message size of approximately 32K, as in SSU. Increase to 64 KB? TBD +- Remove IP and port fields from the handshake, so that routers that don't know + their external IP and port will be able to connect. + - Include representatives of Java, C++, and Go router developers in the design. @@ -294,6 +297,7 @@ Address Validation --------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. Address validation ensures that an endpoint cannot be used for a traffic amplification attack. In such an attack, a packet is sent to @@ -774,6 +778,8 @@ Connection Migration ---------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. + The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an @@ -1213,27 +1219,18 @@ on any path. Use of IPv6 Flow Label and Migration `````````````````````````````````````````` -Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label -in compliance with [RFC6437], unless the local API does not allow +QUIC recommends endpoints that send data using IPv6 SHOULD apply an IPv6 flow label +in compliance with [RFC6437]_, unless the local API does not allow setting IPv6 flow labels. -The flow label generation MUST be designed to minimize the chances of -linkability with a previously used flow label, as a stable flow label -would enable correlating activity on multiple paths; see Section 9.5. - -[RFC6437] suggests deriving values using a pseudorandom function to -generate flow labels. Including the Destination Connection ID field -in addition to source and destination addresses when generating flow -labels ensures that changes are synchronized with changes in other -observable identifiers. A cryptographic hash function that combines -these inputs with a local secret is one way this might be -implemented. +Unfortunately, the Java API does not allow setting IPv6 flow labels. Security Considerations --------------------------- Following is copied from QUIC [RFC-9000]_. +For each section, review and edit. The goal of QUIC is to provide a secure transport connection. Section 21.1 provides an overview of those properties; subsequent @@ -2108,6 +2105,24 @@ Endpoints might also reveal sensitive information through other side channels, such as the timing of packets. +Relay Security +---------------- + +Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch + +SSU 1 and 2 TBD + + + + +Peer Test Security +--------------------- + +Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch + +SSU 1 and 2 TBD + + @@ -2143,6 +2158,10 @@ for inspiration, guidance, and code reuse: * Messages: Adapted from [SSU]_ +* I2NP Fragmentation: Adapted from [SSU]_ + +* Relay 0