diff --git a/www.i2p2/pages/datagrams.html b/www.i2p2/pages/datagrams.html
index 09f5ac860e6a8b0a629b3b69bd68990a2b2e1ea4..3291e61d733bf55dbf694455e238bf6b5cdd0658 100644
--- a/www.i2p2/pages/datagrams.html
+++ b/www.i2p2/pages/datagrams.html
@@ -76,6 +76,15 @@ Data integrity is assured by the gzip CRC-32 checksum implemented in
 <a href="i2cp.html#format">the I2CP layer</a>.
 There is no checksum field in the datagram protocol.
 
+<h3>Packet Encapsulation</h3>
+Each datagram is sent through I2P as a single message (or as an individual clove in a
+<a href="how_garlicrouting.html">Garlic Message</a>).
+Message encapsulation is implemented in the underlying
+<a href="i2cp.html">I2CP</a>,
+<a href="i2np.html">I2NP</a>, and
+<a href="tunnel_message_spec.html">tunnel message</a>layers.
+There is no packet delimiter mechanism or length field in the datagram protocol.
+
 
 <h2 id="spec">Specification</h2>
 
diff --git a/www.i2p2/pages/how.html b/www.i2p2/pages/how.html
index 1d1430c9f6f992a0776eedfa197c4b993f3fd754..f70cda3a08a0761013c042cf94ffc2727562dfc0 100644
--- a/www.i2p2/pages/how.html
+++ b/www.i2p2/pages/how.html
@@ -23,7 +23,7 @@ If you find any inaccuracies in the documents linked below, please
 <ul class="helplist">
 <li><a href="techintro.html">Technical Introduction</a></li>
 <li><a href="how_intro.html">A Less-Technical Introduction</a></li>
-<li><a href="how_threatmodel.html">Threat model</a></li>
+<li><a href="how_threatmodel.html">Threat model and analysis</a></li>
 <li><a href="how_networkcomparisons.html">Comparisons to other anonymous networks</a></li>
 <li><a href="protocols.html">Protocol stack chart</a></li>
 </ul>
diff --git a/www.i2p2/pages/how_threatmodel.html b/www.i2p2/pages/how_threatmodel.html
index 5acdc071aed42be5634753e65078cf54bce2502d..0fc3526426b380984b239674b84cdcc83baa20c7 100644
--- a/www.i2p2/pages/how_threatmodel.html
+++ b/www.i2p2/pages/how_threatmodel.html
@@ -1,15 +1,18 @@
 {% extends "_layout.html" %}
 {% block title %}I2P's Threat Model{% endblock %}
-{% block content %}<h1>What do we mean by "anonymous"?</h1>
+{% block content %}
 
-<p>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
+Updated August 2010, current as of router version 0.8
+<h2>What do we mean by "anonymous"?</h2>
+
+<p>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, I2P is working to provide sufficient anonymity to meet the
-real needs of whomever we can - from Joe Sixpack browsing porn to Tommy Trader
-sharing files to Irene Insurgent organizing an upcoming action.</p>
+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>
   
 <p>The question of whether I2P provides sufficient anonymity for your 
 particular needs is a hard one, but this page will hopefully assist in 
@@ -17,47 +20,80 @@ answering that question by exploring how I2P operates under various attacks
 so that you may decide whether it meets your needs.</p>
 
 <p>We welcome further research and analysis on I2P's resistance to the threats described below.
-Both review of existing literature (much of it focused on Tor) and original
+More review of existing literature (much of it focused on Tor) and original
 work focused on I2P is needed.</p>
 
-<h2>Mix summary</h2>
+<h2>Network Topology Summary</h2>
 <p>I2P builds off the ideas of many <a href="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).  However, any of these hops along the path may inject an 
-    arbitrary number of hops before forwarding the message to the next peer (though
-    the current implementation does not).</li>
-<li><b>I2P is variable latency</b> - each application (destination) determines its
-    own tradeoff of latency, throughput, bandwidth, and anonymity by configuring 
-    the number of hops in their tunnels, the number of tunnels to keep in parallel,
-    and how frequently to rotate tunnels.  In addition, there are 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).</li>
-<li><b>I2P has no entry and exit points</b> - all peers fully participate in 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 outbound HTTP proxies exist at the moment)</li>
-<li><b>I2P is fully distributed</b> - there are no central controls or peers who
-    take on uneven responsibilities (beyond load balancing due to resource constraints).
+    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>
 </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>
 
