I2P_Developers/i2p.www
3
0
Fork 5
Code Issues 27 Pull Requests Actions 1 Packages Projects Releases Wiki Activity

Proposal 159 updates

Browse Source
This commit is contained in:
zzz
2021-10-17 13:15:09 -04:00
parent 3cd54147f2
commit 0754e903f6
1 changed files with 94 additions and 32 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -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.