Prop. 159 minor updates
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-06-15
|
||||
:lastupdated: 2022-06-20
|
||||
:status: Open
|
||||
:target: 0.9.56
|
||||
|
||||
@@ -4609,7 +4609,7 @@ or it may be regenerated. Signature is optional.
|
||||
|
||||
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).
|
||||
is two copies of the 4-byte big-endian 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.
|
||||
@@ -4989,7 +4989,6 @@ Unencrypted data (Poly1305 authentication tag not shown):
|
||||
Source Connection ID :: See below
|
||||
|
||||
Token :: 8 byte unsigned integer, randomly generated by Charlie, nonzero.
|
||||
Identical to the token sent in the Relay Response.
|
||||
|
||||
{% endhighlight %}
|
||||
|
||||
@@ -5005,7 +5004,7 @@ total more than that, the requirement is met with only those two blocks.
|
||||
|
||||
Connection IDs: The two connection IDs are derived from the relay nonce.
|
||||
The Destination Connection ID
|
||||
is two copies of the 4-byte relay nonce, i.e. ((nonce << 32) | nonce).
|
||||
is two copies of the 4-byte big-endian relay nonce, i.e. ((nonce << 32) | nonce).
|
||||
The Source Connection ID is the inverse of the Destination Connection ID,
|
||||
i.e. ~((nonce << 32) | nonce).
|
||||
|
||||
@@ -5075,6 +5074,8 @@ a Padding block must be included.
|
||||
|
||||
Maximum ChaChaPoly payload varies based on message type, MTU,
|
||||
and IPv4 or IPv6 address type.
|
||||
Maximum payload is MTU - 60 for IPv4 and MTU - 80 for IPv6.
|
||||
Maximum payload data is MTU - 63 for IPv4 and MTU - 83 for IPv6.
|
||||
Upper limit is about 1440 bytes for IPv4, 1500 MTU, Data message.
|
||||
Maximum total block size is the maximum payload size.
|
||||
Maximum single block size is the maximum total block size.
|
||||
@@ -5355,6 +5356,8 @@ Notes:
|
||||
- This is exactly the same format as the First Fragment block,
|
||||
but the block type indicates that this is a complete message.
|
||||
|
||||
- Maximum size including 9-byte I2NP header is MTU - 63 for IPv4 and MTU - 83 for IPv6.
|
||||
|
||||
|
||||
First Fragment
|
||||
```````````````
|
||||
@@ -5403,6 +5406,8 @@ Notes:
|
||||
so that the receiver knows the total number of fragments and can
|
||||
efficiently allocate receive buffers.
|
||||
|
||||
- Maximum size including 9-byte I2NP header is MTU - 63 for IPv4 and MTU - 83 for IPv6.
|
||||
|
||||
|
||||
Follow-on Fragment
|
||||
````````````````````````
|
||||
@@ -5448,6 +5453,8 @@ Notes:
|
||||
which is about 55 fragments with a 1280 minimum MTU.
|
||||
See the Max I2NP Message Size section below.
|
||||
|
||||
- Maximum partial message size (not including frag and message id) is MTU - 68 for IPv4 and MTU - 88 for IPv6.
|
||||
|
||||
|
||||
|
||||
Termination
|
||||
@@ -7251,13 +7258,24 @@ a short delay (recommended 500 ms) before initiating the handshake with Charlie.
|
||||
|
||||
In SSU 2, Alice will usually receive the Hole Punch (1 1/2 RTT)
|
||||
before the Relay Response (2 RTT).
|
||||
The Hole Punch is easier to process because it is a full
|
||||
The SSU 2 Hole Punch is easier to process than in SSU 1, because it is a full
|
||||
message with defined connection IDs (derived from the relay nonce) and contents including Charlie's IP.
|
||||
The Relay Response (Data message) and Hole Punch message contain the identical
|
||||
signed Relay Response block.
|
||||
Therefore, Alice may initiate the handshake with Charlie after
|
||||
EITHER receiving the Hole Punch from Charlie, OR receiving the Relay Response from Bob.
|
||||
|
||||
The signature verification of the Hole Punch includes the introducer's (Bob's) router hash.
|
||||
If Relay Requests have been sent to more than one introducer,
|
||||
there are several options to validate the signature:
|
||||
|
||||
- Try each hash to which a request was sent
|
||||
- Use different nonces for each introducer, and use that to determine which
|
||||
introducer this Hole Punch was in response to
|
||||
- Don't re-validate the signature if the contents are identical
|
||||
to that in the Relay Response, if already received
|
||||
- Don't validate the signature at all
|
||||
|
||||
|
||||
|
||||
Published Router Info
|
||||
|
Reference in New Issue
Block a user