-<h2>Attacks</h2>
-<p>Taking from the attacks and analyzes put forth in the 
+
+<h2>The Threat Model (Attacks)</h2>
+<p>
+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
+<a href="http://www.torproject.org/">[Tor]</a>.
+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>
+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 will update
-this list to include new attacks as they are identified.</p>
+of attacks as well as many of I2Ps defenses.  We update
+this list to include new attacks as they are identified.
+</p><p>
+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>
+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,
+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="how_networkcomparisons.html">network comparisons</a> and
+<a href="how_garlicrouting.html">"garlic" terminology</a> pages may also be helpful
+to review.
+</p>
 
+<h3 id="index">Index</h3>
 <ul>
 <li><a href="#bruteforce">Brute force attacks</a></li>
 <li><a href="#timing">Timing attacks</a></li>
@@ -67,9 +103,11 @@ this list to include new attacks as they are identified.</p>
 <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="#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>
@@ -99,7 +137,17 @@ would want to make appropriate countermeasures, such as not communicating with
 unknown destinations, not publishing one's current leaseSet in the network 
 database, actively rerouting the associated tunnels 'mid stream', throttling the
 inbound tunnels themselves, and/or using restricted routes with trusted links 
-to secure the local connection.</p>
+to secure the local connection.
+</p><p>
+As a partial defense against 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="how_peerselection.html">peer selection page</a>.
+</p>
+
+
 
 <h3 id="timing">Timing attacks</h3>
 
@@ -120,10 +168,12 @@ automatic replies though - the streaming library does (with the SYN+ACK) as does
 message mode of guaranteed delivery (with the DataMessage+DeliveryStatusMessage).</p>
 
 <p>Without protocol scrubbing or higher latency, global active adversaries can 
