From dc6608837506efc7cc21b227f305aec02eaa8266 Mon Sep 17 00:00:00 2001
From: str4d <str4d@mail.i2p>
Date: Thu, 31 Jan 2013 11:40:21 +0000
Subject: [PATCH] Added translation tags to docs/how/threat-model

---
 i2p2www/pages/site/docs/how/threat-model.html | 857 +++++++++++-------
 1 file changed, 506 insertions(+), 351 deletions(-)

diff --git a/i2p2www/pages/site/docs/how/threat-model.html b/i2p2www/pages/site/docs/how/threat-model.html
index 5ab111bf..09d3c402 100644
--- a/i2p2www/pages/site/docs/how/threat-model.html
+++ b/i2p2www/pages/site/docs/how/threat-model.html
@@ -1,65 +1,82 @@
 {% extends "global/layout.html" %}
-{% block title %}I2P's Threat Model{% endblock %}
-{% block lastupdated %}November 2010{% endblock %}
+{% block title %}{% trans %}I2P's Threat Model{% endtrans %}{% endblock %}
+{% block lastupdated %}{% trans %}November 2010{% endtrans %}{% endblock %}
 {% block accuratefor %}0.8.1{% endblock %}
 {% block content %}
-<h2>What do we mean by "anonymous"?</h2>
+<h2>{% trans %}What do we mean by "anonymous"?{% endtrans %}</h2>
 
-<p>Your level of anonymity can be described as "how hard it is for someone
+<p>{% trans -%}
+Your level of anonymity can be described as "how hard it is for someone
 to find out information you don't want them to know?" - who you are, where
 you are located, who you communicate with, or even when you communicate.  
 "Perfect" anonymity is not a useful concept here - software will not make 
 you indistinguishable from people that don't use computers or who are not on
 the Internet.  Instead, we are working to provide sufficient anonymity to meet the
 real needs of whomever we can - from those simply browsing websites, to those exchanging
-data, to those fearful of discovery by powerful organizations or states.</p>
+data, to those fearful of discovery by powerful organizations or states.
+{%- endtrans %}</p>
   
-<p>The question of whether I2P provides sufficient anonymity for your 
+<p>{% trans -%}
+The question of whether I2P provides sufficient anonymity for your 
 particular needs is a hard one, but this page will hopefully assist in 
 answering that question by exploring how I2P operates under various attacks
-so that you may decide whether it meets your needs.</p>
+so that you may decide whether it meets your needs.
+{%- endtrans %}</p>
 
-<p>We welcome further research and analysis on I2P's resistance to the threats described below.
+<p>{% trans -%}
+We welcome further research and analysis on I2P's resistance to the threats described below.
 More review of existing literature (much of it focused on Tor) and original
-work focused on I2P is needed.</p>
+work focused on I2P is needed.
+{%- endtrans %}</p>
 
-<h2>Network Topology Summary</h2>
-<p>I2P builds off the ideas of many <a href="{{ site_url('docs/how/networkcomparisons') }}">other</a> 
-<a href="links">systems</a>, but a few key points should be kept in mind when 
-reviewing related literature:</p><ul>
-<li><b>I2P is a free route mixnet</b> - the message creator explicitly defines the
-    path that messages will be sent out (the outbound tunnel), and the message 
-    recipient explicitly defines the path that messages will be received on (the
-    inbound tunnel).
-</li>
-<li><b>I2P has no official entry and exit points</b> - all peers fully participate in the 
-    mix, and there are no network layer in- or out-proxies (however, at the 
-    application layer, a few proxies do exist)</li>
-<li><b>I2P is fully distributed</b> - there are no central controls or authorities.
-    One could modify some routers to operate mix cascades (building tunnels and giving
-    out the keys necessary to control the forwarding at the tunnel endpoint) or directory 
-    based profiling and selection, all without breaking compatibility with the rest of 
-    the network, but doing so is of course not necessary (and may even harm one's
-    anonymity).</li>
+<h2>{% trans %}Network Topology Summary{% endtrans %}</h2>
+<p>{% trans comparisons=site_url('comparison'), links=site_url('links') -%}
+I2P builds off the ideas of many <a href="{{ comparisons }}">other</a> 
+<a href="{{ links }}">systems</a>, but a few key points should be kept in mind when 
+reviewing related literature:
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
+<b>I2P is a free route mixnet</b> - the message creator explicitly defines the
+path that messages will be sent out (the outbound tunnel), and the message 
+recipient explicitly defines the path that messages will be received on (the
+inbound tunnel).
+{%- endtrans %}</li>
+<li>{% trans -%}
+<b>I2P has no official entry and exit points</b> - all peers fully participate in the 
+mix, and there are no network layer in- or out-proxies (however, at the 
+application layer, a few proxies do exist)
+{%- endtrans %}</li>
+<li>{% trans -%}
+<b>I2P is fully distributed</b> - there are no central controls or authorities.
+One could modify some routers to operate mix cascades (building tunnels and giving
+out the keys necessary to control the forwarding at the tunnel endpoint) or directory 
+based profiling and selection, all without breaking compatibility with the rest of 
+the network, but doing so is of course not necessary (and may even harm one's
+anonymity).
+{%- endtrans %}</li>
 </ul>
-<p>
-   We have documented plans to implement
-    <a href="todo#stop">nontrivial delays</a> and <a href="todo#batching">batching strategies</a> 
-    whose existence is only known to the particular hop or tunnel gateway that 
-    receives the message, allowing a mostly low latency mixnet to provide cover 
-    traffic for higher latency communication (e.g. email).
-   However we are aware that significant delays are required to provide meaningful
-   protection, and that implementation of such delays will be a significant challenge.
-   It is not clear at this time whether we will actually implement these delay features.
-</p><p>
-  In theory, routers along the message path may inject an 
-    arbitrary number of hops before forwarding the message to the next peer, though
-    the current implementation does not.
-</p>
+
+<p>{% trans todo=site_url('get-involved/todo') -%}
+We have documented plans to implement <a href="{{ todo }}#stop">nontrivial delays</a>
+and <a href="{{ todo }}#batching">batching strategies</a> 
+whose existence is only known to the particular hop or tunnel gateway that 
+receives the message, allowing a mostly low latency mixnet to provide cover 
+traffic for higher latency communication (e.g. email).
+However we are aware that significant delays are required to provide meaningful
+protection, and that implementation of such delays will be a significant challenge.
+It is not clear at this time whether we will actually implement these delay features.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+In theory, routers along the message path may inject an 
+arbitrary number of hops before forwarding the message to the next peer, though
+the current implementation does not.
+{%- endtrans %}</p>
 
 
-<h2>The Threat Model (Attacks)</h2>
-<p>
+<h2>{% trans %}The Threat Model (Attacks){% endtrans %}</h2>
+<p>{% trans -%}
 I2P design started in 2003, not long after the advent of
 <a href="http://www.onion-router.net">[Onion Routing]</a>,
 <a href="http://freenetproject.org/">[Freenet]</a>, and
