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

Merge branch 'master' of i2pgit.org:i2p-hackers/i2p.www

Browse Source
This commit is contained in:
eyedeekay
2024-08-08 13:34:50 -04:00
parent 16f38b9e24 08b5bfdead
commit f8e04ce6ae
4 changed files with 234 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
i2p2www/pages/site/about/media.html
View File

@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %}{{ _('Presentations on I2P') }}{% endblock %}
{% block lastupdated %}2022-03{% endblock %}
{% block lastupdated %}2024-08{% endblock %}
{% block content %}
<p>{% trans papers=site_url('papers') -%}
Following are links to presentations, videos, and tutorials about I2P. Links to research papers on I2P are available <a href="{{ papers }}">here</a>.
@ -139,6 +139,25 @@ Andrew Savchenko (bircoph), FOSDEM, Brussel, February 4, 2018
idk
{%- endtrans %}</li>
<li>
I2P, blockchain and the application (FOSDEM 2021)
<a href="https://odysee.com/@diva.exchange:d/diva-exchange-fosdem-21:c">video</a>
February 7, 2021
</li>
<li>
Private, fully distributed exchange (DEX), Monero and I2P research results
<a href="https://odysee.com/@diva.exchange:d/monerokon2022:0">video</a>
MoneroKon 2022 Lisbon
July 5, 2022
</li>
<li>
DNS for I2P (FOSDEM 2023)
<a href="https://odysee.com/@diva.exchange:d/diva-dns-i2p-fosdem2023:2">video</a>
February 12, 2023
</li>
</ul>
@ -264,6 +283,31 @@ Opt Out Podcast Season 2 Episode 10
March 6, 2022
</li>
<li>
I2P and DIVA.EXCHANGE - Interview with Konrad
(<a href="https://odysee.com/@diva.exchange:d/i2p-diva-exchange-2022-09-26:6">video</a>)
September 26, 2022
</li>
<li>
Interview with Sadie on I2P and the Free Internet
(<a href="https://www.diva.exchange/en/privacy/i2p-and-the-free-internet-interview-with-a-community-member/">interview</a>)
February 2024
</li>
<li>
Interview with Phillip on I2P Network Reliability
(<a href="https://www.diva.exchange/en/privacy/i2p-network-reliability-is-on-the-radar-of-the-academic-community/">interview</a>)
March 2024
</li>
<li>
Interview with IDK on I2P Development
(<a href="https://www.diva.exchange/en/privacy/i2p-interview-with-the-developer-idk-part-1/">interview part 1</a>)
July 2024
</li>
</ul>
<h2>{{ _('Other') }}</h2>

8
i2p2www/spec/ecies.rst
View File

@ -3,8 +3,8 @@ ECIES-X25519-AEAD-Ratchet
=========================
.. meta::
:category: Protocols
:lastupdated: 2020-11
:accuratefor: 0.9.47
:lastupdated: 2024-08
:accuratefor: 0.9.63
.. contents::
@ -15,7 +15,7 @@ Network deployment and testing in progress.
Subject to minor revisions.
See [Prop144]_ for the original proposal, including background discussion and additional information.
The following features are not implemented as of 0.9.46:
The following features are not implemented as of 0.9.63:
- MessageNumbers, Options, and Termination blocks
- Protocol-layer responses
@ -2143,7 +2143,7 @@ a single frame, but it is not prohibited.
DateTime
````````
An expiration.
Assists in reply prevention.
Assists in replay prevention.
Bob must validate that the message is recent, using this timestamp.
Bob must implement a Bloom filter or other mechanism to prevent replay attacks,
if the time is valid.

35
i2p2www/spec/i2cp.rst
View File

@ -3,8 +3,8 @@ I2CP Specification
==================
.. meta::
:category: Protocols
:lastupdated: 2024-01
:accuratefor: 0.9.62
:lastupdated: 2024-08
:accuratefor: 0.9.63
.. contents::
@ -497,9 +497,11 @@ Contents
Notes
`````
Currently, the client limits are the only values set, and are actually the
router limits. All the values labeled as router limits are always 0. As of
release 0.7.2.
The client limits may be the only values set, and may be the
actual router limits, or a percentage of the router limits, or specific to
the particular client, implementation-dependent.
All the values labeled as router limits may be 0, implementation-dependent.
As of release 0.7.2.
.. _msg-BlindingInfo:
@ -1189,6 +1191,12 @@ Notes
changes here will not be recognized by the router. Changes to tunnel options
inbound.* and outbound.* are always recognized.
* In general, the router should merge the updated config with the current config,
so the updated config only needs to contain the new or changed options.
However, because of the merge, options may not be removed in this manner;
they must be set explicitly to the desired default value.
.. _msg-ReportAbuse:
ReportAbuseMessage
@ -1228,6 +1236,12 @@ Request that a client authorize the inclusion of a particular set of inbound
tunnels. Sent from Router to Client. The client responds with a
CreateLeaseSetMessage_.
The first of these messages sent on a session is a signal to the client
that tunnels are built and ready for traffic. The router must not
send the first of these messages until at least one inbound AND one outbound tunnel
have been built. Clients should timeout and destroy the session if the first
of these messages is not received after some time (recommended: 5 minutes or more).
Contents
````````
1. `Session ID`_
@ -1257,6 +1271,12 @@ tunnels.
Sent from Router to Client. The client responds with a CreateLeaseSetMessage_ or CreateLeaseSet2Message_.
The first of these messages sent on a session is a signal to the client
that tunnels are built and ready for traffic. The router must not
send the first of these messages until at least one inbound AND one outbound tunnel
have been built. Clients should timeout and destroy the session if the first
of these messages is not received after some time (recommended: 5 minutes or more).
Contents
````````
1. `Session ID`_
@ -1466,8 +1486,11 @@ Description
```````````
Instruct the client as to the status of its session.
Sent from Router to Client, possibly in response to a CreateSessionMessage_,
Sent from Router to Client, in response to a CreateSessionMessage_,
ReconfigureSessionMessage_, or DestroySessionMessage_.
In all cases, including in response to CreateSessionMessage_,
the router should respond immediately (do not wait for tunnels to be built).
Contents
````````

