str4d / ire

I2P router implementation in Rust

Ire: the I2P Rust engine

Ire is a Rust implementation of an I2P router, designed to participate in the global, decentralised I2P network.

Development Status

Ire is in pre-alpha; much of the internal architecture still needs to be defined and implemented.

Implemented Features

• Cryptographic primitives
  • Signing
    • ECDSA_SHA256_P256
    • ECDSA_SHA384_P384
    • ECDSA_SHA512_P521
    • Ed25519
  • Verifying
    • DSA
    • ECDSA_SHA256_P256
    • ECDSA_SHA384_P384
    • ECDSA_SHA512_P521
    • RSA_SHA256_2048
    • RSA_SHA384_3072
    • RSA_SHA512_4096
    • Ed25519
  • ElGamal
  • AES256
• I2NP
  • Message parsing
  • Message handling
• NetDB
  • Local storage
  • Persistence to disk
  • Reseeding
  • Lookups
  • Expiry
  • Exploration
  • Publishing
  • Floodfill
• Transports
  • Transport manager
  • NTCP
    • Handshake
    • Session tracking
    • Automatic session creation
  • NTCP2
    • Handshake
    • Session tracking
    • Automatic session creation
  • SSU

Usage

The binary implements a router, along with a basic client that can be used to test the various transports:

1. Create a router.toml file and configure the router. See examples/router.toml for available configuration options.

2. Run the router:

$ RUST_LOG=ire=debug cargo run --features cli --release router router.toml

3. Generate keys for the client:

$ cargo run --features cli --release cli gen client.router.keys.dat

4. Run a client:

$ RUST_LOG=ire=debug cargo run --features cli --release cli client client.router.keys.dat router.info [NTCP|NTCP2]

Code of Conduct

We abide by the Contributor Covenant and ask that you do as well.

For more information, please see CODE_OF_CONDUCT.md.

Contributing

Bug reports and pull requests are welcome on GitHub at https://github.com/str4d/ire

Copyright

Copyright (c) 2017-2023 The Ire Developers. See LICENSE.txt for further details.

ire's Issues

Deduplicate state machine in NTCP engine

NTCP handshake messages don't have IDs, and are identified based on send order. As a result, there are currently two state machines inside the NTCP engine:

• IBHandshakeState and OBHandshakeState in HandshakeTransport.state, which handle the higher-level state transformations.
• HandshakeState in InboundHandshakeCodec and OutboundHandshakeCodec, which defines which handshake message the codec is listening for or expects to be sent.

The reason for having two separate state machines is that HandshakeTransport calls stream.framed() to get a Framed transport that wraps the stream with a codec, and then itself wraps that transport. This makes it tricky to have a single state machine that is used by both parts of the engine (bearing in mind that I wrote the engine partly as an exercise in learning Rust). But having two state machines that are supposed to always be in sync is clearly prone to bugs.

We should deduplicate the state machine. I can see two ways of doing this:

• Give a remote reference to the HandshakeTransport state machine to *HandshakeCodec (which is probably easier than I think it is using something like RefCell, which I still need to learn about).
• Remove the use of Framed by implementing stream framing in HandshakeTransport, and pass the state machine through to the codec.

Config handler

Should support:

• Configuration via a TOML file or programmatically via the builder.
• Watching the file for changes (though some settings will require a restart to take effect).
• Separate configuration per-router (i.e. not a global static).

https://crates.io/crates/config looks like a good crate to leverage.

NetDB exploration

The local netDB should regularly explore the global netDB for new routers, by searching for random hashes.

Implement X25519 RouterIdentity keys

These are now appearing in reseed bundles, causing parser failures.

At the same time, we should make parsing of RouterInfos more resilient by adding some way to represent Unknown key types (given that a KeyCertificate can indicate its total length).

Implement ECDSA signing

Stretch goal. By default Ire will use Ed25519 for locally-generated keys.

Migrate to `signatory 0.26`

The signatory-* crates have been abandoned in favour of native support for the traits signatory uses in each concrete provider. ed25519-dalek provides this, but I don't know if ring does (and even if it does, we currently pin a fork of it with I2P-specific modifications).

IPv6 support

Implement ElGamal

There aren't any existing Rust crates that provide this, so we'll have to implement it ourselves.

Implement DSA verification

Required for legacy Destinations, and the occasional old Router. I haven't found any Rust crates that provide it, so we'll likely need to implement it ourselves.

Support for outbound-only transports with no listeners

Migrate from `tokio 0.1` to `tokio 1`

This is going to be absolutely hellish. I started ire in 2017 as a way to learn Rust, and decided the best way to do that was to dive head-first into 2017-era async Rust. Things have changed... a bit... since then.

Implement a transport manager

This should be a modular wrapper around the various transports. It should provide a way for callers to send I2NP packets to a peer without needing to care about the available transports, and to register for receiving incoming I2NP packets.

DD-WRT / OpenWRT participant plugin

Enable simple deployment of Ire in participant mode on devices running DD-WRT or OpenWRT. This would be a way for users to easily contribute to the network; it would not enable them to run I2P services themselves.

Depends on #47.

Implement SSU transport

Remote NetDB lookups

If a RouterIdentity hash or Destination hash is not known to the local netdb, it should trigger a lookup from a known floodfill.

Participant mode

It should be easy to configure Ire as a purely-participating router, i.e. a router that:

• Integrates itself into the network (via netDB exploration, possibly with a few exploratory tunnels).
• Collects peer profiles.
• Accepts tunnel build requests.
• Routes tunnel messages.

It might make sense to have this be a separate binary, that can be easily compiled and deployed (e.g. as a Docker image).

In order to be as lightweight as possible, this mode should probably not enable floodfill mode (#46).

Clear pending session data if transport handshake fails

Currently, if a message is sent to an unconnected peer, but the transport handshake fails, the message persists in the pending session cache for that transport. When a subsequent message is sent to that peer, the presence of the peer in the pending session cache means that it is also cached, on the assumption that a session is pending. The result is that if a connection fails to a peer due to transient issues, it can never be reached again within the current router.

Trying to establish contact

Hey @str4d this is zab. I know this isn't suitable for a GitHub issue, so feel to free to close or even delete it after you read it.

I've been trying to reach you on Twitter as well as LinkedIn. I'm very interested in contributing to Ire and intend to start learning Rust. That's all I have to say on GitHub, if you're interested to hear more, reach to me via those other channels.

zab.

Implement ECDSA verification

Some Destinations and routers use this type of signature. There are crates that provide at least P-256 and P-384 (e.g. ring), and it should be possible to extend them to support P-521 as well.

Floodfill mode

Meta-issue for implementing the various extra mechanisms necessary to operate as a floodfill router:

• Kademlia DHT.
• Keyspace rotation.
• Flooding.
• Changes to netDB exploration.
• DatabaseLookup message-handling.
• DatabaseStore message-handling.
• Automatic enabling of floodfill mode as appropriate (with config overrides).

Unified error-handling

Given that Ire is intended to be usable as a library, we need good error-handling with a usable interface and sufficient context. The failure crate is probably the best base to build upon.

Implement ECDSA_SHA512_P521 verification

Uncommon generally, so there aren't any good implementations available compared to P256 and P384.

Generate and update local router's capabilities

Requires the ability to:

• Configure, measure, and rate-limit bandwidth.
• Detect reachability.