@@ -67,18 +84,24 @@ I2P design started in 2003, not long after the advent of
 Our design benefits substantially from the research published around that time.
 I2P uses several onion routing techniques, so we continue to benefit
 from the significant academic interest in Tor.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Taking from the attacks and analysis put forth in the 
 <a href="http://freehaven.net/anonbib/topic.html">anonymity literature</a> (largely 
 <a href="http://citeseer.ist.psu.edu/454354.html">Traffic Analysis: Protocols, Attacks, Design 
 Issues and Open Problems</a>), the following briefly describes a wide variety 
 of attacks as well as many of I2Ps defenses.  We update
 this list to include new attacks as they are identified.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Included are some attacks that may be unique to I2P.
 We do not have good answers for all these attacks, however
 we continue to do research and improve our defenses.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 In addition, many of these attacks are significantly easier than
 they should be, due to the modest size of the current network.
 While we are aware of some limitations that need to be addressed,
@@ -86,38 +109,41 @@ I2P is designed to support hundreds of thousands, or millions, of
 participants.
 As we continue to spread the word and grow the network,
 these attacks will become much harder.
-</p><p>
-The
-<a href="{{ site_url('docs/how/networkcomparisons') }}">network comparisons</a> and
-<a href="{{ site_url('docs/how/garlicrouting') }}">"garlic" terminology</a> pages may also be helpful
-to review.
-</p>
+{%- endtrans %}</p>
 
-<h3 id="index">Index</h3>
+<p>{% trans comparisons=site_url('comparison'), garlicrouting=site_url('docs/how/garlic-routing') -%}
+The
+<a href="{{ comparisons }}">network comparisons</a> and
+<a href="{{ garlicrouting }}">"garlic" terminology</a> pages may also be helpful
+to review.
+{%- endtrans %}</p>
+
+<h3 id="index">{% trans %}Index{% endtrans %}</h3>
 <ul>
-<li><a href="#bruteforce">Brute force attacks</a></li>
-<li><a href="#timing">Timing attacks</a></li>
-<li><a href="#intersection">Intersection attacks</a></li>
-<li><a href="#dos">Denial of service attacks</a></li>
-<li><a href="#tagging">Tagging attacks</a></li>
-<li><a href="#partitioning">Partitioning attacks</a></li>
-<li><a href="#predecessor">Predecessor attacks</a></li>
-<li><a href="#harvesting">Harvesting attacks</a></li>
-<li><a href="#traffic">Identification Through Traffic Analysis</a></li>
-<li><a href="#sybil">Sybil attacks</a></li>
-<li><a href="#buddy">Buddy Exhaustion attacks</a></li>
-<li><a href="#crypto">Cryptographic attacks</a></li>
-<li><a href="#floodfill">Floodfill attacks</a></li>
-<li><a href="#netdb">Other Network Database attacks</a></li>
-<li><a href="#central">Attacks on centralized resources</a></li>
-<li><a href="#dev">Development attacks</a></li>
-<li><a href="#impl">Implementation attacks</a></li>
-<li><a href="#blocklist">Other Defenses</a></li>
+<li><a href="#bruteforce">{% trans %}Brute force attacks{% endtrans %}</a></li>
+<li><a href="#timing">{% trans %}Timing attacks{% endtrans %}</a></li>
+<li><a href="#intersection">{% trans %}Intersection attacks{% endtrans %}</a></li>
+<li><a href="#dos">{% trans %}Denial of service attacks{% endtrans %}</a></li>
+<li><a href="#tagging">{% trans %}Tagging attacks{% endtrans %}</a></li>
+<li><a href="#partitioning">{% trans %}Partitioning attacks{% endtrans %}</a></li>
+<li><a href="#predecessor">{% trans %}Predecessor attacks{% endtrans %}</a></li>
+<li><a href="#harvesting">{% trans %}Harvesting attacks{% endtrans %}</a></li>
+<li><a href="#traffic">{% trans %}Identification Through Traffic Analysis{% endtrans %}</a></li>
+<li><a href="#sybil">{% trans %}Sybil attacks{% endtrans %}</a></li>
+<li><a href="#buddy">{% trans %}Buddy Exhaustion attacks{% endtrans %}</a></li>
+<li><a href="#crypto">{% trans %}Cryptographic attacks{% endtrans %}</a></li>
+<li><a href="#floodfill">{% trans %}Floodfill attacks{% endtrans %}</a></li>
+<li><a href="#netdb">{% trans %}Other Network Database attacks{% endtrans %}</a></li>
+<li><a href="#central">{% trans %}Attacks on centralized resources{% endtrans %}</a></li>
+<li><a href="#dev">{% trans %}Development attacks{% endtrans %}</a></li>
+<li><a href="#impl">{% trans %}Implementation attacks{% endtrans %}</a></li>
+<li><a href="#blocklist">{% trans %}Other Defenses{% endtrans %}</a></li>
 </ul>
 
-<h3 id="bruteforce">Brute force attacks</h3>
+<h3 id="bruteforce">{% trans %}Brute force attacks{% endtrans %}</h3>
 
-<p>A brute force attack can be mounted by a global passive or active adversary, 
+<p>{% trans -%}
+A brute force attack can be mounted by a global passive or active adversary, 
 watching all the messages pass between all of the nodes and attempting to correlate
 which message follows which path.  Mounting this attack against I2P should be 
 nontrivial, as all peers in the network are frequently sending messages (both
@@ -125,9 +151,11 @@ end to end and network maintenance messages), plus an end to end message changes
 size and data along its path.  In addition, the external adversary does not have
 access to the messages either, as inter-router communication is both encrypted
 and streamed (making two 1024 byte messages indistinguishable from one 2048 byte
-message).</p>
+message).
+{%- endtrans %}</p>
 
-<p>However, a powerful attacker can use brute force to detect trends - if they 
+<p>{% trans -%}
+However, a powerful attacker can use brute force to detect trends - if they 
 can send 5GB to an I2P destination and monitor everyone's network connection,
 they can eliminate all peers who did not receive 5GB of data.  Techniques to 
 defeat this attack exist, but may be prohibitively expensive (see: 
@@ -141,193 +169,238 @@ would want to take appropriate countermeasures, such as
 setting low bandwidth limits, and using unpublished or encrypted leasesets for eepsites.
 Other countermeasures, such as nontrivial delays and restricted routes, are
 not currently implemented.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans peerselection=site_url('docs/how/peer-selection') -%}
 As a partial defense against a single router or group of routers trying to route all the network's traffic,
 routers contain limits as to how many tunnels can be routed through a single peer.
 As the network grows, these limits are subject to further adjustment.
 Other mechanisms for peer rating, selection and avoidance
 are discussed on the
-<a href="{{ site_url('docs/how/peerselection') }}">peer selection page</a>.
-</p>
+<a href="{{ peerselection }}">peer selection page</a>.
+{%- endtrans %}</p>
 
 
 
-<h3 id="timing">Timing attacks</h3>
+<h3 id="timing">{% trans %}Timing attacks{% endtrans %}</h3>
 
