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

Prop. 159 more updates

Browse Source
This commit is contained in:
zzz
2021-10-16 16:24:49 -04:00
parent cdcea91fd4
commit 49d005c534
1 changed files with 139 additions and 35 deletions
Download Patch File Download Diff File Expand all files Collapse all files

174
i2p2www/spec/proposals/159-ssu2.rst
View File

@ -81,7 +81,7 @@ Design Goals
implementation-dependent and may or may not be specified in the protocol
itself.
- Obfuscate the contents of messages that aren't encrypted (Session Created and Confirmed),
- Obfuscate the contents of messages that aren't fully encrypted (Session Created and Confirmed),
sufficiently so that DPI boxes and AV signatures can't easily classify them.
Also ensure that the messages going to a single peer or set of peers do not
have a similar pattern of bits.
@ -124,6 +124,9 @@ Design Goals
- Maintain a max I2NP message size of approximately 32K, as in SSU.
Increase to 64 KB? TBD
- Remove IP and port fields from the handshake, so that routers that don't know
their external IP and port will be able to connect.
- Include representatives of Java, C++, and Go router developers in the design.
@ -294,6 +297,7 @@ Address Validation
---------------------------
Following is copied from QUIC [RFC-9000]_.
For each section, review and edit.
Address validation ensures that an endpoint cannot be used for a
traffic amplification attack. In such an attack, a packet is sent to
@ -774,6 +778,8 @@ Connection Migration
----------------------------
Following is copied from QUIC [RFC-9000]_.
For each section, review and edit.
The use of a connection ID allows connections to survive changes to
endpoint addresses (IP address and port), such as those caused by an
@ -1213,27 +1219,18 @@ on any path.
Use of IPv6 Flow Label and Migration
``````````````````````````````````````````
Endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437], unless the local API does not allow
QUIC recommends endpoints that send data using IPv6 SHOULD apply an IPv6 flow label
in compliance with [RFC6437]_, unless the local API does not allow
setting IPv6 flow labels.
The flow label generation MUST be designed to minimize the chances of
linkability with a previously used flow label, as a stable flow label
would enable correlating activity on multiple paths; see Section 9.5.
[RFC6437] suggests deriving values using a pseudorandom function to
generate flow labels. Including the Destination Connection ID field
in addition to source and destination addresses when generating flow
labels ensures that changes are synchronized with changes in other
observable identifiers. A cryptographic hash function that combines
these inputs with a local secret is one way this might be
implemented.
Unfortunately, the Java API does not allow setting IPv6 flow labels.
Security Considerations
---------------------------
Following is copied from QUIC [RFC-9000]_.
For each section, review and edit.
The goal of QUIC is to provide a secure transport connection.
Section 21.1 provides an overview of those properties; subsequent
@ -2108,6 +2105,24 @@ Endpoints might also reveal sensitive information through other side
channels, such as the timing of packets.
Relay Security
----------------
Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch
SSU 1 and 2 TBD
Peer Test Security
---------------------
Analysis of Relay Request, Relay Response, Relay Intro, and Hole Punch
SSU 1 and 2 TBD
@ -2143,6 +2158,10 @@ for inspiration, guidance, and code reuse:
* Messages: Adapted from [SSU]_
* I2NP Fragmentation: Adapted from [SSU]_
* Relay and Peer Testing: Adapted from [SSU]_
* Block format: From [NTCP2]_ and [ECIES]_.
* Padding and options: From [NTCP2]_ and [ECIES]_.
@ -2151,6 +2170,28 @@ for inspiration, guidance, and code reuse:
Delivery Guarantees
----------------------
As with other I2P transports NTCP, NTCP2, and SSU 1, this transport is not a general-purpose
facility for delivery of an in-order stream of bytes. It is designed for
transport of I2NP messages. There is no "stream" abstraction provided.
In addition, as for SSU, it contains additional facilities for peer-facilitated NAT traversal
and testing of reachability (inbound connections).
As for SSU 1, it does NOT provide in-order delivery of I2NP messages.
Nor does it provide guaranteed delivery of I2NP messages.
For efficiency, or because of out-of order delivery of UDP datagrams
or loss of those datagrams, I2NP messages may be delivered to the
far-end out-of-order, or may not be delivered at all.
An I2NP message may be retransmitted multiple times if necessary,
but delivery may eventually fail without causing the full connection to be
disconnected. Also, new I2NP messages may continue to be sent even
while retransmission (loss recovery) is occurring for other I2NP messages.
Noise Protocol Framework
-------------------------
@ -2220,9 +2261,6 @@ We define the following functions corresponding to the cryptographic building bl
ZEROLEN
zero-length byte array
CSRNG(n)
n-byte output from a cryptographically-secure random number generator.
H(p, d)
SHA-256 hash function that takes a personalization string p and data d, and
produces an output of length 32 bytes.
@ -2414,7 +2452,7 @@ Before header obfuscation and protection:
+----+----+----+----+----+----+----+----+
| Source Connection ID |
+----+----+----+----+----+----+----+----+
| Retry Token |
| Token |
+----+----+----+----+----+----+----+----+
Destination Connection ID :: 8 bytes, unsigned big endian integer
@ -2431,7 +2469,7 @@ Before header obfuscation and protection:
Source Connection ID :: 8 bytes, unsigned big endian integer
Retry Token :: 8 bytes, unsigned big endian integer
Token :: 8 bytes, unsigned big endian integer
{% endhighlight %}
@ -2477,6 +2515,17 @@ Packets are numbered within a single session, for each direction, starting from
A session must be terminated, and a new session created, well before the max
number of packets is sent.
Packets that are determined to be lost are not 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.
New packets are used to carry information that is
determined to have been lost. In general, information is sent again
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.
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.
@ -2874,7 +2923,7 @@ Unencrypted data (Poly1305 authentication tag not shown):
+----+----+----+----+----+----+----+----+
| Source Connection ID |
+----+----+----+----+----+----+----+----+
| Retry Token |
| Token |
+----+----+----+----+----+----+----+----+
| |
+ +
@ -2904,7 +2953,7 @@ Unencrypted data (Poly1305 authentication tag not shown):
Source Connection ID :: Randomly generated by Alice
Retry Token :: 0 if not previously received from Bob
Token :: 0 if not previously received from Bob
X :: 32 bytes, X25519 ephemeral key, little endian
@ -3147,7 +3196,7 @@ Unencrypted data (Poly1305 auth tag not shown):
+----+----+----+----+----+----+----+----+
| Source Connection ID |
+----+----+----+----+----+----+----+----+
| Retry Token |
| Token |
+----+----+----+----+----+----+----+----+
| |
+ +
@ -3176,7 +3225,7 @@ Unencrypted data (Poly1305 auth tag not shown):
Source Connection ID :: Randomly generated by Alice
Retry Token :: 0 (unused)
Token :: 0 (unused)
Y :: 32 bytes, X25519 ephemeral key, little endian
@ -3681,7 +3730,7 @@ Unencrypted data (Poly1305 authentication tag not shown):
+----+----+----+----+----+----+----+----+
| Source Connection ID |
+----+----+----+----+----+----+----+----+
| Retry Token |
| Token |
+----+----+----+----+----+----+----+----+
| ChaCha20 payload (block data) |
+ (length varies) +
@ -3703,7 +3752,7 @@ Unencrypted data (Poly1305 authentication tag not shown):
Source Connection ID :: As received from Alice in Session Request
Retry Token :: 8 byte unsigned integer, nonzero
Token :: 8 byte unsigned integer, nonzero
{% endhighlight %}
@ -3809,7 +3858,9 @@ Partial ACK 13 varies
NACK 14 varies
Relay Tag Request 15 3
Relay Tag 16 7
Retry Token 17 15
New Token 17 15
Path Challenge 18 varies
Path Response 19 varies
reserved for experimental features 255
Padding 254 varies
reserved for future extension 255
@ -4485,7 +4536,7 @@ In the Session Created message.
{% endhighlight %}
Retry Token
New Token
```````````````
For a subsequent connection:
@ -4495,18 +4546,68 @@ For a subsequent connection:
+----+----+----+----+----+----+----+----+
| 17 | 4 | expires | |
+----+----+----+----+----+----+----+ +
retry token |
token |
+----+----+----+----+----+----+----+
blk :: 17
size :: 2 bytes, big endian, value = 4
expires :: Unix timestamp, unsigned seconds.
Wraps around in 2106
retry token :: 8 bytes, big endian
token :: 8 bytes, big endian
{% endhighlight %}
Path Challenge
``````````````
A Ping with arbitrary data to be returned in a Path Response,
used as a keep-alive or to validate an IP/Port change.
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| 18 | size | Arbitrary Data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 18
size :: 2 bytes, big endian, size of data to follow
data :: Arbitrary data to be returned in a Path Response
length as selected by sender
{% endhighlight %}
Path Response
``````````````
A Pong with arbitrary data, a reply to a Path Challenge,
used as a keep-alive or to validate an IP/Port change.
.. raw:: html
{% highlight lang='dataspec' %}
+----+----+----+----+----+----+----+----+
| 19 | size | Arbitrary Data |
+----+----+----+ +
| |
~ . . . ~
| |
+----+----+----+----+----+----+----+----+
blk :: 19
size :: 2 bytes, big endian, size of data to follow
data :: As received in a Path Challenge
{% endhighlight %}
Padding
```````
This is for padding inside AEAD payloads.
@ -4632,10 +4733,10 @@ Total Timeout
Recommended total timeout for the handshake is 20 seconds.
Retry Token
Token
=============
The Retry Token in the Session Request header is used for DoS mitigation.
The Token in the Session Request header is used for DoS mitigation.
If Bob does not accept the token in the Session Request message, Bob does NOT decrypt
the message, as it requires an expensive DH operation.
@ -4644,7 +4745,7 @@ Bob simply sends a Retry message with a new token.
If a subsequent Session Request message then is received with that token,
Bob proceeds to decrypt that message and proceed with the handshake.
The retry token may be a randomly-generated 8 byte value, if the generator of the token
The token may be a randomly-generated 8 byte value, if the generator of the token
stores the values and associated IP and port (in-memory or persistently).
Alternatively, the generator may generate an opaque value (for example,
using the SipHash with a stored seed of the IP, port, and current hour or day)
@ -4654,7 +4755,7 @@ Note that this method may make it difficult to reject reused tokens.
Tokens may only be used once.
A token sent from Bob to Alice in a Retry message must be used immediately, and expires
in a few seconds.
A token sent in a Retry Token block in an established session
A token sent in a New Token block in an established session
may be used in a subsequent connection, and it
expires at the time specified in that block.
Expiration is specified by the sender; recommended values are
@ -4664,7 +4765,7 @@ Tokens may optionally be persisted across router restarts, implementation depend
Acceptance of an unexpired token is not guaranteed; if Bob has forgotten or deleted
his saved tokens, he will send a Retry to Alice.
Retry Token blocks may be sent from Alice to Bob or Bob 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.
The token may be resent before or after expiration with a new expiration time,
or a new token may be sent.
@ -4809,7 +4910,7 @@ to prevent amplification attacks. and ensure the PMTU supports it.
We could require this for Session Request and Session Created,
at substantial cost in bandwidth.
Perhaps we could do this only if we don't have a retry token,
Perhaps we could do this only if we don't have a token,
or after a Retry message is received.
@ -5183,6 +5284,9 @@ References
.. [RFC-6151]
https://tools.ietf.org/html/rfc6151
.. [RFC-6437]
https://tools.ietf.org/html/rfc6437
.. [RFC-7539]
https://tools.ietf.org/html/rfc7539