Cette page a été mise à jour en November 2016 et est valide pour la version de routeur 0.9.27.

Aperçu

This page describes the origins and design of I2P's unidirectional tunnels. For further information see:

Review

While we aren't aware of any published research on the advantages of unidirecdtional tunnels, they appear to make it harder to detect a request/response pattern, which is quite possible to detect over a bidirectional tunnel. Several apps and protocols, notably HTTP, do transfer data in such manner. Having the traffic follow the same route to its destination and back could make it easier for an attacker who has only timing and traffic volume data to infer the path a tunnel is taking. Having the response come back along a different path arguably makes it harder.

When dealing with an internal adversary or most external adversaries, I2P's undirectional tunnels expose half as much traffic data than would be exposed with bidirectional circuits by simply looking at the flows themselves - an HTTP request and response would follow the same path in Tor, while in I2P the packets making up the request would go out through one or more outbound tunnels and the packets making up the response would come back through one or more different inbound tunnels.

The strategy of using two separate tunnels for inbound and outbound communication is not the only technique available, and it does have anonymity implications. On the positive side, by using separate tunnels it lessens the traffic data exposed for analysis to participants in a tunnel - for instance, peers in an outbound tunnel from a web browser would only see the traffic of an HTTP GET, while the peers in an inbound tunnel would see the payload delivered along the tunnel. With bidirectional tunnels, all participants would have access to the fact that e.g. 1KB was sent in one direction, then 100KB in the other. On the negative side, using unidirectional tunnels means that there are two sets of peers which need to be profiled and accounted for, and additional care must be taken to address the increased speed of predecessor attacks. The tunnel pooling and building process (peer selection and ordering strategies) should minimize the worries of the predecessor attack.

Anonymat

Un récent papier par Hermann et Grothoff déclare que les tunnels unidirectionnels de I2P "semblent être une mauvaise décision de conception".

La question principale que le papier cible est que les déanonymisations ciblant les tunnels unidirectionnels prennent davantage de temps, ce qui est un avantage, mais qu'un attaquant peut être davantage certain dans le cas d'un unidirectionnel. Par conséquent, le papier le déclare que ce n'est pas un avantage du tout, mais un inconvénient, au moins avec les eepsites à longue durée de vie (long-living eepsites).

Cette conclusion n'est pas entièrement soutenue par le papier. Les tunnels unidirectionnels atténuent clairement d'autres attaques et il n'est pas clair dans le papier sur la façon de négocier le risque d'attaques dans une architecture de tunnels bidirectionnels.

Sa conclusion est basée sur une certitude arbitraire contre la pondération de temps ? (la différence) qui ne peut pas être applicable dans tous les cas. Par exemple, quelqu'un pourrait faire une liste d'IPs possibles puis publier "subpoenas" (des citations à comparaître) à chacune. Ou l'attaquant pourrait DDoS chacune tour à tour, et via une simple attaque par intersection voir si l'eepsite tombe ou est ralenti. Ainsi de près cela peut être assez bon, ou le temps peut être plus important.

La conclusion est basée sur une pondération spécifique de l'importance de la certitude contre ("versus") le temps, et que la pondération pourrait être fausse, et c'est certainement discutable, particulièrement dans un monde réel avec citations à comparaître ("subpoeanas"), mandats de perquisition ("search warrants"), et autres méthodes disponibles pour la confirmation finale.

Une analyse complète des différences entre les tunnels unidirectionnels opposés ("versus") aux bidirectionnel est clairement à l'extérieur du périmètre du papier, et n'a d'ailleurs pas été faite. Par exemple, comment cette attaque se compare-t-elle aux nombreuses "timing attacks" possibles publiées au sujet des réseaux "onion-routed" ? Clairement les auteurs n'ont pas fait cette analyse, s'il est même effectivement possible de le faire.

Tor utilise les tunnels bidirectionnels et a subi beaucoup d'examens. I2P utilise les tunnels unidirectionnels et a subi très peu d'examens. Est-ce que le manque de papiers de recherche défendant les tunnels unidirectionnels signifie que c'est un pauvre choix de conception, ou plutôt qu'il nécessite davantage d'examens ? Il est difficile de se défendre contre les timing attacks (attaques par synchronisation) et les attaques distribuées, autant dans I2P que dans Tor. L'intention de conception (voir les références ci-dessus) était que des tunnels unidirectionnels sont plus résistants à des timing attacks. Cependant, le papier présente un type quelque peu différent de timing attack. Dans cette attaque, novatrice en l'état actuel des choses, suffisante pour étiqueter l'architecture de tunnel d'I2P (et ainsi I2P dans son ensemble) un "mauvais design", et par implication clairement inférieure à Tor, ou cela est juste une alternative de design qui a clairement besoin de la davantage d'examens et d'analyses ? Il y a plusieurs autres raisons pour considérer I2P actuellement inférieur à Tor et à d'autres projets (la petite taille du réseau, le manque de financement, le manque d'examens) mais est-ce que les tunnels unidirectionnels en sont vraiment une raison ?

En résumé, "mauvaise décision de conception" est apparemment (puisque le papier n'étiquette pas comme "mauvais" les tunnels bidirectionnels) un raccourci pour "les tunnels unidirectionnels sont sans équivoque inférieurs aux tunnels bidirectionnel", pourtant cette conclusion n'est pas soutenue par le papier.