-<p>I2P's messages are unidirectional and do not necessarily imply that a reply
+<p>{% trans -%}
+I2P's messages are unidirectional and do not necessarily imply that a reply
 will be sent.  However, applications on top of I2P will most likely have
 recognizable patterns within the frequency of their messages - for instance, an 
 HTTP request will be a small message with a large sequence of reply messages 
 containing the HTTP response.  Using this data as well as a broad view of the 
 network topology, an attacker may be able to disqualify some links as being too 
-slow to have passed the message along.</p>
+slow to have passed the message along.
+{%- endtrans %}</p>
 
-<p>This sort of attack is powerful, but its applicability to I2P is non obvious,
+<p>{% trans -%}
+This sort of attack is powerful, but its applicability to I2P is non obvious,
 as the variation on message delays due to queuing, message processing, and 
 throttling will often meet or exceed the time of passing a message along a 
 single link - even when the attacker knows that a reply will be sent as soon as
 the message is received.  There are some scenarios which will expose fairly 
 automatic replies though - the streaming library does (with the SYN+ACK) as does the 
-message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).</p>
+message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).
+{%- endtrans %}</p>
 
-<p>Without protocol scrubbing or higher latency, global active adversaries can 
+<p>{% trans todo=site_url('get-involved/todo') -%}
+Without protocol scrubbing or higher latency, global active adversaries can 
 gain substantial information.  As such, people concerned with these attacks could
-increase the latency (using <a href="todo#stop">nontrivial delays</a> or 
-<a href="todo#batching">batching strategies</a>), include protocol scrubbing, or
-other advanced tunnel routing <a href="todo#batching">techniques</a>,
+increase the latency (using <a href="{{ todo }}#stop">nontrivial delays</a> or 
+<a href="{{ todo }}#batching">batching strategies</a>), include protocol scrubbing, or
+other advanced tunnel routing <a href="{{ todo }}#batching">techniques</a>,
 but these are unimplemented in I2P.
-</p>
+{%- endtrans %}</p>
 
-<p>References:
-<a href="http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf">Low-Resource Routing Attacks Against Anonymous Systems</a>
-</p>
+<p>{% trans pdf='http://www.cs.colorado.edu/department/publications/reports/docs/CU-CS-1025-07.pdf' -%}
+References: <a href="{{ pdf }}">Low-Resource Routing Attacks Against Anonymous Systems</a>
+{%- endtrans %}</p>
 
-<h3 id="intersection">Intersection attacks</h3>
+<h3 id="intersection">{% trans %}Intersection attacks{% endtrans %}</h3>
 
-<p>Intersection attacks against low latency systems are extremely powerful -
+<p>{% trans -%}
+Intersection attacks against low latency systems are extremely powerful -
 periodically make contact with the target and keep track of what peers are on
 the network.  Over time, as node churn occurs the attacker will gain 
 significant information about the target by simply intersecting the sets of
 peers that are online when a message successfully goes through.  The cost of 
 this attack is significant as the network grows, but may be feasible in some
-scenarios.</p>
-  
-<p>
+scenarios.
+{%- endtrans %}</p>
+
+<p>{% trans url='https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting' -%}
 In summary, if an attacker is at both ends of your tunnel at the same time,
 he may be successful.
 I2P does not have a full defense to this for low latency communication.
 This is an inherent weakness of low-latency onion routing.
-Tor provides a <a href="https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#Whatattacksremainagainstonionrouting">similar disclaimer</a>.
-</p><p>
+Tor provides a <a href="{{ url }}">similar disclaimer</a>.
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Partial defenses implemented in I2P:
-<ul><li>
-<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
-</li><li>
-<a href="{{ site_url('docs/how/peerselection') }}">peer profiling and selection</a> from a small group that changes slowly
-</li><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans tunnelimpl=site_url('docs/tunnels/implementation') -%}
+<a href="{{ tunnelimpl }}#ordering">strict ordering</a> of peers
+{%- endtrans %}</li>
+<li>{% trans peerselection=site_url('docs/how/peer-selection') -%}
+<a href="{{ peerselection }}">peer profiling and selection</a> from a small group that changes slowly
+{%- endtrans %}</li>
+<li>{% trans -%}
 Limits on the number of tunnels routed through a single peer
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Prevention of peers from the same /16 IP range from being members of a single tunnel
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 For eepsites or other hosted services, we support
 simultaneous hosting on multiple routers, or
-<a href="{{ site_url('docs/how/threatmodel') }}#intersection">multihoming</a>
-</li></ul>
+<a href="#intersection">multihoming</a>
+{%- endtrans %}</li>
+</ul>
 
+<p>{% trans -%}
 Even in total, these defenses are not a complete solution.
 Also, we have made some design choices that may significantly increase our vulnerability:
-<ul><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
 We do not use low-bandwidth "guard nodes"
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Tunnels are not long-lived; new tunnels are built every 10 minutes.
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Tunnel lengths are configurable.
 While 3-hop tunnels are recommended for full protection, several applications and
 services use 2-hop tunnels by default.
-</li></ul>
+{%- endtrans %}</li>
+</ul>
 
-
-</p><p>
+<p>{% trans todo=site_url('get-involved/todo') -%}
 In the future, it could
-for peers who can afford significant delays (per <a href="todo#stop">nontrivial 
-delays</a> and <a href="todo#batching">batching strategies</a>).  In addition,
+for peers who can afford significant delays (per <a href="{{ todo }}#stop">nontrivial
+delays</a> and <a href="{{ todo }}#batching">batching strategies</a>).  In addition,
 this is only relevant for destinations that other people know about - a private
 group whose destination is only known to trusted peers does not have to worry,
 as an adversary can't "ping" them to mount the attack.</p>
+{%- endtrans %}</p>
 
-<p>Reference:
-<a href="http://blog.torproject.org/blog/one-cell-enough">One Cell Enough</a>
-</p>
+<p>{% trans oce='http://blog.torproject.org/blog/one-cell-enough' -%}
+Reference: <a href="{{ oce }}">One Cell Enough</a>
+{%- endtrans %}</p>
 
 
+<h3 id="dos">{% trans %}Denial of service attacks{% endtrans %}</h3>
 
