Saying that I2P is an anonymous and secure communication system may sound interesting, but by itself, that statement is meaningless.
The three basic assumptions that we make are that the user's local computer is secure, that the cryptographic algorithms are sound, and that the user does not intentionally expose their identity. For researchers studying anonymity, I2P's threat model includes everything up through a well funded global active adversary, and if I2P does its job correctly, the weak link in the chain will be the user. The rest of this discussion explains what that means in the context of I2P.
Each of the seven user types above have their own set of concerns - reasons why they want privacy and anonymity.
Those adversaries could be interested in piercing the anonymity or confidentiality of the data for mere curiosity, to find out if some particular person was communicating with anyone else, to find out who those people are, to find out where those people are, and to confirm or deny whether their suspicions are correct. In addition, they could be passively gathering the data and storing it away for later analysis, or actively trying to trip up the network into revealing more than it should.
Various adversaries can mount different attacks against users of the network, but the cost may be significant and may require determined action.
The most plausible attack against the network is simply people behaving like they do on nearly every other network - greedily. I2P must operate in such a way that the Nash equilibrium can be found quickly and quite visibly, so that users are aware that antisocial behavior actually degrades their own performance. In addition, I2P must build obstacles against excessive use of network resources, while allowing people with diverse resources to still use the network effectively.
A large part of how I2P will convince the user that they shouldn't be antisocial is due to the anonymous nature of the network - when a router receives a request to provide some service (participate in a tunnel, pass on some garlic routed messages, handle some network database entries, etc), it has no idea what router it is being asked to perform this task for, and therefor cannot satisfy the requests of routers it wants to please and refuse the requests of routers it is not concerned with gaining the favor of (it would otherwise want to do this since every router keeps a profile of what its peers agree to, refuse to do, or fail to do after agreeing).
The network doesn't inherently expose scarce resources that one router would want to gain from another, but some routers will obviously have significantly varied capabilities - CPU, latency, and throughput - and all routers will want the "best" peers to perform services for them. The main way that routers provide better service to preferred peers is by using more efficient (but scarcer) transports (e.g. keeping a TCP connection open to them, rather than using UDP or email, or quickly ejecting them from the connection pool).
Another aspect of greedy operation can occur when a peer wants to build an excessive number of tunnels with a large number of participants per tunnel. To counter this, requests for tunnel participation includes a certificate which may be filled with some proof of work, or even a token proving payment (intertwined with the message recipient, message ID, and message expiration date to prevent reuse). The same mechanism is available for garlic routed messages - each garlic and each clove has its own certificate attached. (As a side note, all router identities and destinations also have one of these certificates attached so as to allow the introduction of increased 'cost' for identity) Currently however, all of these certificates are of the 'null' type, providing no proof of work.
In addition to the above greedy user attacks, there are a whole class of denial of service attacks that can be mounted on the network. At the extreme, nothing can defend against an attacker who outright disables all means of communication, from T1 lines through carrier pigeon. Thankfully that attack has been ruled out as too expensive, but plausible attacks still remain, falling into three camps - attacks against the entire network, attacks against a specific router, and attacks against a specific destination.
The entire network can be attacked by legal means (making the use of the software illegal), and for those who still wish to use it, there are a few techniques available. First, with I2P 2.0 people will be able to set up temporary trusted peers (perhaps at a public net cafe) and have their own router behind that one via restricted routes, and after a specified amount of time have that temporary router securely delete any data it has. In addition, with I2P 2.0 people will be able to use alternate transports that do not expose one's location (such as email, PHTTP, usenet, or even over another existing network). The router information for all peers in the network can be gathered without much effort by an attacker by simply mounting a harvesting attack - running a router and keeping track of all routers it sees passing through the network database.
The entire network can also be attacked technically by running a significant number of malicious routers that perform incorrectly or otherwise refuse to service its peers. On the other hand, the router's peer profiling and peer selection algorithms should fairly quickly identify these malicious routers and cease to use them. In addition, for those who are convinced that these profiles must be managed centrally, each router can include its own peer rankings in its published router information data for all to see.
An attacker can go after specific routers both trivially and successfully, using known techniques to flood its host. When I2P 2.0 includes alternate transports that are not subject to such IP level flooding, the attacker can send more valid data than the router can process. While the router will do what it can to operate effectively under attack, its likely that a determined adversary will be successful at disabling a router, and it is for this reason that the I2P client protocol defines a way for it to notify client applications that the router is under attack and is essentially useless. At that point, the client would simply have to migrate the destination to another router and grant a new lease.
An attacker who wants to go after a specific destination, regardless of what router it is located on, has a harder time. The I2P network database distributes the destination's current leases according to the Kademlia algorithm, which by itself is succeptible to Sybil attacks where an attacker takes over the keyspace surrounding the target and drops the data. However, I2P has modified the algorithm to both include a random exploration factor when publishing the data (so that the attacker cannot compromise all of the hosts with the data), plus the location within the Kademlia keyspace is modified every day through some predictable date driven transform against the key, requiring the attacker to remount the Sybil attack every day.
An additional way to mount a denial of service attack against a specific destination is to attempt to make all of its inbound tunnels unusable by looking up the current leases for that destination and mounting a denial of service attack against each of the routers serving as gateways (this obviously is useless against those trying to keep a destination from sending data, since outbound tunnels aren't published anywhere). To defend against this, the destination's router periodically performs essentially 'real world' tests against all of its inbound tunnels, marking ones that do not deliver the test message back to itself within the allotted time as invalid. If a sufficient number of a destination's inbound tunnels fail, the router simply creates new ones and the client authorizes a new set of leases. In addition, leases are rotated frequently (currently no tunnels last for more than 10 minutes), so over time, the attacker would have to flood a significant number of routers.
There are many different mechanisms for traffic analysis and entire categories of associated attacks.
Analysis by a passive external observer is simple to do, but unlikely to provide valuable results. All users on the network must run a router locally (or have a secure channel to one), and all routers serve as tunnel gateways, participants, and endpoints for other routers, as well as all other aspects of the I2P network protocol, so a simple short term intersection attack, even by a global attacker, is useless. Traffic confirmation attacks are also much harder, since routers continually forward on other messages. I2P 2.0 may include transports with support for constant bitrate links, giving passive external attackers no information whatsoever.
Analysis by passive internal observers is also quite simple to do by simply running a number of I2P routers. Even if all routers along the inbound and outbound tunnels from one destination to another are compromised by passive internal attackers, they will not know with certainty that the next hop in the tunnel is the final hop. In addition, transports available do not necessarily rely on exposing the IP address of the peer (e.g. PHTTP relays or email gateways, to be deployed in I2P 2.0), so that those who need to defend themselves against attackers who would go to such lengths to identify them would still be unsuccessful. In addition, I2P 2.0's support for a restricted route topology would provide additional hops that an attacker would have to compromise to determine the location of a destination, and I2P 3.0's nontrivial delays would prevent long term intersection attacks by allowing those that need such defenses to delay their messages for even days per hop, as well as including redundancy within the wrapped garlic cloves to fan out and distribute the payload.
Internal observers are also not able to detect to whom messages are bound, as the ElGamal/AES+SessionTag algorithm uses essentially random bits to observers not privvy to the decryption keys involved. No one in I2P inherently knows the sender of a message either - unlike IP, there is no 'from' address on plain I2P messages (while protocols built on top of I2P will likely include this information when necessary)
Analysis by active external observers is essentially limited to mounting denial of service attacks on selected peers and monitoring the traffic flow. As with the passive external observer above, this does not expose much information.
Analysis by active internal observers can include attacking the peers of their target (if those peers can somehow be identified?) and replacing them with peers under the attacker's control. Even if the attacker were able to replace all of their target's peers with those under the attacker's control, the subject of the attack would still be able to communicate with peers beyond their control if such a link were possible, and if not, it would seem as if the peer was simply unreachable. As above, there would still be no way to determine whether the subject of the attack was actually the router in question, plus I2P 2.0's restricted routes additionally provide not just plausible, but likely reason to believe that the router in question isn't the subject of the attack.
All messages within I2P have both a unique ID and an expiration date, preventing messages from being delivered twice before that date, or ever after it. I2P also does require that all routers have access to a synchronized clock - possible if the computer uses NTP, the user manually keeps the time correct, or a few other techniques to automate synchronization. Routers will refuse to talk to any other router whose clock is too far out of sync.
We are still assuming the security of the cryptographic primitives explained elsewhere. That includes 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 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.
These attacks aren't directly on the network, but instead go after its development and adoption, either by 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.
However, two techniques help defend against these attacks:
Try as we might, most nontrivial applications include errors in the design or implementation, and it is possible that any of them 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 are publishing 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 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.