-gain substantial information.  As such, people concerned with these attacks should
-increase the latency (per <a href="todo#stop">nontrivial delays</a> or 
+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>.</p>
+other advanced tunnel routing <a href="todo#batching">techniques</a>,
+but these are unimplemented in I2P.
+</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>
@@ -139,8 +189,42 @@ 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>I2P does not attempt to address this for low latency communication,
-but does for peers who can afford delays (per <a href="todo#stop">nontrivial 
+<p>
+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>
+Partial defenses implemented in I2P:
+<ul><li>
+<a href="tunnel-alt.html#ordering">strict ordering</a> of peers
+</li><li>
+<a href="how_peerselection.html">peer profiling and selection</a> from a small group that changes slowly
+</li><li>
+Limits on the number of tunnels routed through a single peer
+</li><li>
+Prevention of peers from the same /16 IP range from being members of a single tunnel
+</li></ul>
+
+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>
+We do not use low-bandwidth "guard nodes"
+</li><li>
+We use tunnel pools comprised of several tunnels, and traffic can shift from tunnel to tunnel.
+</li><li>
+Tunnels are not long-lived; new tunnels are built every 10 minutes.
+</li><li>
+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>
+
+
+</p><p>
+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,
 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,
@@ -150,20 +234,20 @@ as an adversary can't "ping" them to mount the attack.</p>
 
 <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> The most plausible attack against I2P will simply
-    be people trying to consume significantly more resources than they are 
-    willing to contribute.  The defense against this is twofold:<ul>
-    <li>First, for people who do not need very strong anonymity, simply set the tunnel length
-    to 0 hops (1 hop until <a href="todo#ordering">strict ordering</a> and 
-    <a href="todo#tunnelLength">permuted lengths</a> is implemented).  This will
-    provide optimal throughput while still providing a degree of anonymity via
-    plausible deniability.  In addition, it will not consume significant network
-    resources.</li>
-    <li>Second, for people who do need stronger anonymity, educate them so they 
-    understand that without routing other people's traffic, their own anonymity
-    is weakened, so that if they want to consume significant network resources
-    while still being anonymous, they need to provide significant network 
-    resources.</li></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 
@@ -176,10 +260,9 @@ each with different costs and consequences:</p><ul>
     I2P addresses these issues by maintaining <a href="how_peerselection.html">profiles</a> on the 
     peers, attempting to identify underperforming ones and simply ignoring 
     them, or using them rarely.
-    In the process of fixing several problems and bugs with peer reachability
-    in the 0.6.1.32 and 0.6.1.33 releases, we have significantly enhanced the
-    ability to recognize and avoid troublesome peers. These efforts will
-    continue in the 0.6.2.x release cycle.
+    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,
@@ -202,20 +285,17 @@ each with different costs and consequences:</p><ul>
     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.</p>
+    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.
-    To fix problems with floodfill peer selection
-    in the 0.6.1.32 and earlier releases, significantly enhancements in the
-    ability to recognize and avoid troublesome floodfill peers
-    were included in release 0.6.1.33.
-    However, there is much more to do.
     A floodfill router may provide bad or no response to lookups, and
     it may also interfere with inter-floodfill communication.
-    A brief summary of the issues is
-    listed on <a href="http://zzz.i2p/#floodfill">zzz.i2p</a>.
-    These efforts will continue in the 0.6.2.x release cycle.
+    Some defenses and
+    <a href="how_peerselection">peer profiling</a> are implemented,
+    however there is much more to do.
+    For more information see the
+    <a href="how_networkdatabase.html#threat">network database page</a>.
 </li>
 </ul>
 
@@ -260,7 +340,11 @@ 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>
+which other tunnels or messages have those delays).
+</p><p>
+Also discussed on the
+    <a href="how_networkdatabase.html#threat">network database page</a> (bootstrap attack).
+</p>
 
 <h3 id="predecessor">Predecessor attacks</h3>
 
@@ -275,14 +359,21 @@ target is located.  </p>
 <p>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="how_peerselection">peer selection</a> algorithm which breaks them
-into tiers.  Second, with <a href="todo#ordering">strict ordering</a> of peers
+into tiers.  Second, with <a href="tunnel-alt.html#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="todo#tunnelLength">permuted tunnel length</a>
+the source.  Third, with <a href="tunnel-alt.html#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>, 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>
+attackers will merely run into that gateway.
+</p><p>
+The current
+<a href="tunnel-alt-creation.html">tunnel build method</a>
+was specifically designed to combat the predecessor attack.
+See also <a href="#intersection">the intersection attack</a>.
+</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>
@@ -290,21 +381,83 @@ 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>
 
-<h3 id="harvesting">Harvesting attacks</h3>
 
-<p>The harvesting attack can be used for legal attacks and to help mounting
+<h3 id="harvesting">Harvesting attacks</h3>
+<p>
+"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.  I2P itself is 
-built to optimize this attack, since there is the distributed network database 
-containing just this information.  However, this by itself isn't a problem,
-since there are ways to track down who is participating in the network with
-essentially all public systems - I2P just makes it easier to do (and, in 
-turn, gains the ability to combat partitioning and provide well bounded 
-discovery time).  With <a href="todo#nat">basic</a> and 
-<a href="todo#fullRestrictedRoutes">comprehensive</a> restricted routes, 
+harvesting whatever references to other peers it can find.
+</p><p>
+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 may the attack somewhat harder in practice:
+<ul><li>
+Network growth will make it more difficult to obtain a given proportion of the network
+</li><li>
+Floodfill routers implement query limits as DOS protection
+</li><li>
+"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>
+In future implementations,
+<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>
+they can be reached (as well as their public keys, etc).
+</p><p>
+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>
+
+
+
+<h3 id="traffic">Identification Through Traffic Analysis</h3>
+<p>
+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>
+make it somewhat difficult to identify I2P traffic:
+<ul><li>
+Random port selection
+</li><li>
+Point-to-Point Encryption of all traffic
+</li><li>
+DH key exchange with no protocol bytes or other unencrypted constant fields
+</li><li>
+Simultaneous use of both
+<a href="ntcp.html">TCP</a> and
+<a href="udp.html">UDP</a> transports.
+UDP may be much harder for some Deep Packet Inspection (DPI) equipment to track.
+</li></ul>
+
+In the near future, we plan to directly address traffic analysis issues by further obfuscation of I2P transport protocols, possibly including:
+<ul><li>
+Padding at the transport layer to random lengths, especially during the connection handshake
+</li><li>
+Study of packet size distribution signatures, and additional padding as necessary
+</li><li>
+Development of additional transport methods that mimic SSL or other common protocols
+</li><li>
+Review of padding strategies at higher layers to see how they affect packet sizes at the transport layer
+</li><li>
+Review of methods implemented by various state-level firewalls to block Tor
+</li><li>
+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>
+
+
 
 <h3 id="sybil">Sybil attacks</h3>
 
@@ -322,28 +475,93 @@ IIP used
 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>
+appropriate value when necessary (or some other certificate proving scarcity).
+</p><p>
+Requiring HashCash Certificates in various places has two major problems:
+<ul><li>
+Maintaining backward compatibility
+</li><li>
+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>
+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="how_networkdatabase.html#threat">network database page</a>
+for more Sybil discussion.
+</p>
+
+
 
 <h3 id="crypto">Cryptographic attacks</h3>
 
 <p>
-We are still assuming the security of the cryptographic primitives explained 
-<a href="how_cryptography">elsewhere</a>.  That includes the immediate detection of 
+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="how_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 network protocol and data structures
+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
+those used in <a href="https://torproject.org/">other anonymity networks</a>.
+We don't think the current key lengths are our biggest weakness,
+especially for traditional, non-state-level adversaries;
+bugs and the small size of the network are much more worrisome.
+Of course, all cryptographic algorithms eventually become obsolete due to
+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>
+Upgrading the various data structures and protocols to support longer keys
+will have to be tackled eventually, and this will be a
+<a href="how_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
 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>
 
+
+
 <h3 id="floodfill">Floodfill Anonymity attacks</h3>
 <p>
 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 centralized role
+to learn about network participants, due to their role
 in the netDb, and the high frequency of communication with those participants.
-The specific potential threats and corresponding defenses are a topic for further research.
-</li>
+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="how_networkdatabase.html#threat">network database page</a>.
+The specific mechanisms by which routers communicate with floodfills have been
+  <a href="how_networkdatabase.html#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>
+
+
+<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="how_networkdatabase.html#threat">network database page</a>.
+</p>
+
+
 
 <h3 id="central">Central Resource Attacks</h3>
 <p>
@@ -355,7 +573,7 @@ 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.
 <ul>
-<li>The <a href="/">new website</a> is mirrored and uses DNS round-robin for external public access.
+<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.
@@ -365,7 +583,7 @@ not the operation of the network itself.
 <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 still rely on a single news host, update for this is TBD.
+<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
@@ -385,9 +603,9 @@ These attacks aren't directly on the network, but instead go after its developme
 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 lives of a developer's loved ones (or even just issuing a 
-court order along with a gag order, under threat of prison), everyone should expect that 
-the code would be modified.  </p>
+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>
 
 <p>
 However, two techniques help defend against these attacks:
