Prop. 159 updates

Peer Test, amplification, RI compression
This commit is contained in:
zzz
2022-03-17 10:50:06 -04:00
parent d72e71a30d
commit 16d78a3552

View File

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