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

Prop. 159 minor updates

Browse Source
This commit is contained in:
zzz
2022-07-19 11:26:14 -04:00
parent 6c2211604f
commit 784c862e1c
1 changed files with 58 additions and 16 deletions
Download Patch File Download Diff File Expand all files Collapse all files

74
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-07-10
:lastupdated: 2022-07-19
:status: Open
:target: 0.9.56
@ -5143,10 +5143,8 @@ In all other messages, order is unspecified, except for the
following requirements:
Padding, if present, must be the last block.
Termination, if present, must be the last block except for Padding.
Multiple Padding blocks are not allowed in a single payload.
Other block types probably won't have multiple blocks in
a single payload, but it is not prohibited.
Block Specifications
----------------------
@ -6069,6 +6067,8 @@ Notes:
- This format is a simplified version of that in QUIC.
It is designed to efficiently encode a large number of ACKs,
together with bursts of NACKs.
- ACK blocks are used to acknowledge data phase packets.
They are only to be included for in-session data phase packets.
Address
@ -6386,7 +6386,7 @@ Or, just retain and retransmit the same encrypted packet.
Packet number must not be incremented, because that would change
the chained hash value used to encrypt the Session Created message.
Recommended retransmission intervals: 3 and 6 seconds (3 and 9 seconds after first sent).
Recommended retransmission intervals: 1.25, 2.5, and 5 seconds (1.25, 3.75, and 8.75 seconds after first sent).
Recommended timeout: 15 seconds total
@ -6399,16 +6399,17 @@ Or, just retain the encrypted packet.
Packet number must not be incremented, because that would change
the chained hash value used to encrypt the Session Confirmed message.
Recommended retransmission intervals: 3 and 6 seconds (3 and 9 seconds after first sent).
Recommended timeout: 15 seconds total
Recommended retransmission intervals: 1, 2, and 4 seconds (1, 3, and 7 seconds after first sent).
Recommended timeout: 12 seconds total
Session Confirmed
------------------
In SSU 1, Alice does not shift to the data phase until the first data packet is
received from Bob. This makes SSU 1 a two-round-trip setup.
Session Confirmed messages will be retransmitted
at 3 and 6 seconds (3 and 9 seconds after first sent).
For SSU 2,
Recommended Session Confirmed retransmission intervals: 1.25, 2.5, and 5 seconds (1.25, 3.75, and 8.75 seconds after first sent).
There are several alternatives. All are 1 RTT:
@ -6423,7 +6424,7 @@ There are several alternatives. All are 1 RTT:
3) We could use IK instead of XK, as it has only two messages in the handshake, but
it uses an extra DH (4 instead of 3).
The preferred alternative is option 2).
The recommeded implementation is option 2).
Alice must retain the information required to retransmit the Session Confirmed message.
Alice should also retransmit all Data messages after the Session Confirmed
message is retransmitted.
@ -6443,6 +6444,13 @@ decrypt and process the queued Data messages.
If this is too complex, Bob may just drop the undecryptable Data messages,
as Alice will retransmit them.
Note: If the session confirmed packets are lost, Bob will retransmit
session created. The session created header will not be decryptable
with Alice's intro key, as it is set with Bob's intro key
(unless fallback decryption is performed with Bob's intro key).
Bob may immediately retransmit the session confirmed packets
if not previously acked, and an undecryptable packet is received.
Token Request
----------------
@ -6655,13 +6663,18 @@ load generated by a receiver that sends an ACK block in response to
every ack-eliciting packet. The guidance offered below seeks to
strike this balance.
All blocks EXCEPT for the following are ack-eliciting:
In-session data packets containing any block
EXCEPT for the following are ack-eliciting:
- ACK block
- Padding block
- Termination block
- Others?
Out-of session packets, including handshake messages
and peer test messages 5-7, have their own acknowledgement mechanisms.
See below.
Handshake ACKs
--------------
@ -6680,6 +6693,9 @@ These are special cases:
Sending ACK Blocks
---------------------
ACK blocks are used to acknowledge data phase packets.
They are only to be included for in-session data phase packets.
Every packet should be acknowledged at least once, and ack-eliciting
packets must be acknowledged at least once within a maximum delay.
@ -6946,6 +6962,8 @@ an increase in the maximum I2NP message size.
A router must not enable SSU2 or publish an SSU2 address unless
the MTU for that address is at least 1280.
Routers must publish a non-default MTU in each SSU or SSU2 router address.
SSU Address
------------
@ -7835,6 +7853,27 @@ Therefore, the recommended processing steps in the receiver loop logic are:
4) If running SSU 1 on the same port, attempt to process the message as an SSU 1 packet.
Error Handling
```````````````
In general, a session (in the handshake or data phase) should never be destroyed
after receiving a packet with an unexpected message type. This prevents
packet injection attacks. These packets will also commonly be received
after retransmission of a handshake packet, when the header decryption keys
are no longer valid.
In most cases, simply drop the packet. An implementation may, but is not required to,
retransmit the previously-sent packet (handshake message or ACK 0) in response.
After sending Session Created as Bob, unexpected packets are commonly Data packets
that cannot be decrypted because the Session Confirmed packets were lost or out-of-order.
Queue the packets and attempt to decrypt them after receiving the Session Confirmed packets.
After receiving Session Confirmed as Bob, unexpected packets are commonly retransmitted
Session Confirmed packets, because the ACK 0 of the Sesssion Confirmed was lost.
The unexpected packets may be dropped.
An implementation may, but is not required to, send a Data packet containing an ACK block in response.
Notes
-------
@ -7859,14 +7898,17 @@ TBD if required.
Recommended Constants
=======================
- Handshake retransmission timeout: 3 seconds, with exponential backoff
(retransmissions at 3 and 9 seconds)
- Total handshake timeout: 20 seconds
- Outbound handshake retransmission timeout: 1.25 seconds, with exponential backoff
(retransmissions at 1.25, 3.75, and 8.75 seconds)
- Total outbound handshake timeout: 15 seconds
- Inbound handshake retransmission timeout: 1 second, with exponential backoff
(retransmissions at 1, 3, and 7 seconds)
- Total inbound handshake timeout: 12 seconds
- Timeout after sending retry: 9 seconds
- ACK delay: max(10, min(rtt/6, 150) ms
- Max ACK ranges: 256?
- Max ACK depth: 512?
- Padding distribution: ?
- Padding distribution: 0-15 bytes, or greater
@ -7904,7 +7946,7 @@ Message Header+MACs Keys Data Padding Total Notes
================== =========== ===== ====== ======= ====== =====
Session Request 48 32 7 87 DateTime block
Session Created 48 32 16 96 DateTime, Address blocks
Session Confirmed 48 32 1005 1085 1000 byte RI block
Session Confirmed 48 32 1005 1085 1000 byte compressed RI block
Data (1 full msg) 32 14 46
Total 1314
================== =========== ===== ====== ======= ====== =====