Why

In order to allow relays with custom properties, and to regulate resources, there needs to be a way to authenticate iroh nodes.

How

The general idea is to restrict the NodeIds that can connect to a relay, and use the fact, that this is already communicated in the initial handshake.

• extend ClientInfo to include the NodeId of the client connecting
  • this doesn’t work, as it doesn’t authenticate, we need to actually sign a challenge to make this work, so the handshake has to go back to a similar construction than what we had before it was optimized
  • server sends random 32byte challenge
  • client responds with a signature over the challenge, and their NodeId
  • server verifies the signature
• extend the configuration of the relay server to include a new configuration option

enum Access {
  /// Allows anyone
  Everyone,
  /// Will only allow nodes for which this function returns `true`
  Restricted(Box<Fn(NodeId) -> bool>),
}

// In the toml config we could add these options, for more complex use cases
// a custom iroh-relay binary is required, using a custom implementation of the 
// validator function of `Access::Restricted`

enum AccessConfig {
  /// Allows everyone
  Everyone,
  /// Allows only these
  Allowlist(Vec<NodeId>),
  /// Allows everyone, except these
  Denylist(Vec<NodeId>),
}

• in the handshake, when the NodeId is not allowed reject it

Benefits

• this access restriction is general enough, that it can be used for more complex usage in other scenarios, like blocking abusive nodes
• there is no additional tokens or other things that need to be stored in the configuration when adding a relay
• No need to design or settle on a specific authentication mechanism, other than what we already use
• this is the simplest solution I could come up with

Drawbacks

• requires multiple API calls the first time when authenticating with a service, or when continously changing the NodeId
• requires making a custom iroh-relay binary for complex use cases (this is likely to be the case with any solution)
• [b5] traffic is not attributable in a multi-tentant context: Multiple clients can allow-list the same node