@@ -407,22 +625,42 @@ However, two techniques help defend against these attacks:
      discussion forums (forum.i2p), and the software distribution sites,
      all available within I2P.</li>
 </ul>
+We also maintain relationships with various organizations that offer legal advice,
+should any defense be necessary.
 </p>
 
-<h3 id="impl">Implementation attacks</h3>
+<h3 id="impl">Implementation attacks (bugs)</h3>
 <p>
 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 
 ways.  To help withstand attacks against the design or protocols in use, we publish 
-all designs and documentation in the open and asking for any and all criticism with 
-the hope that many eyes will improve the system.  In addition, the code is being 
+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>
+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 
 modification).  Documentation for the design and implementation of the network and 
 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>
+enough to identify shortcomings and bugs.
+</p><p>
+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>
+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>
+
+
 
 
 <h2>Other Defenses</h2>
@@ -437,23 +675,6 @@ 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.
-<p>
-Any blocking within i2p would have to be implemented at the following
-places in the code to be fully effective.
-Different places address the various possible malicious behaviors.
-<ol>
-<li>Outbound connections (bids)
-<li>Inbound NTCP
-<li>Inbound SSU
-<li>Peer selection for inbound and outbound tunnels
-<li>Other-end inbound gateway
-<li>Netdb stores / shitlisting
-<li>Floodfill stores
-<li>Floodfill queries
-<li>Inter-floodfill flooding
-<li>SSU peer tests
-<li>SSU address determination
-</ol>
 
 <p>
 Blocklists are only a part (perhaps a small part) of an array of defenses
