forked from I2P_Developers/i2p.www
Prop. 159 updates
Peer Test, amplification, RI compression
This commit is contained in:
@ -5,7 +5,7 @@ SSU2
|
||||
:author: eyedeekay, orignal, zlatinb, zzz
|
||||
:created: 2021-09-12
|
||||
:thread: http://zzz.i2p/topics/2612
|
||||
:lastupdated: 2022-03-16
|
||||
:lastupdated: 2022-03-17
|
||||
:status: Open
|
||||
:target: 0.9.55
|
||||
|
||||
@ -2399,9 +2399,9 @@ The possible version combinations are:
|
||||
Alice/Bob Bob/Charlie Alice/Charlie Supported
|
||||
========= =========== ============= =============
|
||||
1 1 2 no, use 1/1/1
|
||||
1 2 1 yes?
|
||||
1 2 1 Relay: yes? Peer Test: no
|
||||
1 2 2 no, use 1/2/1
|
||||
2 1 2 yes?
|
||||
2 1 2 Relay: yes? Peer Test: no
|
||||
2 2 1 no, use 2/2/2
|
||||
2 2 2 yes
|
||||
========= =========== ============= =============
|
||||
@ -4384,7 +4384,7 @@ Unencrypted data (Poly1305 authentication tag not shown):
|
||||
+----+----+----+----+----+----+----+----+
|
||||
|
||||
|
||||
Destination Connection ID :: Randomly generated by Charlie
|
||||
Destination Connection ID :: See below
|
||||
|
||||
type :: 7
|
||||
|
||||
@ -4396,21 +4396,36 @@ Unencrypted data (Poly1305 authentication tag not shown):
|
||||
|
||||
Packet Number :: Random number generated by Alice or Charlie
|
||||
|
||||
Source Connection ID :: Randomly generated by Charlie
|
||||
Source Connection ID :: See below
|
||||
|
||||
Token :: Randomly generated by Charlie, ignored
|
||||
Token :: Randomly generated by ALice or Charlie, ignored
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
Payload
|
||||
```````
|
||||
- DateTime block
|
||||
- Address block
|
||||
- Peer Test block
|
||||
- Padding block (optional)
|
||||
|
||||
The minimum payload size is 8 bytes. Since the Peer Test block
|
||||
totals more than that, the requirement is met with only this block.
|
||||
|
||||
In messages 5 and 7, the Peer Test block is identical to
|
||||
the block from in-session messages 3 and 4,
|
||||
containing the agreement signed by Charlie.
|
||||
|
||||
In message 6, the Peer Test block is identical to
|
||||
the block from in-session messages 1 and 2,
|
||||
containing the request signed by Alice.
|
||||
|
||||
Connection IDs: The two connection IDs are derived from the test nonce.
|
||||
For messages sent from Charlie to Alice, the Destination Connection ID
|
||||
is two copies of the 4-byte test nonce, i.e. ((nonce << 32) | nonce).
|
||||
The Source Connection ID is the inverse of the Destination Connection ID,
|
||||
i.e. ~((nonce << 32) | nonce).
|
||||
For messages sent from Alice to Charlie, swap the two connection IDs.
|
||||
|
||||
|
||||
|
||||
@ -5505,8 +5520,8 @@ either in the same payload (if there's room), or in a previous message.
|
||||
reject codes only allowed in messages 3 and 4
|
||||
flag :: 1 byte flags, Unused, set to 0 for future compatibility
|
||||
hash :: Alice's or Charlie's 32-byte router hash,
|
||||
only present in messages 2-4.
|
||||
Not present in message 4 if rejected by Bob.
|
||||
only present in messages 2 and 4.
|
||||
All zeros (fake hash) in message 4 if rejected by Bob.
|
||||
|
||||
For messages 1-4, the data below here is covered
|
||||
by the signature, if present, and Bob forwards it unmodified.
|
||||
@ -5566,6 +5581,7 @@ Signature algorithm: Sign or verify the following data with the Alice's or Charl
|
||||
|
||||
- prologue: 16 bytes "PeerTestValidate", not null-terminated (not included in the message)
|
||||
- bhash: Bob's 32-byte router hash (not included in the message)
|
||||
- ahash: Alice's 32-byte router hash (for messages 3 and 4 only; not included in message 3)
|
||||
- role: 1 byte role of the signer
|
||||
- ver: 1 byte SSU version
|
||||
- nonce: 4 byte test nonce
|
||||
@ -6039,9 +6055,11 @@ Acceptance of an unexpired token is not guaranteed; if Bob has forgotten or dele
|
||||
his saved tokens, he will send a Retry to Alice.
|
||||
|
||||
New Token blocks may be sent from Alice to Bob or Bob to Alice.
|
||||
They would typically be sent once, soon after session establishment.
|
||||
They would typically be sent once, during or soon after session establishment.
|
||||
The token may be resent before or after expiration with a new expiration time,
|
||||
or a new token may be sent.
|
||||
Routers should assume that only the last token received is valid;
|
||||
there is no requirement to store multiple inbound or outbound tokens for the same router.
|
||||
|
||||
A token is bound to the combination of source IP/port, destination IP/port,
|
||||
static keys, and router hashes. A token received on IPv4 may not be used
|
||||
@ -6097,6 +6115,10 @@ are received and the signature and static key are validated.
|
||||
Bob must NOT send any I2NP blocks to Alice before all Router Info blocks
|
||||
are received and the signature and static key are validated.
|
||||
|
||||
TODO: Another alternative to fragmentation is to make the RI much more compressible,
|
||||
by padding the Router Identity (between the two keys) with zeros.
|
||||
This would be 320 bytes of zeros assuming a 32-byte X25519 crypto key and
|
||||
a 32-byte EdDSA signing key.
|
||||
|
||||
|
||||
|
||||
@ -6498,6 +6520,13 @@ Perhaps we could do this only if we don't have a token,
|
||||
or after a Retry message is received.
|
||||
TBD
|
||||
|
||||
QUIC requires that Bob send no more than three times the amount of data
|
||||
received until the client address is validated.
|
||||
SSU2 meets this requirement inherently, because the Retry message
|
||||
is about the same size as the Token Request message, and is
|
||||
smaller than the Session Request message.
|
||||
Also, the Retry message is only sent once.
|
||||
|
||||
|
||||
Path Message Min Size
|
||||
-------------------------
|
||||
@ -6602,7 +6631,8 @@ Alice Bob Charlie
|
||||
{% endhighlight %}
|
||||
|
||||
|
||||
|
||||
Messages 1-4 are in-session using Peer Test blocks in a Data message.
|
||||
Messages 5-7 are out-of-session using Peer Test blocks in a Peer Test message.
|
||||
|
||||
========= ============ =============
|
||||
Message Path Intro Key
|
||||
@ -6618,17 +6648,16 @@ Message Path Intro Key
|
||||
|
||||
|
||||
|
||||
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):
|
||||
Cross-version peer testing is not supported.
|
||||
The only allowed version combination is where all peers are version 2.
|
||||
|
||||
========= =========== ============= =============
|
||||
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?
|
||||
1 2 1 no, Bob must select a version 1 Charlie
|
||||
1 2 2 no, Bob must select a version 1 Charlie
|
||||
2 1 2 no, Bob must select a version 2 Charlie
|
||||
2 2 1 no, use 2/2/2
|
||||
2 2 2 yes
|
||||
========= =========== ============= =============
|
||||
|
Reference in New Issue
Block a user