-<h3 id="dos">Denial of service attacks</h3>
-
-<p>There are a whole slew of denial of service attacks available against I2P,
-each with different costs and consequences:</p><ul>
-<li><b>Greedy user attack:</b> This is simply
-    people trying to consume significantly more resources than they are 
-    willing to contribute.  The defense against this is:<ul>
-    <li>Set defaults so that most users provide resources to the network.
-    In I2P, users route traffic by default. In sharp distinction to
-    <a href="https://torproject.org/">other networks</a>,
-    over 95% of I2P users relay traffic for others.
-   </li>
-    <li>Provide easy configuration options so that users may increase their
-    contribution (share percentage) to the network. Display easy-to-understand
-    metrics such as "share ratio" so that users may see what they are contributing.
-   </li><lil>
-     Maintain a strong community with blogs, forums, IRC, and other means of communication.
-   </li></ul>
-<li><b>Starvation attack:</b> A hostile user may attempt to harm the network by
-    creating a significant number of peers in the network who are not identified as
-    being under control of the same entity (as with Sybil).  These nodes then 
-    decide not to provide any resources to the network, causing existing peers 
-    to search through a larger network database or request more tunnels than 
-    should be necessary. 
-    Alternatively, the nodes may provide intermittent service by periodically
-    dropping selected traffic, or refusing connections to certain peers.
-    This behavior may be indistinguishable from that of a heavily-loaded or failing node.
-    I2P addresses these issues by maintaining <a href="{{ site_url('docs/how/peerselection') }}">profiles</a> on the 
-    peers, attempting to identify underperforming ones and simply ignoring 
-    them, or using them rarely.
-    We have significantly enhanced the
-    ability to recognize and avoid troublesome peers; however there are still
-    significant efforts required in this area.
-</li>
-<li><b>Flooding attack:</b> A hostile user may attempt to flood the network,
-    a peer, a destination, or a tunnel.  Network and peer flooding is possible,
-    and I2P does nothing to prevent standard IP layer flooding.  The flooding of
-    a destination with messages by sending a large number to the target's various
-    inbound tunnel gateways is possible, but the destination will know this both
-    by the contents of the message and because the tunnel's tests will fail.  The
-    same goes for flooding just a single tunnel.  I2P has no defenses for a network
-    flooding attack.  For a destination and tunnel flooding attack, the target
-    identifies which tunnels are unresponsive and builds new ones.  New code could
-    also be written to add even more tunnels if the client wishes to handle the
-    larger load.  If, on the other hand, the load is more than the client can
-    deal with, they can instruct the tunnels to throttle the number of messages or
-    bytes they should pass on (once the <a href="todo#batching">advanced tunnel
-    operation</a> is implemented).</li>
-<li><b>CPU load attack:</b> There are currently some methods for people to 
-    remotely request that a peer perform some cryptographically expensive 
-    operation, and a hostile attacker could use these to flood that peer with
-    a large number of them in an attempt to overload the CPU.  Both using good 
-    engineering practices and potentially requiring nontrivial certificates 
-    (e.g. HashCash) to be attached to these expensive requests should mitigate
-    the issue, though there may be room for an attacker to exploit various
-    bugs in the implementation.</li>
-<li id="ffdos"><b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
-    becoming a floodfill router. The current defenses against unreliable,
-    intermittent, or malicious floodfill routers are poor.
-    A floodfill router may provide bad or no response to lookups, and
-    it may also interfere with inter-floodfill communication.
-    Some defenses and
-    <a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> are implemented,
-    however there is much more to do.
-    For more information see the
-    <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
+<p>{% trans -%}
+There are a whole slew of denial of service attacks available against I2P,
+each with different costs and consequences:
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
+<b>Greedy user attack:</b> This is simply
+people trying to consume significantly more resources than they are 
+willing to contribute. The defense against this is:
+{%- endtrans %}
+  <ul>
+  <li>{% trans comparisons=site_url('comparison') -%}
+Set defaults so that most users provide resources to the network.
+In I2P, users route traffic by default. In sharp distinction to
+<a href="{{ comparisons }}">other networks</a>,
+over 95% of I2P users relay traffic for others.
+{%- endtrans %}</li>
+  <li>{% trans -%}
+Provide easy configuration options so that users may increase their
+contribution (share percentage) to the network. Display easy-to-understand
+metrics such as "share ratio" so that users may see what they are contributing.
+{%- endtrans %}</li>
+  <li>{% trans -%}
+Maintain a strong community with blogs, forums, IRC, and other means of communication.
+{%- endtrans %}</li>
+  </ul>
 </li>
+<li>{% trans peerselection=site_url('docs/how/peer-selection') -%}
+<b>Starvation attack:</b> A hostile user may attempt to harm the network by
+creating a significant number of peers in the network who are not identified as
+being under control of the same entity (as with Sybil). These nodes then 
+decide not to provide any resources to the network, causing existing peers 
+to search through a larger network database or request more tunnels than 
+should be necessary. 
+Alternatively, the nodes may provide intermittent service by periodically
+dropping selected traffic, or refusing connections to certain peers.
+This behavior may be indistinguishable from that of a heavily-loaded or failing node.
+I2P addresses these issues by maintaining <a href="{{ peerselection }}">profiles</a> on the 
+peers, attempting to identify underperforming ones and simply ignoring 
+them, or using them rarely.
+We have significantly enhanced the
+ability to recognize and avoid troublesome peers; however there are still
+significant efforts required in this area.
+{%- endtrans %}</li>
+<li>{% trans todo=site_url('get-involved/todo') -%}
+<b>Flooding attack:</b> A hostile user may attempt to flood the network,
+a peer, a destination, or a tunnel.  Network and peer flooding is possible,
+and I2P does nothing to prevent standard IP layer flooding.  The flooding of
+a destination with messages by sending a large number to the target's various
+inbound tunnel gateways is possible, but the destination will know this both
+by the contents of the message and because the tunnel's tests will fail.  The
+same goes for flooding just a single tunnel.  I2P has no defenses for a network
+flooding attack.  For a destination and tunnel flooding attack, the target
+identifies which tunnels are unresponsive and builds new ones.  New code could
+also be written to add even more tunnels if the client wishes to handle the
+larger load.  If, on the other hand, the load is more than the client can
+deal with, they can instruct the tunnels to throttle the number of messages or
+bytes they should pass on (once the <a href="{{ todo }}#batching">advanced tunnel
+operation</a> is implemented).
+{%- endtrans %}</li>
+<li>{% trans -%}
+<b>CPU load attack:</b> There are currently some methods for people to 
+remotely request that a peer perform some cryptographically expensive 
+operation, and a hostile attacker could use these to flood that peer with
+a large number of them in an attempt to overload the CPU.  Both using good 
+engineering practices and potentially requiring nontrivial certificates 
+(e.g. HashCash) to be attached to these expensive requests should mitigate
+the issue, though there may be room for an attacker to exploit various
+bugs in the implementation.
+{%- endtrans %}</li>
+<li id="ffdos">{% trans peerselection=site_url('docs/how/peer-selection'),
+netdb=site_url('docs/how/network-database') -%}
+<b>Floodfill DOS attack:</b> A hostile user may attempt to harm the network by
+becoming a floodfill router. The current defenses against unreliable,
+intermittent, or malicious floodfill routers are poor.
+A floodfill router may provide bad or no response to lookups, and
+it may also interfere with inter-floodfill communication.
+Some defenses and
+<a href="{{ peerselection }}">peer profiling</a> are implemented,
+however there is much more to do.
+For more information see the
+<a href="{{ netdb }}#threat">network database page</a>.
+{%- endtrans %}</li>
 </ul>
 