@@ -467,15 +688,16 @@ 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. So we probably won't be doing that.
-Inclusion in i2pupdate files perhaps? Signed or unsigned?
-In-I2P subscription?
+the i2p network down. Completely.
 <p>
-Initial test results
-show that the common splist.txt blocklist is overly broad for our use - at the least
-we don't want to block Tor users that are in splist.
-Level1 + bogon + (maybe) level2 is more reasonable?
-But we don't want to block potential anonymity researchers at .edu locations.
+Currently, a default blocklist is distributed with our software,
+listing only the IPs of past DOS sources.
+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>
 
 
 {% endblock %}
diff --git a/www.i2p2/pages/streaming.html b/www.i2p2/pages/streaming.html
index ae5947e5b67fa6da5af974f8dca53a35006226ec..87f6dfa2ebd27154483621298c5cd4720805227e 100644
--- a/www.i2p2/pages/streaming.html
+++ b/www.i2p2/pages/streaming.html
@@ -89,12 +89,12 @@ For a good example of usage, see the i2psnark code.
 </p>
 
 
-<h3 id="options">Default Parameters</h3>
+<h3 id="options">Options and Defaults</h3>
 <p>
-The current default values are listed below.
-Lower case values are streaming lib parameters that can changed on a
+The options and current default values are listed below.
+Options are case-sensitive and may be set for the whole router, for a particular client, or for an individual socket on a
 per-connection basis.
-These values are tuned for HTTP performance over typical I2P conditions. Other applications such
+Many values are tuned for HTTP performance over typical I2P conditions. Other applications such
 as peer-to-peer services are strongly encouraged to
 modify as necessary, by setting the options and passing them via the call to
 <a href="http://docs.i2p2.de/core/net/i2p/client/streaming/I2PSocketManagerFactory.html">I2PSocketManagerFactory</a>.createManager(_i2cpHost, _i2cpPort, opts).
@@ -106,33 +106,67 @@ Note that higher-layer APIs, such as
 <a href="bob.html">BOB</a>, and
 <a href="i2ptunnel.html">I2PTunnel</a>,
 may override these defaults with their own defaults.
+Also note that many options only apply to servers listening for incoming connections.
 </p>
 
 
 <table>
-<tr><th>Option</th><th>Default</th>
-</tr><tr><td>i2p.streaming.connectTimeout</td><td>5*60*1000
-</td></tr><tr><td>i2p.streaming.initialReceiveWindow</td><td>1
-</td></tr><tr><td>i2p.streaming.initialWindowSize</td><td>12 (if no <a href="#sharing">sharing data</a> available)
-</td></tr><tr><td>i2p.streaming.maxWindowSize</td><td>128
-</td></tr><tr><td>i2p.streaming.maxResends</td><td>8
-</td></tr><tr><td>i2p.streaming.profile</td><td>1 (bulk) (2=interactive not supported)
-</td></tr><tr><td>i2p.streaming.maxMessageSize</td><td>1730
-</td></tr><tr><td>i2p.streaming.initialRTT</td><td>10*1000 (if no <a href="#sharing">sharing data</a> available)
-</td></tr><tr><td>i2p.streaming.initialResendDelay</td><td>1000
-</td></tr><tr><td>i2p.streaming.initialAckDelay</td><td>2000
-</td></tr><tr><td>i2p.streaming.inactivityTimeout</td><td>90*1000
-</td></tr><tr><td>i2p.streaming.inactivityAction</td><td>2 (send) (0=noop, 1=disconnect)
+<tr><th>Option</th><th>Default</th><th>Notes</th>
+</tr>
+<tr><td>i2cp.accessList</td><td>null</td><td>Comma- or space-separated list of Base64 peer Hashes used for either access list or blacklist
+</td></tr><tr><td>i2cp.enableAccessList</td><td>false
+</td><td>Use the access list as a whitelist for incoming connections
+</td></tr><tr><td>i2cp.enableBlackList</td><td>false
+</td><td>Use the access list as a blacklist for incoming connections
+</td></tr><tr><td>i2p.streaming.answerPings</td><td>true</td><td>Whether to respond to incoming pings
 </td></tr><tr><td>i2p.streaming.congestionAvoidanceGrowthRateFactor</td><td>1
