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

Prop. 159 relay

Browse Source
This commit is contained in:
zzz
2022-02-17 05:57:14 -05:00
parent a59293d378
commit b082cd333c
1 changed files with 203 additions and 104 deletions
Download Patch File Download Diff File Expand all files Collapse all files

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

@ -5,7 +5,7 @@ SSU2
:author: eyedeekay, orignal, zlatinb, zzz
:created: 2021-09-12
:thread: http://zzz.i2p/topics/2612
:lastupdated: 2022-02-16
:lastupdated: 2022-02-17
:status: Open
:target: 0.9.55
@ -2631,12 +2631,8 @@ Type Message Notes
0 SessionRequest
1 SessionCreated
2 SessionConfirmed
3 RelayRequest TBD may be a block
4 RelayResponse TBD may be a block
5 RelayIntro NO, block only
6 Data
7 PeerTest
8 SessionDestroyed NO, block only??
9 Retry
10 Token Request
n/a HolePunch
@ -4060,12 +4056,6 @@ This is the split() function, exactly as defined in the Noise spec.
Relay Messages (Types 3-5)
------------------------------
TBD, only required if these must be sent outside of an existing session.
Data Message (Type 6)
---------------------------
@ -4279,12 +4269,6 @@ totals more than that, the requirement is met with only this block.
Session Destroyed (Type 8)
-------------------------------
TBD, only required if these must be sent outside of an existing session.
KDF for Retry
----------------
@ -4614,8 +4598,7 @@ Notes:
overrun into the next block or beyond the payload boundary.
- Implementations should ignore unknown block types for
forward compatibility, except in Session Confirmed part 2, where
unknown blocks are not allowed.
forward compatibility.
@ -4631,9 +4614,9 @@ I2NP Message 3 varies
First Fragment 4 varies
Follow-on Fragment 5 varies
Termination (TBD) 6 9 typ.
Relay Request 7 TBD
Relay Response 8 TBD
Relay Intro 9 TBD
Relay Request 7 varies
Relay Response 8 9
Relay Intro 9 varies
Peer Test 10 varies
Next Nonce 11 TBD
ACK 12 varies
@ -5034,50 +5017,56 @@ Additional reasons listed are for consistency, logging, debugging, or if policy
RelayRequest
``````````````
TODO this is the SSU 1 flavor, to be updated
Sent in a Data message in-session, from Alice to Bob.
See Relay Process section below.
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| 7 | size | relay tag | asz|
| 7 | size |flag| nonce |
+----+----+----+----+----+----+----+----+
| Alice IP address | APort | csz| |
+----+----+----+----+----+----+----+ +
| challenge to be delivered to Charlie |
+ +
| |
| relay tag | timestamp |
+----+----+----+----+----+----+----+----+
| Alice's intro key |
+ +
| |
+ +
| |
+ +
| |
| ver| asz| Alice IP address |AlicePort|
+----+----+----+----+----+----+----+----+
| signature |
+ length varies +
| 64 bytes for Ed25519 |
~ ~
| . . . |
+----+----+----+----+----+----+----+----+
| nonce |
+----+----+----+----+
blk :: 7
size :: 2 bytes, big endian, size of data to follow
relay tag :: 4 byte relay (introduction) tag, nonzero, as received by
Alice in the SessionCreated message from Bob
asz :: 1 byte IP address size
Alice IP :: Alice's IP address, network byte order, asz bytes
APort :: 2 byte port number of Alice, network byte order
csz :: 1 byte challenge size
challenge :: if csz is nonzero, that many bytes to be relayed to Charlie in the intro
intro : Alice's 32-byte introduction key (so Bob can reply with
Charlie's info)
nonce :: 4 byte nonce of Alice's relay request
flag :: 1 byte flags, Unused, set to 0 for future compatibility
nonce :: 4 bytes, randomly generated by Alice
The data below here is covered
by the signature, and Bob forwards it unmodified.
relay tag :: 4 bytes, the itag from Charlie's RI
timestamp :: Unix timestamp, unsigned seconds.
Wraps around in 2106
ver:: 1 byte SSU version to be used for the introduction:
1: SSU 1
2: SSU 2
asz :: 1 byte IP address size (4 or 16)
Alice IP :: asz byte representation of Alice's IP address,
network byte order
AlicePort :: 2 byte Alice's port number, big endian
signature :: length varies, 64 bytes for Ed25519.
Signature of prologue, Bob's hash,
and signed data above, as signed by
Alice.
{% endhighlight %}
Notes:
* The IP address is only included if it is be different than the packet's
source address and port.
* The IP address is always included (unlike in SSU 1)
and may be different than the IP used for the session.
* This message may be sent via IPv4 or IPv6.
If the message is over IPv6 for an IPv4 introduction,
@ -5085,93 +5074,105 @@ Notes:
Alice must include her introduction address and port.
This is supported as of release 0.9.50.
* If Alice includes her address/port, Bob may perform additional validation
before continuing.
* Challenge is unimplemented, challenge size is always zero
* Relaying for IPv6 is supported as of release 0.9.50.
* Prior to release 0.9.12, Bob's intro key was always used. As of release
0.9.12, the session key is used if there is an established session between
Alice and Bob. In practice, there must be an established session, as Alice
will only get the nonce (introduction tag) from the session created message,
and Bob will mark the introduction tag invalid once the session is destroyed.
RelayResponse
``````````````
TODO this is the SSU 1 flavor, to be updated
Sent in a Data message in-session, from Charlie to Bob
or from Bob to Alice.
See Relay Process section below.
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| 8 | size | csz| Charlie IP |
| 8 | size |flag| nonce |
+----+----+----+----+----+----+----+----+
| CPort | asz| Alice IP |Aprt
+----+----+----+----+----+----+----+----+
Aprt| nonce |
+----+----+----+----+----+
|code|
+----+
blk :: 8
size :: 2 bytes, big endian, size of data to follow
csz :: 1 byte Charlie IP address size
Charlie IP :: Charlie's IP address, network byte order, csz bytes
CPort :: 2 byte Charlie's port number, network byte order
asz :: 1 byte Alice IP address size
Alice IP :: Alice's IP address, network byte order, asz bytes
Aprt :: 2 byte Alice's port number, network byte order
nonce :: 4 byte nonce sent by Alice
size :: 2 bytes, 6
flag :: 1 byte flags, Unused, set to 0 for future compatibility
nonce :: 4 bytes, as received from Bob or Alice
code:: 1 byte status code:
0: accept
1: reject, reason unspecified
2: rejected by Bob, reason unspecified
3: rejected by Charlie, reason unspecified
4-255: other reject codes TBD
{% endhighlight %}
Notes:
* This message may be sent via IPv4 or IPv6.
* Alice's IP address/port are the apparent IP/port that Bob received the
RelayRequest on (not necessarily the IP Alice included in the RelayRequest),
and may be IPv4 or IPv6. Alice currently ignores these on receive.
* Charlie's IP address may be IPv4, or, as of release 0.9.50, IPv6.
as that is the address that Alice will
send the SessionRequest to after the Hole Punch.
* Relaying for IPv6 is supported as of release 0.9.50.
* Prior to release 0.9.12, Alice's intro key was always used. As of release
0.9.12, the session key is used if there is an established session between
Alice and Bob.
RelayIntro
``````````````
TODO this is the SSU 1 flavor, to be updated
Sent in a Data message in-session, from Bob to Charlie.
See Relay Process section below.
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| 9 | size | asz| Alice IP |
| 9 | size |flag| nonce |
+----+----+----+----+----+----+----+----+
| relay tag | timestamp |
+----+----+----+----+----+----+----+----+
| APort | csz| |
+----+----+----+ +
| that many bytes of challenge |
+ +
| data relayed from Alice |
~ . . . ~
| |
+ +
| Alice Router Hash |
+ 32 bytes +
| |
+ +
| |
+----+----+----+----+----+----+----+----+
| ver| asz| Alice IP address |AlicePort|
+----+----+----+----+----+----+----+----+
| signature |
+ length varies +
| 64 bytes for Ed25519 |
~ ~
| . . . |
+----+----+----+----+----+----+----+----+
blk :: 9
size :: 2 bytes, big endian, size of data to follow
flag :: 1 byte flags, Unused, set to 0 for future compatibility
nonce :: 4 bytes, randomly generated by Bob,
or may be the same as the nonce received from Alice
hash :: Alice's 32-byte router hash,
The data below here is covered
by the signature, as received from Alice in the Relay Request,
and Bob forwards it unmodified.
relay tag :: 4 bytes, the itag from Charlie's RI
timestamp :: Unix timestamp, unsigned seconds.
Wraps around in 2106
ver:: 1 byte SSU version to be used for the introduction:
1: SSU 1
2: SSU 2
asz :: 1 byte IP address size (4 or 16)
Alice IP :: asz byte representation of Alice's IP address,
network byte order
AlicePort :: 2 byte Alice's port number, big endian
signature :: length varies, 64 bytes for Ed25519.
Signature of prologue, Bob's hash,
and signed data above, as signed by
Alice.
{% endhighlight %}
Notes:
* For IPv4, Alice's IP address is always 4 bytes, because Alice is trying to connect to Charlie via IPv4.
@ -5187,8 +5188,6 @@ Notes:
* As of release 0.9.50, any SSU address published with introducers must contain "4" or "6" in the "caps" option.
* Challenge is unimplemented, challenge size is always zero
PeerTest
``````````````
@ -6328,7 +6327,7 @@ Message Path Intro Key
Cross-version relaying and peer testing should also be supported if possible.
Cross-version peer testing should also be supported if possible.
This will facilitate a gradual transition from SSU 1 to SSU 2.
The allowed version combinations are (TODO):
@ -6351,6 +6350,106 @@ Peer Test blocks are ack-eliciting.
Messages 5-7 may be retransmitted, unchanged.
Relay Process
========================
See Relay Security above for an analysis of SSU1 Relay and
the goals for SSU2 Relay.
.. raw:: html
{% highlight %}
Alice Bob Charlie
lookup Bob RI
SessionRequest -------------------->
<------------ SessionCreated
SessionConfirmed ----------------->
1. RelayRequest ---------------------->
Alice RI ------------>
2. RelayIntro ----------->
3. <-------------- RelayResponse
4. <-------------- RelayResponse
5. <-------------------------------------------- HolePunch
6. SessionRequest -------------------------------------------->
7. <-------------------------------------------- SessionCreated
8. SessionConfirmed ------------------------------------------>
{% endhighlight %}
When rejected by Bob:
.. raw:: html
{% highlight %}
Alice Bob Charlie
lookup Bob RI
SessionRequest -------------------->
<------------ SessionCreated
SessionConfirmed ----------------->
1. RelayRequest ---------------------->
4. <-------------- RelayResponse
{% endhighlight %}
When rejected by Charlie:
.. raw:: html
{% highlight %}
Alice Bob Charlie
lookup Bob RI
SessionRequest -------------------->
<------------ SessionCreated
SessionConfirmed ----------------->
1. RelayRequest ---------------------->
Alice RI ------------>
2. RelayIntro ----------->
3. <-------------- RelayResponse
4. <-------------- RelayResponse
{% endhighlight %}
In SSU 1, Charlie's router info contains the IP, port, intro key, relay tag, and expiration of each introducer.
In SSU 2, Charlie's router info contains the router hash, relay tag, and expiration of each introducer.
Cross-version relaying should also be supported if possible.
This will facilitate a gradual transition from SSU 1 to SSU 2.
The allowed version combinations are (TODO):
========= =========== ============= =============
Alice/Bob Bob/Charlie Alice/Charlie Supported
========= =========== ============= =============
1 1 2 no, use 1/1/1
1 2 1 yes?
1 2 2 no, use 1/2/1
2 1 2 yes?
2 2 1 no, use 2/2/2
2 2 2 yes
========= =========== ============= =============
Retransmissions: Relay Request, Relay Intro, and Relay Response
are all in-session and are covered by the
data phase ACK and retransmission processes.
Relay Request, Relay Intro, and Relay Response blocks are ack-eliciting.
Hole punch may be retransmitted, as in SSU 1.
Published Router Info
=====================