-<h3 id="tagging">Tagging attacks</h3>
-<p>Tagging attacks - modifying a message so that it can later be identified 
+<h3 id="tagging">{% trans %}Tagging attacks{% endtrans %}</h3>
+<p>{% trans todo=site_url('get-involved/todo') -%}
+Tagging attacks - modifying a message so that it can later be identified 
 further along the path - are by themselves impossible in I2P, as messages 
 passed through tunnels are signed.  However, if an attacker is the inbound 
 tunnel gateway as well as a participant further along in that tunnel, with
 collusion they can identify the fact that they are in the same tunnel (and 
-prior to adding <a href="todo#tunnelId">unique hop ids</a> and other updates,
+prior to adding <a href="{{ todo }}#tunnelId">unique hop ids</a> and other updates,
 colluding peers within the same tunnel can recognize that fact without any 
 effort).  An attacker in an outbound tunnel and any part of an inbound tunnel cannot 
 collude however, as the tunnel encryption pads and modifies the data separately
 for the inbound and outbound tunnels.  External attackers cannot do anything,
-as the links are encrypted and messages signed.</p>
+as the links are encrypted and messages signed.
+{%- endtrans %}</p>
 
-<h3 id="partitioning">Partitioning attacks</h3>
+<h3 id="partitioning">{% trans %}Partitioning attacks{% endtrans %}</h3>
 
-<p>Partitioning attacks - finding ways to segregate (technically or analytically)
+<p>{% trans -%}
+Partitioning attacks - finding ways to segregate (technically or analytically)
 the peers in a network - are important to keep in mind when dealing with a 
 powerful adversary, since the size of the network plays a key role in determining
 your anonymity.  Technical partitioning by cutting links between peers to create
@@ -339,142 +412,177 @@ isolating the target, no amount of network database healing will fix it.  At
 that point, the only thing the router can hope to do is notice that a significant
 number of previously reliable peers have become unavailable and alert the client
 that it is temporarily disconnected (this detection code is not implemented at
-the moment).</p>
+the moment).
+{%- endtrans %}</p>
 
-<p>Partitioning the network analytically by looking for differences in how routers 
+<p>{% trans todo=site_url('get-involved/todo') -%}
+Partitioning the network analytically by looking for differences in how routers 
 and destinations behave and grouping them accordingly is also a very powerful
 attack.  For instance, an attacker <a href="#harvesting">harvesting</a> the network
 database will know when a particular destination has 5 inbound tunnels in their
 LeaseSet while others have only 2 or 3, allowing the adversary to potentially 
 partition clients by the number of tunnels selected.  Another partition is 
-possible when dealing with the <a href="todo#stop">nontrivial delays</a> and 
-<a href="todo#batching">batching strategies</a>, as the tunnel gateways and the
+possible when dealing with the <a href="{{ todo }}#stop">nontrivial delays</a> and 
+<a href="{{ todo }}#batching">batching strategies</a>, as the tunnel gateways and the
 particular hops with non-zero delays will likely stand out.  However, this data
 is only exposed to those specific hops, so to partition effectively on that 
 matter, the attacker would need to control a significant portion of the network
 (and still that would only be a probabilistic partition, as they wouldn't know
 which other tunnels or messages have those delays).
-</p><p>
-Also discussed on the
-    <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a> (bootstrap attack).
-</p>
+{%- endtrans %}</p>
 
-<h3 id="predecessor">Predecessor attacks</h3>
+<p>{% trans netdb=site_url('docs/how/networkdatabase') -%}
+Also discussed on the <a href="{{ netdb }}#threat">network database page</a> (bootstrap attack).
+{%- endtrans %}</p>
 
-<p>The predecessor attack is passively gathering statistics in an attempt to see
+<h3 id="predecessor">{% trans %}Predecessor attacks{% endtrans %}</h3>
+
+<p>{% trans -%}
+The predecessor attack is passively gathering statistics in an attempt to see
 what peers are 'close' to the destination by participating in their tunnels and
 keeping track of the previous or next hop (for outbound or inbound tunnels, 
 respectively).  Over time, using a perfectly random sample of peers and random
 ordering, an attacker would be able to see which peer shows up as 'closer' 
 statistically more than the rest, and that peer would in turn be where the
-target is located.  </p>
+target is located.
+{%- endtrans %}</p>
 
-<p>I2P avoids this in four ways: first, the peers selected to participate in
+<p>{% trans peerselection=site_url('docs/how/peer-selection'),
+tunnelimpl=site_url('docs/tunnels/implementation'),
+todo=site_url('get-involved/todo') -%}
+I2P avoids this in four ways: first, the peers selected to participate in
 tunnels are not randomly sampled throughout the network - they are derived from
-the <a href="{{ site_url('docs/how/peerselection') }}">peer selection</a> algorithm which breaks them
-into tiers.  Second, with <a href="tunnel-alt.html#ordering">strict ordering</a> of peers
+the <a href="{{ peerselection }}">peer selection</a> algorithm which breaks them
+into tiers.  Second, with <a href="{{ tunnelimpl }}#ordering">strict ordering</a> of peers
 in a tunnel, the fact that a peer shows up more frequently does not mean they're
-the source.  Third, with <a href="tunnel-alt.html#length">permuted tunnel length</a>
+the source.  Third, with <a href="{{ tunnelimpl }}#length">permuted tunnel length</a>
 (not enabled by default)
 even 0 hop tunnels can provide plausible deniability as the occasional 
 variation of the gateway will look like normal tunnels.  Fourth, with 
-<a href="todo#fullRestrictedRoutes">restricted routes</a> (unimplemented), only the peer with
+<a href="{{ todo }}#fullRestrictedRoutes">restricted routes</a> (unimplemented), only the peer with
 a restricted connection to the target will ever contact the target, while 
 attackers will merely run into that gateway.
-</p><p>
-The current
-<a href="tunnel-alt-creation.html">tunnel build method</a>
+{%- endtrans %}</p>
+
+<p>{% trans tunnelcreation=site_url('docs/spec/tunnel-creation') -%}
+The current <a href="{{ tunnelcreation }}">tunnel build method</a>
 was specifically designed to combat the predecessor attack.
 See also <a href="#intersection">the intersection attack</a>.
-</p>
+{%- endtrans %}</p>
 
-<p>References:
-<a href="http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf">http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf</a>
+<p>{% trans pdf2008='http://prisms.cs.umass.edu/brian/pubs/wright.tissec.2008.pdf',
+pdf2004='http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf' -%}
+References: <a href="{{ pdf2008 }}">{{ pdf2008 }}</a>
 which is an update to the 2004 predecessor attack paper
-<a href="http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf">http://prisms.cs.umass.edu/brian/pubs/wright-tissec.pdf</a>.
-</p>
+<a href="{{ pdf2004 }}">{{ pdf2004 }}</a>.
+{%- endtrans %}</p>
 
 
-<h3 id="harvesting">Harvesting attacks</h3>
-<p>
+<h3 id="harvesting">{% trans %}Harvesting attacks{% endtrans %}</h3>
+<p>{% trans -%}
 "Harvesting" means compiling a list of users running I2P.
 It can be used for legal attacks and to help
 other attacks by simply running a peer, seeing who it connects to, and 
 harvesting whatever references to other peers it can find.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 I2P itself is not designed with effective defenses against
 this attack, since there is the distributed network database 
 containing just this information.
 The following factors make the attack somewhat harder in practice:
