From 79f3bc3290cff13d731b60005666b05da1049c34 Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 18 Oct 2021 09:58:42 -0400 Subject: [PATCH] Update prop. 159 --- i2p2www/spec/proposals/159-ssu2.rst | 130 ++++++++++++++++++---------- 1 file changed, 85 insertions(+), 45 deletions(-) diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index be69cee0..a9e0453b 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -5,7 +5,7 @@ SSU2 :author: orignal, zlatinb, zzz :created: 2021-09-12 :thread: http://zzz.i2p/topics/2612 - :lastupdated: 2021-10-17 + :lastupdated: 2021-10-18 :status: Open :target: 0.9.55 @@ -2116,23 +2116,24 @@ Bandwidth and CPU are not as important. SSU 1: -Alice first connects to introducer Bob, who relays the request to Charlie. +Alice first connects to introducer Bob, who relays the request to Charlie (who is firewalled). After the hole punch, the session is established between Alice and Charlie as in a direct establishment. .. raw:: html {% highlight %} Alice Bob Charlie - RelayRequest ----------------------> - <-------------- RelayResponse RelayIntro -----------> - <-------------------------------------------- HolePunch (data ignored) - SessionRequest --------------------------------------------> - <-------------------------------------------- SessionCreated - SessionConfirmed ------------------------------------------> + 1. RelayRequest ----------------------> + 2. <-------------- RelayResponse RelayIntro -----------> + 3. <-------------------------------------------- HolePunch + 4. SessionRequest --------------------------------------------> + 5. <-------------------------------------------- SessionCreated + 6. SessionConfirmed ------------------------------------------> {% endhighlight %} -Authentication: Relay Request and Relay Response are generally unauthenticated, -as Alice and Bob usually do not have an existing session. +Authentication: Relay Request and Relay Response are not securely unauthenticated, +as Alice and Bob usually do not have an existing session; +these messages use published intro keys. In-session Relay Request/Response is allowed and preferred if a session does exist. Relay Intro from Bob to Charlie is required to be in an existing session, @@ -2149,14 +2150,34 @@ or Alice would have to lookup Bob's Router Info in the network database, adding additional delay. Authentication would add a round-trip between Alice and Bob. +By forwarding Alice's router hash to Charlie, Charlie could more easily +determine if he wishes to receive a connection from Alice, +by checking a local ban list. +There is no mechanism for Charlie to reject the relay by sending +a rejection through Bob to Alice. +There is no mechanism for Charlie to accept the relay by sending +an acceptance through Bob to Alice. Alice must wait for the HolePunch, +or simply send the SessionRequest blindly. The HolePunch may come from +a different port than Alice was expecting, due to NAT, which +may make it harder to recognize what router the HolePunch came from. + +Alice could send her full Router Info in the Relay Request to Bob, +and forwarded to Charlie in the Relay Intro. + The Relay Request does not contain a timestamp, so it has no replay prevention. The source IP can be spoofed, to cause Charlie to send a Hole Punch to any IP/port. +The Relay Request is not signed, and even if signed and timestamped, +Charlie does not have tHTTP/1.1 200 OK Cache-Control: max-age=0, private, must-revalidate, no-transform Set-Cookie: i_like_gitea=448708a1469bb681; Path=/; HttpOnly; Secure; SameSite=Lax Set-Cookie: _csrf=upwVG_2rkDFtfIKMlKbSAiJSJ2E6MTc1MzI2OTM5OTUyMDU5MDE1Mg; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax X-Frame-Options: SAMEORIGIN Date: Wed, 23 Jul 2025 11:16:39 GMT Content-Type: text/plain; charset=utf-8 Connection: close Transfer-Encoding: chunked X-Cache-Status: HIT X-Cache-Age: 0 2e90 From 79f3bc3290cff13d731b60005666b05da1049c34 Mon Sep 17 00:00:00 2001 From: zzz Date: Mon, 18 Oct 2021 09:58:42 -0400 Subject: [PATCH] Update prop. 159 --- i2p2www/spec/proposals/159-ssu2.rst | 130 ++++++++++++++++++---------- 1 file changed, 85 insertions(+), 45 deletions(-) diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index be69cee0..a9e0453b 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -5,7 +5,7 @@ SSU2 :author: orignal, zlatinb, zzz :created: 2021-09-12 :thread: http://zzz.i2p/topics/2612 - :lastupdated: 2021-10-17 + :lastupdated: 2021-10-18 :status: Open :target: 0.9.55 @@ -2116,23 +2116,24 @@ Bandwidth and CPU are not as important. SSU 1: -Alice first connects to introducer Bob, who relays the request to Charlie. +Alice first connects to introducer Bob, who relays the request to Charlie (who is firewalled). After the hole punch, the session is established between Alice and Charlie as in a direct establishment. .. raw:: html {% highlight %} Alice Bob Charlie - RelayRequest ----------------------> - <-------------- RelayResponse RelayIntro -----------> - <-------------------------------------------- HolePunch (data ignored) - SessionRequest --------------------------------------------> - <-------------------------------------------- SessionCreated - SessionConfirmed ------------------------------------------> + 1. RelayRequest ----------------------> + 2. <-------------- RelayResponse RelayIntro -----------> + 3. <-------------------------------------------- HolePunch + 4. SessionRequest --------------------------------------------> + 5. <-------------------------------------------- SessionCreated + 6. SessionConfirmed ------------------------------------------> {% endhighlight %} -Authentication: Relay Request and Relay Response are generally unauthenticated, -as Alice and Bob usually do not have an existing session. +Authentication: Relay Request and Relay Response are not securely unauthenticated, +as Alice and Bob usually do not have an existing session; +these messages use published intro keys. In-session Relay Request/Response is allowed and preferred if a session does exist. Relay Intro from Bob to Charlie is required to be in an existing session, @@ -2149,14 +2150,34 @@ or Alice would have to lookup Bob's Router Info in the network database, adding additional delay. Authentication would add a round-trip between Alice and Bob. +By forwarding Alice's router hash to Charlie, Charlie could more easily +determine if he wishes to receive a connection from Alice, +by checking a local ban list. +There is no mechanism for Charlie to reject the relay by sending +a rejection through Bob to Alice. +There is no mechanism for Charlie to accept the relay by sending +an acceptance through Bob to Alice. Alice must wait for the HolePunch, +or simply send the SessionRequest blindly. The HolePunch may come from +a different port than Alice was expecting, due to NAT, which +may make it harder to recognize what router the HolePunch came from. + +Alice could send her full Router Info in the Relay Request to Bob, +and forwarded to Charlie in the Relay Intro. + The Relay Request does not contain a timestamp, so it has no replay prevention. The source IP can be spoofed, to cause Charlie to send a Hole Punch to any IP/port. +The Relay Request is not signed, and even if signed and timestamped, +Charlie does not have t 0