+</td><td>
+      When we're in congestion avoidance, we grow the window size at the rate
+      of 1/(windowSize*factor).  In standard TCP, window sizes are in bytes,
+      while in I2P, window sizes are in messages.
+      A higher number means slower growth.
+</td></tr><tr><td>i2p.streaming.connectDelay</td><td>-1
+</td><td>
+      How long to wait after instantiating a new con 
+      before actually attempting to connect.  If this is
+      &lt;= 0, connect immediately with no initial data.  If greater than 0, wait
+      until the output stream is flushed, the buffer fills, 
+      or that many milliseconds pass, and include any initial data with the SYN.
+</td></tr><tr><td>i2p.streaming.connectTimeout</td><td>5*60*1000</td><td>5 minutes!
+</td></tr><tr><td>i2p.streaming.inactivityAction</td><td>2 (send) </td><td>(0=noop, 1=disconnect)
+    What to do on an inactivity timeout - do nothing, disconnect, or send a duplicate ack.
+</td></tr><tr><td>i2p.streaming.inactivityTimeout</td><td>90*1000
+</td></tr><tr><td>i2p.streaming.initialAckDelay</td><td>2000
+</td></tr><tr><td>i2p.streaming.initialResendDelay</td><td>1000
+</td><td>
+   The initial value of the resend delay field in the packet header, times 1000.
+   Not fully implemented; see below.
+</td></tr><tr><td>i2p.streaming.initialRTT</td><td>8000 </td><td>(if no <a href="#sharing">sharing data</a> available)
+</td></tr><tr><td>i2p.streaming.initialWindowSize</td><td>6</td><td>(if no <a href="#sharing">sharing data</a> available)
+   In standard TCP, window sizes are in bytes, while in I2P, window sizes are in messages.
+</td></tr><tr><td>i2p.streaming.maxConcurrentStreams</td><td>-1 </td><td>(0 or negative value means unlimited)
+   This is a total limit for incoming and outgoing combined.
+</td></tr><tr><td>i2p.streaming.maxConnsPerMinute</td><td>0 </td><td>Incoming connection limit (per peer; 0 means disabled)
+</td></tr><tr><td>i2p.streaming.maxConnsPerHour</td><td>0 </td><td>(per peer; 0 means disabled)
+</td></tr><tr><td>i2p.streaming.maxConnsPerDay</td><td>0 </td><td>(per peer; 0 means disabled)
+</td></tr><tr><td>i2p.streaming.maxMessageSize</td><td>1730</td><td>The MTU in bytes.
+</td></tr><tr><td>i2p.streaming.maxResends</td><td>8
+</td><td>
+   Maximum number of retransmissions before failure.
+</td></tr><tr><td>i2p.streaming.maxTotalConnsPerMinute</td><td>0 </td><td>Incoming connection limit (all peers; 0 means disabled)
+</td></tr><tr><td>i2p.streaming.maxTotalConnsPerHour</td><td>0 </td><td>(all peers; 0 means disabled)
+   Use with caution as exceeding this will disable a server for a long time.
+</td></tr><tr><td>i2p.streaming.maxTotalConnsPerDay</td><td>0 </td><td>(all peers; 0 means disabled)
+   Use with caution as exceeding this will disable a server for a long time.
+</td></tr><tr><td>i2p.streaming.maxWindowSize</td><td>128
+</td></tr><tr><td>i2p.streaming.profile</td><td>1 (bulk)</td><td>(2=interactive not supported)
+      This doesn't currently do anything, but setting it to a value other than 1 will cause an error.
 </td></tr><tr><td>i2p.streaming.slowStartGrowthRateFactor</td><td>1