-<ul><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
 Network growth will make it more difficult to obtain a given proportion of the network
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Floodfill routers implement query limits as DOS protection
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 "Hidden mode", which prevents a router from publishing its information to the netDb,
 (but also prevents it from relaying data) is not widely used now but could be.
-</li></ul>
+{%- endtrans %}</li>
+</ul>
+
+<p>{% trans todo=site_url('get-involved/todo') -%}
 In future implementations,
-<a href="todo#nat">basic</a> and 
-<a href="todo#fullRestrictedRoutes">comprehensive</a> restricted routes,
+<a href="{{ todo }}#nat">basic</a> and 
+<a href="{{ todo }}#fullRestrictedRoutes">comprehensive</a> restricted routes,
 this attack loses much of its power, as the "hidden" peers do not publish their
 contact addresses in the network database - only the tunnels through which 
 they can be reached (as well as their public keys, etc).
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 In the future, routers could use GeoIP to identify if they are in a particular
 country where identification as an I2P node would be risky.
 In that case, the router could automatically enable hidden mode, or
 enact other restricted route methods.
-</p>
+{%- endtrans %}</p>
 
 
-
-<h3 id="traffic">Identification Through Traffic Analysis</h3>
-<p>
+<h3 id="traffic">{% trans %}Identification Through Traffic Analysis{% endtrans %}</h3>
+<p>{% trans transport=site_url('docs/transport') -%}
 By inspecting the traffic into and out of a router, a malicious ISP
 or state-level firewall could identify that a computer is running I2P.
 As discussed <a href="#harvesting">above</a>, I2P is not specifically designed
 to hide that a computer is running I2P. However, several design decisions made
 in the design of the
-<a href="transport.html">transport layer and protocols</a>
+<a href="{{ transport }}">transport layer and protocols</a>
 make it somewhat difficult to identify I2P traffic:
-<ul><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
 Random port selection
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Point-to-Point Encryption of all traffic
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 DH key exchange with no protocol bytes or other unencrypted constant fields
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans ntcp=site_url('docs/transport/ntcp'), ssu=site_url('docs/transport/ssu') -%}
 Simultaneous use of both
-<a href="ntcp.html">TCP</a> and
-<a href="udp.html">UDP</a> transports.
+<a href="{{ ntcp }}">TCP</a> and
+<a href="{{ ssu }}">UDP</a> transports.
 UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
-</li></ul>
+{%- endtrans %}</li>
+</ul>
 
+<p>{% trans -%}
 In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
-<ul><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
 Padding at the transport layer to random lengths, especially during the connection handshake
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Study of packet size distribution signatures, and additional padding as necessary
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Development of additional transport methods that mimic SSL or other common protocols
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Review of methods implemented by various state-level firewalls to block Tor
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 Working directly with DPI and obfuscation experts
-</li></ul>
-</p><p>
-Reference:
-<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
-</p>
+{%- endtrans %}</li>
+</ul>
+
+<p>{% trans pdf='http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf' -%}
+Reference: <a href="{{ pdf }}">Breaking and Improving Protocol Obfuscation</a>
+{%- endtrans %}</p>
 
 
+<h3 id="sybil">{% trans %}Sybil attacks{% endtrans %}</h3>
 
-<h3 id="sybil">Sybil attacks</h3>
-
-<p>Sybil describes a category of attacks where the adversary creates arbitrarily
+<p>{% trans -%}
+Sybil describes a category of attacks where the adversary creates arbitrarily
 large numbers of colluding nodes and uses the increased numbers to help 
 mounting other attacks.  For instance, if an attacker is in a network where peers
 are selected randomly and they want an 80% chance to be one of those peers, they
@@ -489,39 +597,47 @@ identity.  We currently have not implemented any particular technique to address
 Sybil, but do include placeholder certificates in the router's and 
 destination's data structures which can contain a HashCash certificate of 
 appropriate value when necessary (or some other certificate proving scarcity).
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Requiring HashCash Certificates in various places has two major problems:
-<ul><li>
+{%- endtrans %}</p>
+<ul>
+<li>{% trans -%}
 Maintaining backward compatibility
-</li><li>
+{%- endtrans %}</li>
+<li>{% trans -%}
 The classic HashCash problem -
 selecting HashCash values that are meaningful proofs of work on high-end machines,
 while still being feasible on low-end machines such as mobile devices.
-</li></ul>
-</p><p>
+{%- endtrans %}</li>
+</ul>
+
+<p>{% trans -%}
 Various limitations on the number of routers in a given IP range restrict
 the vulnerability to attackers that don't have the ability to put machines
 in several IP blocks.
 However, this is not a meaningful defense against a powerful adversary.
-</p><p>
-See the
-  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>
+{%- endtrans %}</p>
+
+<p>{% trans netdb=site_url('docs/how/network-database') -%}
+See the <a href="{{ netdb }}#threat">network database page</a>
 for more Sybil discussion.
-</p>
+{%- endtrans %}</p>
 
 
-<h3 id="buddy">Buddy Exhaustion attacks</h3>
-<p>
-  (Reference:
-  <a href="https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf">In Search of an Anonymouns and Secure Lookup</a> Section 5.2)
-</p>
-<p>
+<h3 id="buddy">{% trans %}Buddy Exhaustion attacks{% endtrans %}</h3>
+<p>{% trans pdf='https://netfiles.uiuc.edu/mittal2/www/nisan-torsk-ccs10.pdf' -%}
+(Reference: <a href="{{ pdf }}">In Search of an Anonymouns and Secure Lookup</a> Section 5.2)
+{%- endtrans %}</p>
+
+<p>{% trans peerselection=site_url('docs/how/peer-selection') -%}
 By refusing to accept or forward tunnel build requests, except to a colluding peer, a router could ensure
 that a tunnel is formed wholly from its set of colluding routers.
 The chances of success are enhanced if there is a large number of colluding routers,
 i.e. a <a href="#sybil">Sybil attack</a>.
 This is somewhat mitigated by our
-<a href="{{ site_url('docs/how/peerselection') }}">peer profiling</a> methods used to monitor the performance
+<a href="{{ peerselection }}">peer profiling</a> methods used to monitor the performance
 of peers.
 However, this is a powerful attack as the number of routers approaches
 <i>f</i> = 0.2, or 20% malicious nodes, as specifed in the paper.
@@ -529,17 +645,16 @@ The malicous routers could also maintain connections to the target router and pr
 excellent forwarding bandwidth for traffic over those connections, in an attempt
 to manipulate the profiles managed by the target and appear attractive.
 Further research and defenses may be necessary.
