diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index af686ea2..be69cee0 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -280,7 +280,7 @@ all cryptographic functions defined in this specification. The offline DPI does not have the ability to block existing connections. The offline DPI does have the capability to do near-realtime (within minutes of -setup) sending to host/port of parties, for example TCP RST. The offline DPI +setup) sending to host/port of parties by packet injection. The offline DPI does have the capability to do near-realtime (within minutes of setup) replay of previous messages (modified or not) for "probing" or other reasons. @@ -2108,22 +2108,106 @@ channels, such as the timing of packets. Relay Security ---------------- -Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch +Following is an analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch. -SSU 1 and 2 TBD +Constraints: It is important that Relays be fast. +Round trips should be minimized. +Bandwidth and CPU are not as important. +SSU 1: +Alice first connects to introducer Bob, who relays the request to Charlie. +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 ------------------------------------------> +{% endhighlight %} + +Authentication: Relay Request and Relay Response are generally unauthenticated, +as Alice and Bob usually do not have an existing session. +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, +so it is presumed secure. + +Bob may spoof Relay Intros or change IP/port from the Relay Request. +There are no mechanisms to cryptographically bind requests to intros or +otherwise prevent or detect malicious Bobs. + +Bob's router hash is not currently published in Charlie's Router Info, so +that must be added if we want the Alice-Bob messages to be authenticated. +Additionally, other SSU2 parameters would have to be published in Charlie's Router Info, +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. + +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 protocol defines a challenge field of variable length 0-255 bytes. +The challenge in the Relay Request is passed to Charlie in the Relay Intro. +However, the protocol does not specify how to create, use, or verify the challenge, +and it is unimplemented. + Peer Test Security --------------------- -Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch +Following is an analysis of Peer Test. -SSU 1 and 2 TBD +Constraints: It is not particularly important that Peer Tests be fast, +or low-bandwidth, or low-CPU, except perhaps at router startup, +where we prefer that the router discovers its reachability fairly quickly. +SSU 1: + +.. raw:: HTTP/1.1 200 OK X-Frame-Options: SAMEORIGIN Date: Wed, 23 Jul 2025 10:55:04 GMT Content-Type: text/plain; charset=utf-8 Connection: close Transfer-Encoding: chunked Cache-Control: max-age=0, private, must-revalidate, no-transform Set-Cookie: i_like_gitea=c2da2e699709155b; Path=/; HttpOnly; Secure; SameSite=Lax Set-Cookie: _csrf=ZQSVC4PJ4a7MR4l_5vA-6-cxAsc6MTc1MzI2ODEwNDc3NzM4NDAwNw; Path=/; Max-Age=86400; HttpOnly; Secure; SameSite=Lax X-Cache-Status: HIT X-Cache-Age: 0 21f7 diff --git a/i2p2www/spec/proposals/159-ssu2.rst b/i2p2www/spec/proposals/159-ssu2.rst index af686ea2..be69cee0 100644 --- a/i2p2www/spec/proposals/159-ssu2.rst +++ b/i2p2www/spec/proposals/159-ssu2.rst @@ -280,7 +280,7 @@ all cryptographic functions defined in this specification. The offline DPI does not have the ability to block existing connections. The offline DPI does have the capability to do near-realtime (within minutes of -setup) sending to host/port of parties, for example TCP RST. The offline DPI +setup) sending to host/port of parties by packet injection. The offline DPI does have the capability to do near-realtime (within minutes of setup) replay of previous messages (modified or not) for "probing" or other reasons. @@ -2108,22 +2108,106 @@ channels, such as the timing of packets. Relay Security ---------------- -Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch +Following is an analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch. -SSU 1 and 2 TBD +Constraints: It is important that Relays be fast. +Round trips should be minimized. +Bandwidth and CPU are not as important. +SSU 1: +Alice first connects to introducer Bob, who relays the request to Charlie. +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 ------------------------------------------> +{% endhighlight %} + +Authentication: Relay Request and Relay Response are generally unauthenticated, +as Alice and Bob usually do not have an existing session. +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, +so it is presumed secure. + +Bob may spoof Relay Intros or change IP/port from the Relay Request. +There are no mechanisms to cryptographically bind requests to intros or +otherwise prevent or detect malicious Bobs. + +Bob's router hash is not currently published in Charlie's Router Info, so +that must be added if we want the Alice-Bob messages to be authenticated. +Additionally, other SSU2 parameters would have to be published in Charlie's Router Info, +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. + +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 protocol defines a challenge field of variable length 0-255 bytes. +The challenge in the Relay Request is passed to Charlie in the Relay Intro. +However, the protocol does not specify how to create, use, or verify the challenge, +and it is unimplemented. + Peer Test Security --------------------- -Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch +Following is an analysis of Peer Test. -SSU 1 and 2 TBD +Constraints: It is not particularly important that Peer Tests be fast, +or low-bandwidth, or low-CPU, except perhaps at router startup, +where we prefer that the router discovers its reachability fairly quickly. +SSU 1: + +.. raw:: 0