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:: html + + {% highlight %} +Alice Bob Charlie + 1. PeerTest -------------------> + 2. PeerTest--------------------> + 3. <-------------------PeerTest + 4. <-------------------PeerTest + 5. <------------------------------------------PeerTest + 6. PeerTest------------------------------------------> + 7. <------------------------------------------PeerTest +{% endhighlight %} + + +Authentication: +As of 0.9.15, Alice will always choose a Bob with an existing session. +The protocol also permits Bob's introKey if Alice and Bob do not have an established session, +but in the current implementation Alice always selects a Bob that is established. +As of release 0.9.15, Bob will reject PeerTests from peers without an established session. +Message 1 is sent in-session. Therefore, message 1 is authenticated. + +Bob selects a Charlie with whom he has an existing session. +Messages 2 and 3 are sent in-session. Therefore, messages 2 and 3 are authenticated. + +Message 4 should be sent in-session; however, the documents say that it is sent +with Alice's intro key, which means not in-session. +To be investigated. + +Alice must not have an existing session with Charlie for the test to proceed; +Alice aborts the test if Bob picks a Charlie that has a sesssion with Alice. +Therefore, messages 5-7 are unauthenticated. + +All Peer Test messages contain a 4-byte nonce that is chosen by Alice. +This nonce is not used cryptographically. + +Attacks possible on messages 5-7: to be researched. Design Overview @@ -3018,11 +3102,8 @@ Notes (Distribution to be determined, see Appendix A.) - On any error, including AEAD, DH, timestamp, apparent replay, or key - validation failure, Bob must halt further message processing and close the - connection without responding. This should be an abnormal close (TCP RST). - For probing resistance, after an AEAD failure, Bob should - set a random timeout (range TBD) and then read a random number of bytes (range TBD), - before closing the socket. + validation failure, Bob must halt further message processing and + drop the message without responding. - 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. @@ -3032,17 +3113,6 @@ Notes Maintain blacklists for sources that repeatedly fail. Do not respond to AEAD failure. -- To facilitate rapid version detection and handshaking, implementations must - ensure that Alice buffers and then flushes the entire contents of the first - message at once, including the padding. This increases the likelihood that - the data will be contained in a single TCP packet (unless segmented by the OS - or middleboxes), and received all at once by Bob. Additionally, - implementations must ensure that Bob buffers and then flushes the entire - contents of the second message at once, including the padding. and that Bob - buffers and then flushes the entire contents of the third message at once. - This is also for efficiency and to ensure the effectiveness of the random - padding. - - "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. @@ -3630,15 +3700,7 @@ XK(s, rs): Authentication Confidentiality Notes ````` -- For efficiency and to minimize identification of the length field, - implementations must ensure that the sender buffers and then flushes the entire contents - of data messages at once, including the length field and the AEAD payload. - This increases the likelihood that the data will be contained in a single TCP packet - (unless segmented by the OS or middleboxes), and received all at once the other party. - This is also for efficiency and to ensure the effectiveness of the random padding. - -- The router may choose to terminate the session on AEAD error, or may continue to attempt communications. - If continuing, the router should terminate after repeated errors. +- The router must drop a message AEAD error. .. raw:: html @@ -3799,7 +3861,7 @@ sequence. Noise Payload =============== -All noise sections contain zero or more "blocks". +Each Noise payload contains zero or more "blocks". This uses the same block format as defined in the [NTCP2]_ and [ECIES]_ specifications. Individual block types are defined differently. @@ -4218,7 +4280,7 @@ This must be the last non-padding block in the payload. Notes ````` Not all reasons may actually be used, implementation dependent. -Handshake failures will generally result in a close with TCP RST instead. +Most failures will generally result in the message being dropped, not a termination. See notes in handshake message sections above. Additional reasons listed are for consistency, logging, debugging, or if policy changes.