-</p>
+{%- endtrans %}</p>
 
 
-<h3 id="crypto">Cryptographic attacks</h3>
+<h3 id="crypto">{% trans %}Cryptographic attacks{% endtrans %}</h3>
 
-<p>
+<p>{% trans cryptography=site_url('docs/how/cryptography') -%}
 We use strong cryptography with long keys, and
 we assume the security of the industry-standard cryptographic primitives used in I2P, as documented
-<a href="{{ site_url('docs/how/cryptography') }}">on the low-level cryptography page</a>. 
-Security features
-include the immediate detection of 
+<a href="{{ cryptography }}">on the low-level cryptography page</a>. 
+Security features include the immediate detection of 
 altered messages along the path, the inability to decrypt messages not addressed to you,
 and defense against man-in-the-middle attacks.
 The key sizes chosen in 2003 were quite conservative at the time, and are still longer than
@@ -552,53 +667,56 @@ the advent of faster processors, cryptographic research, and advancements in
 methods such as rainbow tables, clusters of video game hardware, etc.
 Unfortunately, I2P was not designed with easy mechanisms to lengthen keys or change
 shared secret values while maintaining backward compatibility.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans cryptography=site_url('docs/how/cryptography') -%}
 Upgrading the various data structures and protocols to support longer keys
 will have to be tackled eventually, and this will be a
-<a href="{{ site_url('docs/how/cryptography') }}">major undertaking</a>, just as it will be for 
+<a href="{{ cryptography }}">major undertaking</a>, just as it will be for 
 <a href="https://torproject.org/">others</a>.
 Hopefully, through careful planning, we can minimize the disruption, and
 implement mechanisms to make it easier for future transitions.
-</p><p>
-In the future,
-several I2P protocols and data structures
+{%- endtrans %}</p>
+
+<p>{% trans -%}
+In the future, several I2P protocols and data structures
 support securely padding messages to arbitrary sizes, so messages could be made constant
 size or garlic messages could be modified randomly so that some cloves appear to contain
 more subcloves than they actually do.  At the moment, however, garlic, tunnel, and 
-end to end messages include simple random padding.</p>
+end to end messages include simple random padding.
+{%- endtrans %}</p>
 
 
 
-<h3 id="floodfill">Floodfill Anonymity attacks</h3>
-<p>
+<h3 id="floodfill">{% trans %}Floodfill Anonymity attacks{% endtrans %}</h3>
+<p>{% trans netdb=site_url('docs/how/network-database') -%}
 In addition to the floodfill DOS attacks described
 <a href="#ffdos">above</a>, floodfill routers are uniquely positioned
 to learn about network participants, due to their role
 in the netDb, and the high frequency of communication with those participants.
 This is somewhat mitigated because floodfill routers only manage a portion
 of the total keyspace, and the keyspace rotates daily, as explained 
-on the
-  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
+on the <a href="{{ netdb }}#threat">network database page</a>.
 The specific mechanisms by which routers communicate with floodfills have been
-  <a href="{{ site_url('docs/how/networkdatabase') }}#delivery">carefully designed</a>.
+<a href="{{ netdb }}#delivery">carefully designed</a>.
 However, these threats should be studied further.
 The specific potential threats and corresponding defenses are a topic for future research.
-</p>
+{%- endtrans %}</p>
 
 
-<h3 id="netdb">Other Network Database attacks</h3>
-<p>
-  A hostile user may attempt to harm the network by
-  creating one or more floodfill routers and crafting them to offer
-  bad, slow, or no responses.
-  Several scenarios are discussed on the
-  <a href="{{ site_url('docs/how/networkdatabase') }}#threat">network database page</a>.
-</p>
+<h3 id="netdb">{% trans %}Other Network Database attacks{% endtrans %}</h3>
+<p>{% trans netdb=site_url('docs/how/network-database') -%}
+A hostile user may attempt to harm the network by
+creating one or more floodfill routers and crafting them to offer
+bad, slow, or no responses.
+Several scenarios are discussed on the
+<a href="{{ netdb }}#threat">network database page</a>.
+{%- endtrans %}</p>
 
 
 
-<h3 id="central">Central Resource Attacks</h3>
-<p>
+<h3 id="central">{% trans %}Central Resource Attacks{% endtrans %}</h3>
+<p>{% trans -%}
 There are a few centralized or limited resources (some inside I2P, some not)
 that could be attacked or used as a vector for attacks.
 The absence of jrandom starting November 2007, followed by the loss of the i2p.net hosting service in January 2008,
@@ -606,65 +724,90 @@ highlighted numerous centralized resources in the development and operation of t
 most of which are now distributed.
 Attacks on externally-reachable resources mainly affect the ability of new users to find us,
 not the operation of the network itself.
+{%- endtrans %}</p>
 <ul>
-<li>The <a href="/">website</a> is mirrored and uses DNS round-robin for external public access.
-<li>Routers now support <a href="faq.html#reseed">multiple external reseed locations</a>,
-    however more reseed hosts may be needed, and the handling of unreliable or malicious
-    reseed hosts may need improvement.
-<li>Routers now support multiple update file locations.
-    A malicious update host could feed a huge file, need to limit the size.
-<li>Routers now support multiple default trusted update signers.
-<li>Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
-    Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
-<li>The code is now stored in a <a href="monotone.html">distributed source control system</a>.
-<li>Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
-    A malicious news host could feed a huge file, need to limit the size.
-<li><a href="naming.html">Naming system services</a>, including addressbook subscription providers, add-host services,
-    and jump services, could be malicious. Substantial protections for subscriptions were implemented
-    in release 0.6.1.31, with additional enhancements in subsequent releases.
-    However, all naming services require some measure of trust, see
-    <a href="naming.html">the naming page</a> for details.
-<li>We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
-    disruption in our ability to attract new users,
-    and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
+<li>{% trans site=site_url() -%}
+The <a href="{{ site }}">website</a> is mirrored and uses DNS round-robin for external public access.
+{%- endtrans %}</li>
+<li>{% trans faq=site_url('faq') -%}
+Routers now support <a href="{{ faq }}#reseed">multiple external reseed locations</a>,
+however more reseed hosts may be needed, and the handling of unreliable or malicious
+reseed hosts may need improvement.
+{%- endtrans %}</li>
+<li>{% trans -%}
+Routers now support multiple update file locations.
+A malicious update host could feed a huge file, need to limit the size.
+{%- endtrans %}</li>
+<li>{% trans -%}
+Routers now support multiple default trusted update signers.
+{%- endtrans %}</li>
+<li>{% trans -%}
+Routers now better handle <a href="#ffdos">multiple unreliable floodfill peers</a>.
+Malicious floodfills <a href="#ffdos">needs</a> <a href="#floodfill">more</a> study.
+{%- endtrans %}</li>
+<li>{% trans monotone=site_url('get-involved/guides/monotone') -%}
+The code is now stored in a <a href="{{ monotone }}">distributed source control system</a>.
+{%- endtrans %}</li>
+<li>{% trans -%}
+Routers rely on a single news host, but there is a hardcoded backup URL pointing to a different host.
+A malicious news host could feed a huge file, need to limit the size.
+{%- endtrans %}</li>
+<li>{% trans naming=site_url('docs/naming') -%}
+<a href="{{ naming }}">Naming system services</a>, including addressbook subscription providers, add-host services,
+and jump services, could be malicious. Substantial protections for subscriptions were implemented
+in release 0.6.1.31, with additional enhancements in subsequent releases.
+However, all naming services require some measure of trust, see
+<a href="{{ naming }}">the naming page</a> for details.
+{%- endtrans %}</li>
+<li>{% trans -%}
+We remain reliant on the DNS service for i2p2.de, losing this would cause substantial
+disruption in our ability to attract new users,
+and would shrink the network (in the short-to-medium term), just as the loss of i2p.net did.
+{%- endtrans %}</li>
 </ul>
 
 