156
i2p2www/spec/proposals/168-tunnel-bandwidth.rst Normal file
View File

@ -0,0 +1,156 @@
===================================
Tunnel Bandwidth Parameters
===================================
.. meta::
:author: zzz
:created: 2024-07-31
:thread: http://zzz.i2p/topics/3652
:lastupdated: 2024-07-31
:status: Open
:target: 0.9.65
.. contents::
Overview
========
As we have increased the performance of the network over the last several years
with new protocols, encryption types, and congestion control improvements,
faster applications such as video streaming are becoming possible.
These applications require high bandwidth at each hop in their client tunnels.
Participating routers, however, do not have any information about how much
bandwidth a tunnel will use when they get a tunnel build message.
They can only accept or reject a tunnel based on the current total bandwidth
used by all participating tunnels and the total bandwidth limit for participating tunnels.
Requesting routers also do not have any information on how much bandwidth
is available at each hop.
This proposal addresses the issue by adding bandwidth parameters to
the tunnel build request and reply messages.
Design
======
Add bandwidth parameters to the records in ECIES tunnel build messages [Tunnel-Creation-ECIES]_
in the tunnel build options mapping field. Use short parameter names since the space available
for the options field is limited.
Tunnel build messages are fixed-size so this does not increase the
size of the messages.
Specification
=============
Update the ECIES tunnel build message specification [Tunnel-Creation-ECIES]_
as follows:
For both long and short ECIES build records:
Build Request Options
---------------------------
The following two options may be set in the tunnel build options mapping field of the record:
A requesting router may include either or both.
- m := minimum bandwidth required for this tunnel (KBps positive integer as a string)
- r := requested bandwidth for this tunnel (KBps positive integer as a string)
The participating router should reject the tunnel if "m" is specified and it cannot
provide at least that much bandwidth.
Build Reply Option
---------------------------
The following option may be set in the tunnel build reply options mapping field of the record,
when the response is ACCEPTED:
- b := bandwidth available for this tunnel (KBps positive integer as a string)
The participating router should include this if either "m" or "r" was specified
in the build request. The value should be at least that of the "m" value if specified,
but may be less or more than the "r" value if specified.
The participating router should attempt to reserve and provide at least this
much bandwidth for the tunnel, however this is not guaranteed.
Routers cannot predict conditions 10 minutes into the future, and
participating traffic is lower-priority than a router's own traffic and tunnels.
Routers may also over-allocate available bandwidth if necessary, and this is
probably desirable, as other hops in the tunnel could reject it.
Implementation Notes
=====================
Bandwidth parameters are as seen at the participating routers at the tunnel layer,
i.e. the number of fixed-size 1 KB tunnel messages per second.
Transport (NTCP2 or SSU2) overhead is not included.
This bandwidth may be much more or less than the bandwidth seen at the client.
Tunnel messages contain substantial overhead, including overhead from higher layers
including ratchet and streaming. Intermittent small messages such as streaming acks
will be expanded to 1 KB each.
However, gzip compression at the I2CP layer may substantially reduce bandwidth.
The simplest implementation at the requesting router is to use
the average, minimum, and/or maximum bandwidths of current tunnels in the pool
to calculate the values to put in the request.
More complex algorithms are possible and are up to the implementer.
There are no current I2CP or SAM options defined for the client to tell the
router what bandwidth is required, and no new options are proposed here.
Implementations may use available bandwidth or any other data, algorithm, local policy,
or local configuration to calculate the bandwidth value returned in the
build response. Not specified by this proposal.
This proposal does not require participating hops to implement per-tunnel or global
throttling of any type, or specify a particular algorithm or implementation, if any.
This proposal also does not require client routers to throttle traffic
to the limit returned by the participating hop, and depending on application,
that may not be possible, particularly for inbound tunnels.
Security Analysis
=================
Client fingerprinting based on requests.
The client (originating) router may wish to randomize the "m" and "r" values instead of sending
the same value to each hop; or send a limited set values that represent bandwidth "buckets",
or some combination of both.
Avoid over-allocation ddos.
Compatibility
===============
No issues. All known implementations currently ignore the mapping field in build messages,
and correctly skip over a non-empty options field.
Migration
=========
Implementations may add support at any time, no coordination is needed.
References
==========
.. [Tunnel-Creation-ECIES]
{{ spec_url('tunnel-creation-ecies') }}