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

Prop. 159 handshake retransmissions and packet numbers

Browse Source
This commit is contained in:
zzz
2022-02-10 13:02:05 -05:00
parent 1e152b06d2
commit 50eb1abb4f
1 changed files with 21 additions and 18 deletions
Download Patch File Download Diff File Expand all files Collapse all files

39
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-09
:lastupdated: 2022-02-10
:status: Open
:target: 0.9.55
@ -2762,10 +2762,20 @@ number of packets is sent.
TODO key rotation, reduce max packet number?
Packets that are determined to be lost are not retransmitted
Handshake packets that are determined to be lost are retransmitted
whole, with the identical header including packet number.
The handshake messages Session Request, Session Created, and Session Confirmed
MUST be retransmitted with the same packet number and identical encrypted contents,
so that the same chained hash will be used to encrypt the response.
The Retry message is never transmitted.
Data phase packets that are determined to be lost are never retransmitted
whole. The same applies to the blocks that are contained within lost
packets. Instead, the information that might be carried in blocks is
sent again in new packets as needed.
Data Packets are never retransmitted with the same packet number.
Any retransmission of packet contents (whether or not the contents remain the same)
must use the next unused packet number.
New packets are used to carry information that is
determined to have been lost. In general, information is sent again
@ -2773,16 +2783,8 @@ when a packet containing that information is determined to be lost,
and sending ceases when a packet containing that information is remain the same)
acknowledged.
Data Packets are never retransmitted with the same packet number.
Any retransmission of packet contents (whether or not the contents remain the same)
must use the next unused packet number.
The handshake messages Session Request, Session Created, and Session Confirmed
MUST be retransmitted with the same packet number and identical encrypted contents,
so that the same chained hash will be used to encrypt the response.
Packet numbering starts with Session Request. Assuming no retransmissions
in the handshake, and no Retry reply from Bob, the packet numbers
Packet numbering starts with Session Request. Assuming
no Retry reply from Bob, the packet numbers
in an example standard handshake will be:
.. raw:: html
@ -3309,7 +3311,8 @@ Unencrypted data (Poly1305 authentication tag not shown):
flag :: 1 byte, unused, set to 0 for future compatibility
Packet Number :: 0 unless resent after Retry
Packet Number :: 0 if no Retry was received
1 if this is a new SessionRequest after a Retry was received
Source Connection ID :: Randomly generated by Alice,
must not be equal to Destination Connection ID
@ -3578,7 +3581,7 @@ Unencrypted data (Poly1305 auth tag not shown):
flag :: 1 byte, unused, set to 0 for future compatibility
Packet Number :: 0 unless resent after Retry
Packet Number :: 0
Source Connection ID :: The Destination Connection ID
received from Alice in Session Request
@ -3853,8 +3856,8 @@ Unencrypted data (Poly1305 auth tags not shown):
Destination Connection ID :: As sent in Session Request,
or one received in Session Confirmed?
Packet Number :: 1 unless the Session Request message was
retransmitted or resent after Retry
Packet Number :: 1 if no Retry was received
2 if a Retry was received
type :: 2
@ -5308,12 +5311,12 @@ as Alice will retransmit them.
Retry
---------
A Retry message is never retransmitted, except in response to a repeated
A Retry message is never retransmitted, except (optionally) in response to a repeated
Session Request message being received.
If resending the Retry message:
Maintain same source and connection IDs. Increment packet number.
Re-protect header, re-obfuscate header, as the packet number changed.
Re-encrypt the header, as the packet number changed.