-<h3 id="dev">Development attacks</h3>
+<h3 id="dev">{% trans %}Development attacks{% endtrans %}</h3>
 
-<p>
+<p>{% trans -%}
 These attacks aren't directly on the network, but instead go after its development team 
 by either introducing legal hurdles on anyone contributing to the development
 of the software, or by using whatever means are available to get the developers to 
 subvert the software.  Traditional technical measures cannot defeat these attacks, and
 if someone threatened the life or livelihood of a developer (or even just issuing a 
 court order along with a gag order, under threat of prison), we would have a big problem.
-</p>
+{%- endtrans %}</p>
 
-<p>
+<p>{% trans -%}
 However, two techniques help defend against these attacks:
+{%- endtrans %}</p>
 <ul>
-<li> All components of the network must be open source to enable inspection, verification, 
-     modification, and improvement.  If a developer is compromised, once it is noticed 
-     the community should demand explanation and cease to accept that developer's work.
-     All checkins to our <a href="monotone.html">distributed source control system</a>
-     are cryptographically signed, and the release packagers use a trust-list system
-     to restrict modifications to those previously approved.
-</li>
-<li> Development over the network itself, allowing developers to stay anonymous but still 
-     secure the development process.  All I2P development can occur through I2P - using
-     a <a href="monotone.html">distributed source control system</a>,
-     a distributed source control system, IRC chat,
-     public web servers,
-     discussion forums (forum.i2p), and the software distribution sites,
-     all available within I2P.</li>
+<li>{% trans monotone=site_url('get-involved/guides/monotone') -%}
+All components of the network must be open source to enable inspection, verification, 
+modification, and improvement.  If a developer is compromised, once it is noticed 
+the community should demand explanation and cease to accept that developer's work.
+All checkins to our <a href="{{ monotone }}">distributed source control system</a>
+are cryptographically signed, and the release packagers use a trust-list system
+to restrict modifications to those previously approved.
+{%- endtrans %}</li>
+<li>{% trans monotone=site_url('get-involved/guides/monotone') -%}
+Development over the network itself, allowing developers to stay anonymous but still 
+secure the development process.  All I2P development can occur through I2P - using
+a <a href="{{ monotone }}">distributed source control system</a>,
+a distributed source control system, IRC chat,
+public web servers,
+discussion forums (forum.i2p), and the software distribution sites,
+all available within I2P.
+{%- endtrans %}</li>
 </ul>
+
+<p>{% trans -%}
 We also maintain relationships with various organizations that offer legal advice,
 should any defense be necessary.
-</p>
+{%- endtrans %}</p>
 
-<h3 id="impl">Implementation attacks (bugs)</h3>
-<p>
+<h3 id="impl">{% trans %}Implementation attacks (bugs){% endtrans %}</h3>
+<p>{% trans -%}
 Try as we might, most nontrivial applications include errors in the design or 
 implementation, and I2P is no exception.  There may be bugs that could be exploited to 
 attack the anonymity or security of the communication running over I2P in unexpected 
@@ -673,7 +816,9 @@ all designs and documentation and solicit review and criticism with
 the hope that many eyes will improve the system.
 We do not believe in
 <a href="http://www.haystacknetwork.com/">security through obscurity</a>.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 In addition, the code is being 
 treated the same way, with little aversion towards reworking or throwing out 
 something that isn't meeting the needs of the software system (including ease of 
@@ -681,57 +826,67 @@ modification).  Documentation for the design and implementation of the network a
 the software components are an essential part of security, as without them it is 
 unlikely that developers would be willing to spend the time to learn the software 
 enough to identify shortcomings and bugs.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Our software is likely, in particular, to contain bugs related to denial of service
 through out-of-memory errors (OOMs), cross-site-scripting (XSS) issues  in the router console,
 and other vulnerabilities to non-standard inputs via the various protocols.
-</p><p>
+{%- endtrans %}</p>
+
+<p>{% trans volunteer=site_url('get-involved') -%}
 I2P is still a small network with a small development community and almost no
 interest from academic or research groups.
 Therefore we lack the analysis that
 <a href="https://torproject.org/">other anonymity networks</a>
 may have received. We continue to recruit people to
-<a href="getinvolved.html">get involved</a> and help.
-</p>
+<a href="{{ volunteer }}">get involved</a> and help.
+{%- endtrans %}</p>
 
 
 
 
-<h2>Other Defenses</h2>
-<h3 id="blocklist">Blocklists</h3>
-<p>
+<h2>{% trans %}Other Defenses{% endtrans %}</h2>
+<h3 id="blocklist">{% trans %}Blocklists{% endtrans %}</h3>
+<p>{% trans -%}
 To some extent, I2P could be enhanced to avoid peers operating at IP addresses
 listed in a blocklist. Several blocklists are commonly available in standard formats,
 listing anti-P2P organizations, potential state-level adversaries, and others.
-<p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 To the extent that active peers actually do show up in the actual blocklist,
 blocking by only a subset of peers would tend to segment the network,
 exacerbate reachability problems, and decrease overall reliability.
 Therefore we would want to agree on a particular blocklist and
 enable it by default.
+{%- endtrans %}</p>
 
-<p>
+<p>{% trans -%}
 Blocklists are only a part (perhaps a small part) of an array of defenses
 against maliciousness.
 In large part the profiling system does a good job of measuring
 router behavior so that we don't need to trust anything in netDb.
 However there is more that can be done. For each of the areas in the
 list above there are improvements we can make in detecting badness.
-<p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 If a blocklist is hosted at a central location with automatic updates
 the network is vulnerable to a
 <a href="#central">central resource attack</a>.
 Automatic subscription to a list gives the list provider the power to shut
 the i2p network down. Completely.
-<p>
+{%- endtrans %}</p>
+
+<p>{% trans -%}
 Currently, a default blocklist is distributed with our software,
 listing only the IPs of past DOS sources.
-There
-is no automatic update mechanism.
+There is no automatic update mechanism.
 Should a particular IP range implement serious attacks on the I2P network,
 we would have to ask people to update their blocklist manually through
 out-of-band mechanisms such as forums, blogs, etc.
-</p>
+{%- endtrans %}</p>
 
 
 {% endblock %}