Part 2: Tunnel Magic, NetDB, and Protocol Juggling
Continuing to translate official I2P documentation.
This time it is a little more free, so that the text is read in Russian.
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P”
Part 2: Tunnel Magic, NetDB, and Protocol Juggling
Part 3: Digital Garlic
Incoming and outgoing tunnels operate on similar principles. The tunnel gateway accumulates a number of messages from the tunnels, eventually forming a message from it to send to the tunnel. The gateway then pre-encrypts the data and sends it through the first hop. This peer and subsequent tunnel members check if the message is a duplicate by adding another layer of encryption and send it to the next tunnel.
Ultimately, the message gets to the target, after which it is fully decoded and processed by the target itself. The difference lies in the fact that the creator of the tunnel for transit tunnels will be the target, and for the transit tunnels an additional level of encryption. The originator of the outgoing tunnel is a gateway and pre-decrypts the message so that it does not reach the recipient for peers.
The choice of peers and connecting them in a certain sequence is very important for understanding how I2P remains anonymous and productive (Powerful, fast - approx. Lane).
While NetDB (Network Database) (see below) has its own criteria for selecting, querying, and storing peer entries, and a tunnel initializer can use any peers, in any order and number of times in a single tunnel.
If data with the minimum delay and maximum efficiency are available worldwide, then the customer’s needs will be provided based on his requirements, taking into account possible threats. Unfortunately, latency and throughput is not perfect and depends on peers able to provide their own throughput. The provided level of anonymity leaves its mark on the speed of the network.
')
Anonymity is provided simply: peers are randomly selected from the entire network, requests for peers occur randomly and can last forever. Performance is provided by sampling the fastest peers and load distribution between them, to ensure transparency and resiliency. They are also used to restore and rebuild tunnels when there is a change in network bandwidth. Previously, everything was fragile and inefficient: there could be problems with access to information and lack of anonymity was offered.
I2P offers a wide range of different sampling strategies, combined with anonymous organization of peers by profiles.
I2P uses for work constant profiles of peers that it generates by examining their work on the network, for example, if a peer responds to a search in netDB for 1.3 seconds, then information about the route and delays for both tunnels (incoming and outgoing) is recorded in its profile in which all requests and responses of a feast are also recorded. The data obtained in the measurement of transport delays and “jams” is not used as part of the peer profile, but is associated with specific routers.
During the collection of information for profiles, information will be systematized and as a result we will receive information about performance, delays, the ability of the peer to handle large amounts of information, how much it is currently loaded and how well it is integrated into the network. These calculations are carried out for each peer separately, and then peers are compared with each other and put on the shelves: fast and capacious, high throughput, the worker is not working.
Thresholds for distribution across these levels are generated dynamically, and although quite simple algorithms are currently used for this, there are alternatives.
The following text describes very specific points, the term “harvesting” (harvesting attacks) refers to the type of attack that will allow you to make a list of users working with I2P. I would like someone to suggest a better equivalent, this option cuts off my ears.
Client tunnel is deployed by a simple and efficient random sample of peers, one of the best in terms of capacity and speed. Sampling of peers is carried out from netDB, peers used for expansion, have only a certain stability (not failing) and are used to transfer the “hill top” (central load point - approx. Lane). This type of work provides a very weak resistance to attacks such as “harvest”. As a solution, the router may not balance the load between peers, and use mainly only a separate channel to reduce the impact of this attack, but makes the network less resistant to other types of threats.
Receiving a random key, a route is generated by XOR. In the event of a “harvest harvest” attack, the information is lost and the peer reports an error, after which it is turned off.
Another simple strategy to protect against assembling information is to simply regenerate the incoming tunnel, using new peers to create a new tunnel. To cope with the type of attack that targets clients, the outgoing tunnel endpoints must remain unchanged. End, if peers as tunnel endpoints remain fixed, you need to set a connection time limit. A peer, as the end point of a tunnel, can simulate a temporary router failure, as a result the tunnel will be automatically re-created.
These two security strategies can be combined, then fixed participants and the XOR function will be used to create tunnels. A tougher protection strategy implies precise (specific) connections between individual peers that are trusted and participate in creating a route under the same conditions. (Reminds Tor - approx. Lane). The use of XOR implies the invariance of the order and the fact that the initial and final feast is always the same, and XOR only ensures the invariance of the order.
As mentioned earlier, currently I2P (release 0.8) includes a multi-level sampling strategy using XOR. A more detailed discussion of the mechanics of the tunnel, on the management and selection of peers can be found in the specification of tunnels .
As mentioned earlier, I2P works by exchanging network metadata, which will be explained in more detail below.
A certain percentage of I2P users are designated as 'FloodFill' (Fully Loaded). Currently, the machines on which I2P is installed have a sufficiently high throughput, so in the event of a sharp drop, the number of 'FloodFill'-routers, the router (tautology) itself assigns itself' FloodFill '.
Other routers can store information and search data that they will receive by querying for fully populated routers. If the 'FloodFill' router receives a request for storage, then the 'FloodFill' router starts forwarding this message to other 'FloodFill' routers using the Kademlia algorithm. Search queries are implemented differently to prevent security problems, when the search is completed, the 'FloodFill'-router will not send the result to anyone, but will respond if the data is requested.
The network database stores two types of information:
All this information will be signed by the “publishing party” and verified by any I2P router, and will also be saved by it. Also, the stored information contains timestamps in order to avoid the storage of outdated information and prevent some possible types of attacks.
Also some important notes:
If in this case a certain person wants to reach a certain recipient. It is possible this can be done without publishing the destination in netDb. However, you must then transfer the address in another way. For example, an encrypted alternative method leaseSets. This leaseSets can be decrypted by a person with access to the decryption key.
NetDB self-tuning is quite simple. After a router manages to get at least one routerInfo from reachable peers, it can request links from peers to other routers on the network. Currently, users post information about their routerInfo to websites to make it available to everyone. I2P automatically connects to one of these websites to collect routerInfo files and download them.
Searches on the I2P network do not occur over netDb in other routers. Currently, this is not a big problem, as the network is not very large. However, as the network grows, not all routerInfo and leaseSet files will be present on every netDb router. This will lead to a deterioration in the percentage of successful searches. Because of this, fixes to netDb will be made in future releases.
Communication between routers must ensure data confidentiality and integrity, while authentication and authentication must ensure that the router contacts the person who should receive this message. The details of how routers communicate with each other are not important, but we will look at 3 separate protocols that were used in different nodes to provide these “needs”.
The history of I2P began on the basis of the TCP protocol which later ceased to be used. Then, in order to satisfy the high demand for good communication quality (the number of routers eventually only increased), I2P switched from a TCP-based protocol, a UDP-based protocol to “Secure Semireliable UDP” or “SSU”.
As described in the SSU specification:
The purpose of this protocol is to ensure secure authentication, reliable and unordered delivery of messages, leaving a minimum amount of data that third parties can view. It must provide high quality communications as well as TCP friendly load control and may include PMTU detection. It must be able to efficiently transfer large amounts of data at a rate sufficient for home users. In addition, it must support the ability to separate (limit) the network, as most NATs, or firewalls do.
After the introduction of SSU, problems with network “congestion” were solved by a new, based on the NIO-protocol, TCP, which allowed the inclusion of the NTCP-protocol. It is enabled by default for outgoing connections. If you configure NAT / Firewall to allow incoming connections and specify an external host and port (DynDNS and etc), you can use /config.jsp to establish incoming connections. NTCP is based on NIO and does not suffer from restriction to 1 stream as old versions of TCP protocol.
I2P supports different transport protocols. The desired transport protocol for the outgoing connection is selected with a rate. Depending on the rate is selected priority. Transport responds with a different rate, depending on whether there is an already established connection with a partner.
In most situations, the current implementation of NTCP has a higher priority for setting up an outgoing connection. SSU is enabled for both outgoing and incoming connections. Your firewall and I2P router must be properly configured to establish an NTCP connection.
For more information, see the NTCP protocol.
This time it is a little more free, so that the text is read in Russian.
Table of contents:
Part 1: “Everything you wanted to know and were afraid to ask about I2P”
Part 2: Tunnel Magic, NetDB, and Protocol Juggling
Part 3: Digital Garlic
The tunnels
Incoming and outgoing tunnels operate on similar principles. The tunnel gateway accumulates a number of messages from the tunnels, eventually forming a message from it to send to the tunnel. The gateway then pre-encrypts the data and sends it through the first hop. This peer and subsequent tunnel members check if the message is a duplicate by adding another layer of encryption and send it to the next tunnel.
Ultimately, the message gets to the target, after which it is fully decoded and processed by the target itself. The difference lies in the fact that the creator of the tunnel for transit tunnels will be the target, and for the transit tunnels an additional level of encryption. The originator of the outgoing tunnel is a gateway and pre-decrypts the message so that it does not reach the recipient for peers.
The choice of peers and connecting them in a certain sequence is very important for understanding how I2P remains anonymous and productive (Powerful, fast - approx. Lane).
While NetDB (Network Database) (see below) has its own criteria for selecting, querying, and storing peer entries, and a tunnel initializer can use any peers, in any order and number of times in a single tunnel.
If data with the minimum delay and maximum efficiency are available worldwide, then the customer’s needs will be provided based on his requirements, taking into account possible threats. Unfortunately, latency and throughput is not perfect and depends on peers able to provide their own throughput. The provided level of anonymity leaves its mark on the speed of the network.
')
Anonymity is provided simply: peers are randomly selected from the entire network, requests for peers occur randomly and can last forever. Performance is provided by sampling the fastest peers and load distribution between them, to ensure transparency and resiliency. They are also used to restore and rebuild tunnels when there is a change in network bandwidth. Previously, everything was fragile and inefficient: there could be problems with access to information and lack of anonymity was offered.
I2P offers a wide range of different sampling strategies, combined with anonymous organization of peers by profiles.
I2P uses for work constant profiles of peers that it generates by examining their work on the network, for example, if a peer responds to a search in netDB for 1.3 seconds, then information about the route and delays for both tunnels (incoming and outgoing) is recorded in its profile in which all requests and responses of a feast are also recorded. The data obtained in the measurement of transport delays and “jams” is not used as part of the peer profile, but is associated with specific routers.
During the collection of information for profiles, information will be systematized and as a result we will receive information about performance, delays, the ability of the peer to handle large amounts of information, how much it is currently loaded and how well it is integrated into the network. These calculations are carried out for each peer separately, and then peers are compared with each other and put on the shelves: fast and capacious, high throughput, the worker is not working.
Thresholds for distribution across these levels are generated dynamically, and although quite simple algorithms are currently used for this, there are alternatives.
The following text describes very specific points, the term “harvesting” (harvesting attacks) refers to the type of attack that will allow you to make a list of users working with I2P. I would like someone to suggest a better equivalent, this option cuts off my ears.
Client tunnel is deployed by a simple and efficient random sample of peers, one of the best in terms of capacity and speed. Sampling of peers is carried out from netDB, peers used for expansion, have only a certain stability (not failing) and are used to transfer the “hill top” (central load point - approx. Lane). This type of work provides a very weak resistance to attacks such as “harvest”. As a solution, the router may not balance the load between peers, and use mainly only a separate channel to reduce the impact of this attack, but makes the network less resistant to other types of threats.
Receiving a random key, a route is generated by XOR. In the event of a “harvest harvest” attack, the information is lost and the peer reports an error, after which it is turned off.
Another simple strategy to protect against assembling information is to simply regenerate the incoming tunnel, using new peers to create a new tunnel. To cope with the type of attack that targets clients, the outgoing tunnel endpoints must remain unchanged. End, if peers as tunnel endpoints remain fixed, you need to set a connection time limit. A peer, as the end point of a tunnel, can simulate a temporary router failure, as a result the tunnel will be automatically re-created.
These two security strategies can be combined, then fixed participants and the XOR function will be used to create tunnels. A tougher protection strategy implies precise (specific) connections between individual peers that are trusted and participate in creating a route under the same conditions. (Reminds Tor - approx. Lane). The use of XOR implies the invariance of the order and the fact that the initial and final feast is always the same, and XOR only ensures the invariance of the order.
As mentioned earlier, currently I2P (release 0.8) includes a multi-level sampling strategy using XOR. A more detailed discussion of the mechanics of the tunnel, on the management and selection of peers can be found in the specification of tunnels .
Network database
As mentioned earlier, I2P works by exchanging network metadata, which will be explained in more detail below.
A certain percentage of I2P users are designated as 'FloodFill' (Fully Loaded). Currently, the machines on which I2P is installed have a sufficiently high throughput, so in the event of a sharp drop, the number of 'FloodFill'-routers, the router (tautology) itself assigns itself' FloodFill '.
Other routers can store information and search data that they will receive by querying for fully populated routers. If the 'FloodFill' router receives a request for storage, then the 'FloodFill' router starts forwarding this message to other 'FloodFill' routers using the Kademlia algorithm. Search queries are implemented differently to prevent security problems, when the search is completed, the 'FloodFill'-router will not send the result to anyone, but will respond if the data is requested.
The network database stores two types of information:
- RouterInfo stores information on a specific I2P router and how it can be contacted.
- leaseSet stores information about specific destination points (eg: I2P web server, e-mail server, etc.).
All this information will be signed by the “publishing party” and verified by any I2P router, and will also be saved by it. Also, the stored information contains timestamps in order to avoid the storage of outdated information and prevent some possible types of attacks.
Also some important notes:
Unpublished and encrypted leasesets:
If in this case a certain person wants to reach a certain recipient. It is possible this can be done without publishing the destination in netDb. However, you must then transfer the address in another way. For example, an encrypted alternative method leaseSets. This leaseSets can be decrypted by a person with access to the decryption key.
Self-tuning:
NetDB self-tuning is quite simple. After a router manages to get at least one routerInfo from reachable peers, it can request links from peers to other routers on the network. Currently, users post information about their routerInfo to websites to make it available to everyone. I2P automatically connects to one of these websites to collect routerInfo files and download them.
Search Scalability:
Searches on the I2P network do not occur over netDb in other routers. Currently, this is not a big problem, as the network is not very large. However, as the network grows, not all routerInfo and leaseSet files will be present on every netDb router. This will lead to a deterioration in the percentage of successful searches. Because of this, fixes to netDb will be made in future releases.
Transport protocol
Communication between routers must ensure data confidentiality and integrity, while authentication and authentication must ensure that the router contacts the person who should receive this message. The details of how routers communicate with each other are not important, but we will look at 3 separate protocols that were used in different nodes to provide these “needs”.
The history of I2P began on the basis of the TCP protocol which later ceased to be used. Then, in order to satisfy the high demand for good communication quality (the number of routers eventually only increased), I2P switched from a TCP-based protocol, a UDP-based protocol to “Secure Semireliable UDP” or “SSU”.
As described in the SSU specification:
The purpose of this protocol is to ensure secure authentication, reliable and unordered delivery of messages, leaving a minimum amount of data that third parties can view. It must provide high quality communications as well as TCP friendly load control and may include PMTU detection. It must be able to efficiently transfer large amounts of data at a rate sufficient for home users. In addition, it must support the ability to separate (limit) the network, as most NATs, or firewalls do.
After the introduction of SSU, problems with network “congestion” were solved by a new, based on the NIO-protocol, TCP, which allowed the inclusion of the NTCP-protocol. It is enabled by default for outgoing connections. If you configure NAT / Firewall to allow incoming connections and specify an external host and port (DynDNS and etc), you can use /config.jsp to establish incoming connections. NTCP is based on NIO and does not suffer from restriction to 1 stream as old versions of TCP protocol.
I2P supports different transport protocols. The desired transport protocol for the outgoing connection is selected with a rate. Depending on the rate is selected priority. Transport responds with a different rate, depending on whether there is an already established connection with a partner.
In most situations, the current implementation of NTCP has a higher priority for setting up an outgoing connection. SSU is enabled for both outgoing and incoming connections. Your firewall and I2P router must be properly configured to establish an NTCP connection.
For more information, see the NTCP protocol.
Source: https://habr.com/ru/post/161037/
All Articles