-</td></tr><tr><td>i2p.streaming.answerPings</td><td>true
-</td></tr><tr><td>i2p.streaming.maxConcurrentStreams</td><td>-1 (0 or negative value means unlimited)
-</td></tr><tr><td>i2p.streaming.maxConnsPerMinute</td><td>0 (per peer; 0 means disabled)
-</td></tr><tr><td>i2p.streaming.maxConnsPerHour</td><td>0 (per peer; 0 means disabled)
-</td></tr><tr><td>i2p.streaming.maxConnsPerDay</td><td>0 (per peer; 0 means disabled)
-</td></tr><tr><td>i2p.streaming.maxTotalConnsPerMinute</td><td>0 (all peers; 0 means disabled)
-</td></tr><tr><td>i2p.streaming.maxTotalConnsPerHour</td><td>0 (all peers; 0 means disabled)
-</td></tr><tr><td>i2p.streaming.maxTotalConnsPerDay</td><td>0 (all peers; 0 means disabled)
+</td><td>
+      When we're in slow start, we grow the window size at the rate
+      of 1/(factor).  In standard TCP, window sizes are in bytes,
+      while in I2P, window sizes are in messages.
+      A higher number means slower growth.
 </td></tr>
 </table>
 
@@ -142,7 +176,26 @@ may override these defaults with their own defaults.
 <h2>Protocol Specification</h2>
 <h3>Packet Format</h3>
 <p>
-Here is the format of a single packet transferred as part of a streaming connection.  
+The format of a single packet in the streaming protocol is:
+<pre>
+
++----+----+----+----+----+----+----+----+
+| send Stream ID    | rcv Stream ID     |
++----+----+----+----+----+----+----+----+
+| sequence  Num     | ack Through       |
++----+----+----+----+----+----+----+----+
+| nc |   NACKs ...
++----+----+----+----+----+----+----+----+
+     | rd |  flags  | opt size| opt data
++----+----+----+----+----+----+----+----+
+   ...                                  |
++----+----+----+----+----+----+----+----+
+|   payload ...
++----+----+----+----//
+
+
+</pre>
+
 <table>
 <tr><th>Field<th>Length<th>Contents
 <tr><td>sendStreamId <td>4 byte <a href="common_structures_spec.html#type_Integer">Integer</a><td>Random number selected by the connection recipient
@@ -192,7 +245,7 @@ As specified by the flags. See below.
 <tr><td>payload <td>remaining packet size<td>
 </table>
 
-<h3>Flags Field</h3>
+<h3>Flags and Option Data Fields</h3>
 <p>The flags field above specifies some metadata about the packet, and in
 turn may require certain additional data to be included.  The flags are
 as follows. Any data structures specified must be added to the options area
@@ -263,8 +316,9 @@ including overhead for the typical case.
 </p>
 <p>
 The first message in a connection includes a 387 byte (typical) Destination added by the streaming layer,
-and usually a 898 byte (typical) LeaseSet bundled in the Garlic message.
-Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not realistic.
+and usually a 898 byte (typical) LeaseSet, and Session keys, bundled in the Garlic message by the router.
+(The LeaseSet and Session Keys will not be bundled if an ElGamal Session was previously established).
+Therefore, the goal of fitting a complete HTTP request in a single 1KB I2NP message is not always attainable.
 However, the selection of the MTU, together with careful implementation of fragmentation
 and batching strategies in the tunnel gateway processor, are important factors in network bandwidth,
 latency, reliability, and efficiency, especially for long-lived connections.
@@ -276,6 +330,16 @@ Data integrity is assured by the gzip CRC-32 checksum implemented in
 There is no checksum field in the streaming protocol.
 
 
+<h3>Packet Encapsulation</h3>
+Each packet is sent through I2P as a single message (or as an individual clove in a
+<a href="how_garlicrouting.html">Garlic Message</a>).
+Message encapsulation is implemented in the underlying
+<a href="i2cp.html">I2CP</a>,
+<a href="i2np.html">I2NP</a>, and
+<a href="tunnel_message_spec.html">tunnel message</a>layers.
+There is no packet delimiter mechanism or payload length field in the streaming protocol.
+
+
 <h3>Windowing</h3>
 <p>
 The streaming lib uses standard slow-start (exponential window growth) and congestion avoidance (linear window growth)
