diff --git a/i2p2www/pages/site/get-involved/roadmap.html b/i2p2www/pages/site/get-involved/roadmap.html
index f4b9c2cd2593b281c657f108015bf7a6fb6c26c2..803b5fe17fe7d7c9b113b95d6e5195624a8280fe 100644
--- a/i2p2www/pages/site/get-involved/roadmap.html
+++ b/i2p2www/pages/site/get-involved/roadmap.html
@@ -1,6 +1,6 @@
{% extends "global/layout.html" %}
{% block title %} {{ _('Roadmap') }}{% endblock %}
-{% block lastupdated %}2022-11{% endblock %} {% block content %}
+{% block lastupdated %}2024-01{% endblock %} {% block content %}
<p>
This is the official project roadmap for the desktop and Android Java I2P releases only. Some related tasks for resources such as the website and plugins may be included.
@@ -15,8 +15,8 @@
Older releases are at the bottom of the page.
</p>
-<h2 id="2.5.0">2.5.0 (API 0.9.61)</h2>
-<p><b>Target release: September 2023</b></p>
+<h2 id="2.5.0">2.5.0 (API 0.9.62)</h2>
+<p><b>Target release: April 2024</b></p>
<ul>
<li>
"Install Plugin from File" command-line option
@@ -27,10 +27,46 @@
<li>
Website Migration
</li>
+ <li>
+ Console iframe improvements
+ </li>
+ <li>
+ Reduce memory usage for netdb
+ </li>
+ <li>
+ Redesign i2psnark bandwidth limiter
+ </li>
+ <li>
+ Javascript drag-and-drop for i2psnark and susimail
+ </li>
+ <li>
+ i2ptunnel SSL error handling improvements
+ </li>
+ <li>
+ i2ptunnel persistent HTTP connection support
+ </li>
+ <li>
+ Start removing SSU1 code
+ </li>
+ <li>
+ SSU2 relay tag request handling improvements
+ </li>
+ <li>
+ susimail initial loading speedup
+ </li>
+ <li>
+ susimail javascript markdown for plain text emails
+ </li>
+ <li>
+ susimail HTML email support
+ </li>
+ <li>
+ tunnnel peer selection adjustments
+ </li>
</ul>
-<h2 id="2.4.0">2.4.0 (API 0.9.60)</h2>
-<p><b>Target release: September 2023</b></p>
+<h2 id="2.4.0">2.4.0 (API 0.9.61)</h2>
+<p><b>Released: December 18, 2023</b></p>
<ul>
<li>
NetDB context management/Segmented NetDB
@@ -41,10 +77,31 @@
<li>
Revive Android helper library
</li>
+ <li>
+ i2psnark local torrent file selector
+ </li>
+ <li>
+ NetDB lookup handler fixes
+ </li>
+ <li>
+ Disable SSU1
+ </li>
+ <li>
+ Ban routers publishing in the future
+ </li>
+ <li>
+ SAM fixes
+ </li>
+ <li>
+ susimail fixes
+ </li>
+ <li>
+ UPnP fixes
+ </li>
</ul>
<h2 id="2.3.0">2.3.0 (API 0.9.59)</h2>
-<p><b>Target release: June 2023</b></p>
+<p><b>Released: June 28, 2023</b></p>
<ul>
<li>
Tunnel peer selection improvements
@@ -66,8 +123,16 @@
</li>
</ul>
+<h2 id="2.2.1">2.2.1 (API 0.9.58)</h2>
+<p><b>Released: April 12, 2023</b></p>
+<ul>
+ <li>
+ Packaging fixes
+ </li>
+</ul>
+
<h2 id="2.2.0">2.2.0 (API 0.9.58)</h2>
-<p><b>Target release: April 2023</b></p>
+<p><b>Released: March 13, 2023</b></p>
<ul>
<li>
Tunnel peer selection improvements
diff --git a/i2p2www/spec/ntcp2.rst b/i2p2www/spec/ntcp2.rst
index cd9b239294910274037e0ff95e58a6db8b2d894a..eca46bda548002e65ec33b3a5011d61b9ab25883 100644
--- a/i2p2www/spec/ntcp2.rst
+++ b/i2p2www/spec/ntcp2.rst
@@ -3,8 +3,8 @@ NTCP 2
======
.. meta::
:category: Transports
- :lastupdated: 2022-12
- :accuratefor: 0.9.56
+ :lastupdated: 2024-01
+ :accuratefor: 0.9.61
.. contents::
@@ -1383,6 +1383,14 @@ Raw contents
{% endhighlight %}
+Notes
+`````
+- As the receiver must get the entire frame to check the MAC,
+ it is recommended that the sender limit frames to a few KB
+ rather than maximizing the frame size.
+ This will minimize latency at the receiver.
+
+
Unencrypted data
````````````````
diff --git a/i2p2www/spec/proposals/165-ssu2-fix.rst b/i2p2www/spec/proposals/165-ssu2-fix.rst
new file mode 100644
index 0000000000000000000000000000000000000000..6fd4489203e66881f1e33f6f3dd5697d90fbb369
--- /dev/null
+++ b/i2p2www/spec/proposals/165-ssu2-fix.rst
@@ -0,0 +1,169 @@
+===========================
+I2P proposal #165: SSU2 fix
+===========================
+.. meta::
+ :author: weko, orignal, the Anonymous, zzz
+ :created: 2024-01-19
+ :thread: http://i2pforum.i2p/viewforum.php?f=13
+ :lastupdated: 2024-01-19
+ :status: Open
+ :target: 0.9.62
+
+.. contents::
+
+
+
+Proposal by weko, orignal, the Anonymous and zzz.
+
+
+Overview
+--------
+
+Suggesting changes in SSU2 after the attack on I2P that used SSU2’s
+problem.
+
+
+Threat model
+------------
+
+An attacker creates new fake RIs (router doesn’t exist): is regular RI,
+but he puts address, port, s and i keys from real Bob’s router, then he
+floods the network. When we are trying to connect to this (as we think
+real) router, we, as Alice can connect to this address, but we can’t be
+sure what done it with real Bob’s RI. This is possible and was used for
+a Distributed Denial of Service attack (make big amount of such RIs and
+flood the network), also this can make de-anon attacks easier by framing
+good routers and do not framing attacker’s routers, if we ban IP with
+many RIs (instead better distrubute tunnel building to this RIs as to
+one router).
+
+
+Potential fixes
+---------------
+
+1. Fix with support for old (before the change) routers
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _overview-1:
+
+Overview
+^^^^^^^^
+
+A workaround to support SSU2 connections with old routers.
+
+Behavivor
+^^^^^^^^^
+
+Bob’s router profile should have ‘verified’ flag, it’s false by default
+for all new routers (with no profile yet). When ‘verified’ flag is
+false, we never do connections with SSU2 as Alice to Bob - we can’t be
+sure in RI. If Bob connected to us (Alice) with NTCP2 or SSU2 or we
+(Alice) connected to Bob with NTCP2 once (we can verify Bob’s
+RouterIdent in these cases) - flag is set to true.
+
+Problems
+^^^^^^^^
+
+So, there is a problem with fake SSU2-only RI flood: we can’t verify it
+by ourselves and are forced to wait when the real router will make
+connections with us.
+
+2. Verify RouterIdent during connection creation
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _overview-2:
+
+Overview
+^^^^^^^^
+
+Add “RouterIdent” block for SessionRequest and SessionCreated.
+
+Possible format of RouterIdent block
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+1 byte flags, 32 bytes RouterIdent. Flag_0: 0 if receiver’s RouterIdent;
+1 if sender’s RouterIdent
+
+Behavior
+^^^^^^^^
+
+Alice (should(1), can(2)) send in payload RouterIdent block Flag_0 = 0
+and Bob’s RouterIdent. Bob (should(3), can(4)) check if is it his
+RouterIdent, and if not: terminate the session with “Wrong RouterIdent”
+reason, if it is his RouterIdent: send RI block with 1 in Flag_0 and
+Bob’s RouterIdent.
+
+With (1) Bob does not support old routers. With (2) Bob supports old
+routers, but can be a victim of DDoS from routers that are trying to
+make connection with fake RIs. With (3) Alice does not support old
+routers. With (4) Alice supports old routers and is using a hybrid
+scheme: Fix 1 for old routers and Fix 2 for new routers. If RI says new
+version, but while in the connection we didnt’s recieve the RouterIdent
+block - terminate and remove RI.
+
+.. _problems-1:
+
+Problems
+^^^^^^^^
+
+An attacker can mask his fake routers as old, and with (4) we are
+waiting for ‘verified’ as in fix 1 anyways.
+
+Notes
+^^^^^
+
+Instead of 32 byte RouterIdent, we can probably use 4 byte
+siphash-of-the-hash, some HKDF or something else, which must be
+sufficient.
+
+3. Bob sets i = RouterIdent
+~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+.. _overview-3:
+
+Overview
+^^^^^^^^
+
+Bob uses his RouterIdent as i key.
+
+.. _behavior-1:
+
+Behavior
+^^^^^^^^
+
+Bob (should(1), can(2)) uses his own RouterIdent as i key for SSU2.
+
+Alice with (1) connects only if i = Bob’s RouterIdent. Alice with (2)
+uses the hybrid scheme (fix 3 and 1): if i = Bob’s RouterIdent, we can
+make the connection, otherwise we should verify it first (see fix 1).
+
+With (1) Alice does not support old routers. With (2) Alice supports old
+routers.
+
+.. _problems-2:
+
+Problems
+^^^^^^^^
+
+An attacker can mask his fake routers as old, and with (2) we are
+waiting for ‘verified’ as in fix 1 anyways.
+
+.. _notes-1:
+
+Notes
+^^^^^
+
+To save on RI size, better add handling if i key isn’t specified. If it
+is, then i = RouterIdent. In that case, Bob does not support old
+routers.
+
+Backward compability
+--------------------
+
+Described in fixes.
+
+
+Current status
+--------------
+
+i2pd: Fix 1.