forked from I2P_Developers/i2p.www
prop. 159 relay and peer test goals
This commit is contained in:
@@ -5,7 +5,7 @@ SSU2
|
|||||||
:author: orignal, zlatinb, zzz
|
:author: orignal, zlatinb, zzz
|
||||||
:created: 2021-09-12
|
:created: 2021-09-12
|
||||||
:thread: http://zzz.i2p/topics/2612
|
:thread: http://zzz.i2p/topics/2612
|
||||||
:lastupdated: 2021-10-19
|
:lastupdated: 2021-10-21
|
||||||
:status: Open
|
:status: Open
|
||||||
:target: 0.9.55
|
:target: 0.9.55
|
||||||
|
|
||||||
@@ -22,13 +22,13 @@ resistance of [SSU]_ to various forms of automated identification and attacks.
|
|||||||
The proposal is organized as follows: the security goals are presented,
|
The proposal is organized as follows: the security goals are presented,
|
||||||
followed by a discussion of the basic protocol. Next, a complete specification
|
followed by a discussion of the basic protocol. Next, a complete specification
|
||||||
of all protocol messages is given. Finally, router addresses and version
|
of all protocol messages is given. Finally, router addresses and version
|
||||||
identification are discussed. An appendix discussing a generic attack on common
|
identification are discussed.
|
||||||
padding schemes is also included, as well as an appendix containing a number of
|
|
||||||
candidates for the authenticated cipher.
|
|
||||||
|
|
||||||
As with other I2P transports, SSU2 is defined solely
|
As with other I2P transports, SSU2 is defined
|
||||||
for point-to-point (router-to-router) transport of I2NP messages.
|
for point-to-point (router-to-router) transport of I2NP messages.
|
||||||
It is not a general-purpose data pipe.
|
It is not a general-purpose data pipe.
|
||||||
|
Like [SSU]_, it also provides two additional services:
|
||||||
|
Relaying for NAT traversal, and Peer Testing for determination of inbound reachability.
|
||||||
|
|
||||||
|
|
||||||
Motivation
|
Motivation
|
||||||
@@ -109,7 +109,9 @@ Design Goals
|
|||||||
|
|
||||||
- Add message authentication (MAC) using ChaCha/Poly1305.
|
- Add message authentication (MAC) using ChaCha/Poly1305.
|
||||||
|
|
||||||
- Use a 3-message, one-round-trip handshake, as in [NTCP2]_ and [SSU]_.
|
- Use a 3-message, one-round-trip handshake, as in [NTCP2]_.
|
||||||
|
Remove the delay waiting for data messages that makes
|
||||||
|
[SSU]_ effectively a two-round-trip handshake.
|
||||||
|
|
||||||
- Minimize protocol overhead before padding. While padding will be added,
|
- Minimize protocol overhead before padding. While padding will be added,
|
||||||
overhead before padding is still overhead.
|
overhead before padding is still overhead.
|
||||||
@@ -2247,6 +2249,73 @@ Four byte nonce may need to be replaced or supplemented by
|
|||||||
8-byte connection ID.
|
8-byte connection ID.
|
||||||
|
|
||||||
|
|
||||||
|
Relay and Peer Test Design Goals
|
||||||
|
---------------------------------
|
||||||
|
|
||||||
|
Relay and Peer Test have similar constructions.
|
||||||
|
In both cases, Alice requests Bob to forward a service request to Charlie,
|
||||||
|
and Charlie then acts on that request.
|
||||||
|
|
||||||
|
We have the following goals in improving the security of Relay and Peer Test:
|
||||||
|
|
||||||
|
- Protect against address spoofing or on-path threats that may
|
||||||
|
spoof, alter, forge, or replay requests from Alice to Bob.
|
||||||
|
Bob must ensure that Alice is an actual I2P router and that the
|
||||||
|
request and test address presented are valid.
|
||||||
|
|
||||||
|
- Protect against malicious Bobs that may spoof, alter, forge, or replay
|
||||||
|
requests forwarded to Charlie.
|
||||||
|
Charlie must ensure that both Alice and Bob are actual I2P routers and that the
|
||||||
|
request and test address presented are valid.
|
||||||
|
|
||||||
|
- Bob must receive enough information from Alice to be able to validate
|
||||||
|
the request and then accept or decline it.
|
||||||
|
Bob must have a mechanism to send the acception or rejection back
|
||||||
|
to Alice.
|
||||||
|
Bob must never be required to perform the requested action.
|
||||||
|
|
||||||
|
- Charlie must receive enough information from Bob to be able to validate
|
||||||
|
the request and then accept or decline it.
|
||||||
|
Charlie must have a mechanism to send the acception or rejection back
|
||||||
|
to Bob, to be forwarded to Alice.
|
||||||
|
Charlie must never be required to perform the requested action.
|
||||||
|
|
||||||
|
- Alice must be able to validate that the response forwarded via Bob
|
||||||
|
actually originated from Charlie.
|
||||||
|
|
||||||
|
- Alice and Charlie must be able to validate that their subsequent direct
|
||||||
|
messages (not relayed via Bob) are from the expected source
|
||||||
|
and are actual I2P routers.
|
||||||
|
|
||||||
|
|
||||||
|
The following mechanisms may assist in achieving these goals:
|
||||||
|
|
||||||
|
- Timestamps
|
||||||
|
|
||||||
|
- Signatures using the router signing key
|
||||||
|
|
||||||
|
- Using challenge data included in the request
|
||||||
|
|
||||||
|
- Encryption using the router encryption key
|
||||||
|
|
||||||
|
- Sending router hashes, Router Identities, or Router Infos,
|
||||||
|
not just IPs and ports.
|
||||||
|
|
||||||
|
- Validation of router information by querying the network database
|
||||||
|
|
||||||
|
- Checking router information, IPs, and ports against banlists
|
||||||
|
|
||||||
|
- Rate limiting
|
||||||
|
|
||||||
|
- Requiring session establishment
|
||||||
|
|
||||||
|
|
||||||
|
These possible mechanisms may increase the processing time and latency of
|
||||||
|
the Relay or Peer Test functions. All effects must be evaluated.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
Design Overview
|
Design Overview
|
||||||
====================
|
====================
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user