@@ -310,15 +374,16 @@ The share data for a given peer expires after a few minutes.
 <h3 id="other">Other Parameters</h3>
 The following parameters are hardcoded, but may be of interest for analysis:
 <ul>
-<li>MIN_RESEND_DELAY = 2*1000
-<li>MAX_RESEND_DELAY = 45*1000
+<li>MIN_RESEND_DELAY = 2*1000 (minimum RTO)
+<li>MAX_RESEND_DELAY = 45*1000 (maximum RTO)
 <li>MIN_WINDOW_SIZE = 1
 <li>TREND_COUNT = 3
 <li>RTT_DAMPENING = 0.875
-<li>MIN_MESSAGE_SIZE = 512
+<li>MIN_MESSAGE_SIZE = 512 (minimum MTU)
 <li>INBOUND_BUFFER_SIZE = maxMessageSize * (maxWindowSize + 2)
 <li>INITIAL_TIMEOUT = 1.5 * initialRTT
 <li>PASSIVE_FLUSH_DELAY = 250
+<li>Maximum RTT estimate: 60*1000
 </ul>
 </p>
 
@@ -333,7 +398,7 @@ optimizations to take into account the high bandwidth x delay product.  Individu
 streams may adjust the maximum packet size and other options. The default
 message size is selected to fit precisely in two 1K I2NP tunnel messages,
 and is a reasonable tradeoff between the bandwidth costs of 
-retransmitting lost messages and the latency of multiple messages.
+retransmitting lost messages, and the latency and overhead of multiple messages.
 </p>
 
 
@@ -356,7 +421,7 @@ See <a href="ntcp_discussion.html">the NTCP discussion page</a> for details.
 <li>
 The interaction of the routing algorithms with the streaming lib strongly affects performance.
 In particular, random distribution of messages to multiple tunnels in a pool
-leads to a high degree of out-of-order deli>very which results in smaller window
+leads to a high degree of out-of-order delivery which results in smaller window
 sizes than would otherwise be the case.
 The router currently routes messages for a single from/to destination pair
 through a consistent set of tunnels, until tunnel expiration or deli>very failure.
@@ -373,6 +438,19 @@ The DELAY_REQUESTED field could be used more.
 Duplicate initial SYNCHRONIZE packets on short-lived streams may not be recognized and removed.
 </li>
 <li>
+Don't send the MTU in a retransmission.
+</li>
+<li>
+      Data is sent along unless the outbound window is full.
+      (i.e. no-Nagle or TCP_NODELAY)
+      Probably should have a configuration option for this.
+</li>
+<li>
+zzz has added debug code to the streaming library to log packets in a wireshark-compatible
+(pcap) format; Use this to further analyze performance.
+The format may require enhancement to map more streaming lib parameters to TCP fields.
+</li>
+<li>
 There are proposals to replace the streaming lib with standard TCP
 (or perhaps a null layer together with raw sockets).
 This would unfortunately be incompatible with the streaming lib
diff --git a/www.i2p2/pages/transport.html b/www.i2p2/pages/transport.html
index 8b8712b184947f2e68b8b37382ddb40ae0a9580f..4dba232ae9cb8c8cfae1d83df6b882c9ac532c25 100644
--- a/www.i2p2/pages/transport.html
+++ b/www.i2p2/pages/transport.html
@@ -117,5 +117,11 @@ the memory requirements for an NTCP connection are higher than that for SSU.
 However, as NTCP buffers are partially in the kernel and SSU buffers are on the Java heap,
 that assumption is difficult to verify.
 
+</p><p>
+Analyze
+<a href="http://www.cse.chalmers.se/%7Ejohnwolf/publications/hjelmvik_breaking.pdf">Breaking and Improving Protocol Obfuscation</a>
+and see how transport-layer padding may improve things.
+</p>
+
 
 {% endblock %}