rns.recipes

I want to propose a new interface mode that seems to be missing for a specific but typical use case: An node thats both connected via a slow interface like LoRa as well as via a fast one like Backbone interface. The usual configuration is to set the fast one to Boundary mode and the slow one to Access Point mode. This prohibts the fast interface to spam the slow interface with announces. But it also severly limits the capabilities of the slow interface. It will now (according to my knowledge) also prohibit the propagation of announces coming to the slow interface (via LoRa for example). If the node has a slow interface only the mode would be set to Gateway, and it would propagate everything it receives as usual. But once the announce reaches a node thats also connected to a fast interface the announce will not be relayed further. This acts like a blockade and will split networks announce-wise if there is no other way around the AP mode node.

I have seen RTNode "solve" this by adding some sort of firewall logic, but I dont fully trust this project and would like to see a solution in the reference implementations as well.

Maybe there is a good reasonig for things working as they are right now, I would love to hear them. Right now it seems to me that there should be another mode (lets call it ap-boundary) that only propagates announces from other ap-boundary interfaces as well as gateway interfaces, but announces coming from boundary interfaces would not be propagated. Maybe (probably) there is a better way to solve this, I would like to hear your thoughts about this.

This made me realise, that I still don't fully understand announce propagation rules. Especially when announcements are rebroadcast on the same interface they came in.

I think they are rebroadcast on the same interface if transport is enabled, the mode is something other than AP and it's some kind of radio interface like Rnode. If so, you could use a combination of boundary and roaming for that usecase. But I'm not 100% sure.

Some more fine grained options would be nice. Like some setting per interface what gets send where and which interface is set to transport. On the other hand stuff works ok as it is and other things might be more important.

https://rns.recipes/forum/showcase/reticulum-announce-propagation-simulator

aetherlab wrote:

https://rns.recipes/forum/showcase/reticulum-announce-propagation-simulator

It would be super nice to have the option to have one of the central "hub" nodes to have an AP mode interface for the connection to the other node. It would show my point exactly :) it would result in two separate networks, at least in one direction.

Ok, thanks to aetherlab I figured it out. You can try it in the simulator: Add a intermediary node, set both directions to AP (you can imagine a third direction from the intermediary going to the testnet via boundary mode) and announce from one of the two network segments. The node acts as a blocker between those segments.

In case others have this question as well: one workaround to the limitation described is to have another interface in between the slow and fast interface. For example:

• a microreticulum transport node with lora (full mode) and a udp interface (full mode)
• a raspi with an UDP interface connected to the microreticulum node (access_point mode) and a backbone interfave to the testnet (boundary mode)

That way the lora interface is still propagating lora announces and is also able to get connections from the testnet without broadcasting the testnets announces to the lora network.

In theory this could also be implemented on a single device, for example a raspi with a regular rnode connected. You would have to run a second rnsd and connect them both in the above mentioned way. Never tried that, but thats what the shared instance is for I think.

Seems like there will be a new interface in the next release! Just found this in the latest commits:

The internal mode designates interfaces that belong to an network different from any marked as boundary. Announces from a boundary interface will not propagate to interfaces set as `internal, but announces *will* propagate from internal*to*boundary. Devices on the internalside of the network will still be able to resolve paths to destinations across the boundary when needed, since recursive path requests are enabled forinternal`` mode interfaces by default.

Didn't see this post til now, but I just want to give me two cents from what I've experienced working on RTNode

The one thing I don't think can be handled purely with announce propagation is RAM (or other system resources). Reticulum kind of expects you to just keep track of every destination and every path on the network. That works fine for even moderate spec computers, but definitely not the ESP32.

That's why I took the "Firewall" approach. RTNode doesn't just tell the interface, "please don't send me these announces". It says "if you're not on my list, you are dropped at the front door." Not just announces, either. No packet gets through

I personally don't mind an elegant solution like the announce filtering. I believe it is supposed to be a kind of mutually beneficial cooperation contract. However, I am of the firm belief that no node is to be trusted. Hence I feel it is important not only for a node to take individual responsibility to protect itself, but for such custom implementations to be an expected part of the ecosystem

In my view, Reticulum must be designed with sheer physics as its security. Relying on cooperation is a recipe for vulnerability

jrl290 wrote:

Didn't see this post til now, but I just want to give me two cents from what I've experienced working on RTNode

The one thing I don't think can be handled purely with announce propagation is RAM (or other system resources). Reticulum kind of expects you to just keep track of every destination and every path on the network. That works fine for even moderate spec computers, but definitely not the ESP32.

That's why I took the "Firewall" approach. RTNode doesn't just tell the interface, "please don't send me these announces". It says "if you're not on my list, you are dropped at the front door." Not just announces, either. No packet gets through

I personally don't mind an elegant solution like the announce filtering. I believe it is supposed to be a kind of mutually beneficial cooperation contract. However, I am of the firm belief that no node is to be trusted. Hence I feel it is important not only for a node to take individual responsibility to protect itself, but for such custom implementations to be an expected part of the ecosystem

In my view, Reticulum must be designed with sheer physics as its security. Relying on cooperation is a recipe for vulnerability

I dont really understand how things you are describing work. Interface modes dont need any lists of destinations, its about general behaviour of the interface, right? The behaviour you are describing with RTNode sounds more like "keeping track of destinations" actually :) But I must not get something. How is this saving on limited resources?

Anonymous wrote:

I dont really understand how things you are describing work. Interface modes dont need any lists of destinations, its about general behaviour of the interface, right? The behaviour you are describing with RTNode sounds more like "keeping track of destinations" actually :) But I must not get something. How is this saving on limited resources?

The way Reticulum works is: dest announces, node sees dest and inserts into path and public key tables, node passes announce forward. Every announce that gets received gets database entries.

That's where the interface modes come in. Now supposing you have a transport node sitting between your small branch of network and hundreds of nodes on the other side. You do not want hundreds of announces flooding your small branch of network, especially if it's low bandwidth, so you set up the transport node to filter announces for you. That transport node does its job, keeping track of hundreds of destinations. And when you want to send to one of those addresses, you just send to the transport node and it handles the rest

But what if that transport node doesn't have the memory to track all of those devices? When a new announce comes in and there's no memory left, the transport ejects the oldest member from the table. That works fine, unless there are more simultaneous active devices than there are table slots. Then the slots just rotate indefinitely. When your small network device tries to reach out, the transport node may or may not have a valid entry for the destination.

The standard solution to that is, the packet is dropped, the sender declares the path dead, a path request is posted, that path request triggers a fresh announce by the destination or a cached replay by an intermediary node, and the path is rediscovered. But your transport node still doesn't have enough memory to hold all of the announces on the network, so you end up with the same problem again

Despite the number of interface modes there are, in the standard mechanism, you are sent a set of announces and you put them in the path table. And you might ask, why not just keep the announces you want and discard the others?

And my answer to that is: yes

So RTNode keeps two whitelists: LAN side destinations, and the destinations referenced in any packet that contains a LAN side destination.

I don't necessarily understand interface modes as an oversight. I see it as a network optimization. Something to say "hey, you over there can conserve bandwidth on this". That's why it's part of the protocol. I think it's still perfectly within spec to have other means of filtering that don't require agreement with any other nodes

Thanks for the explanation, makes sense, and yes, the additional filtering is of course something you are allowed to do. So you basically collect all announces from the "LAN side" or LoRa side in most cases, and only process requests coming from the "WAN side" or testnet usually if they are in relation to any of those known destinations? So as an example, if the node would not yet know of a LoRa destination, and has not yet received an announce, a testnet path request to it would be ignored by the RTNode. And in general, no announces from the testnet side would be stored at all on the RTNode? Wouldn that also mean that if a LoRa node has the destination of a testnet node it is unable to reach it via this RTNode? Or does it just not store the path after it requests it?

Anonymous wrote:

So as an example, if the node would not yet know of a LoRa destination, and has not yet received an announce, a testnet path request to it would be ignored by the RTNode. And in general, no announces from the testnet side would be stored at all on the RTNode? Wouldn that also mean that if a LoRa node has the destination of a testnet node it is unable to reach it via this RTNode? Or does it just not store the path after it requests it?

I'm not 100% certain I'm understanding the question, but a node doesn't know how to route to a destination until an announce is sent. That goes for all reticulum. And it goes for the primary whitelist for LAN side destinations in RTNode

After that, any path request coming in through the WAN side will get through as long as it's addressed to a LAN side device. And when a LAN side device requests a path from a WAN side destination, that destination gets stored in the secondary whitelist. So the reply announce from that destination makes it back through the node

1. If its configured as a transport node amd has no announce of the requested destination yet, I expected it would try to request the missing announce as part of the path discovery function. This would not work with the firewall if I am understanding it correctly.
2. If you carry a LAN destination with you without ever communicating from this device with the rtnode (out of band kind of) and then get connected to the testnet amd try to communicate with something on the LAN side of the rtnode it would block this reques.

Does it make more sense?

Still not entirely sure

A path request is an announce request. A transport node doesn't create path requests. It answers them from its cache or it forwards them. This is true of both RTNode and standard transport nodes. RTNode is always a transport node

The difference is that RTNode has its TCPClientInterfaces designated as the WAN. That is what you would connect to the testnet/backbone/public network. The RNodeInterface and local network TCPServerInterface are designated as the LAN

RTNode blocks all packets from the WAN side that don't contain an address in its whitelists. It drops them as soon as possible in order to spend as little processing on them as possible. It doesn't update its path tables. It doesn't forward announces. And it doesn't answer or forward path requests. When it comes to the public network, that is thousands of packets.

If a LAN device has not announced, RTNode doesn't know it's there. It isn't added to the whitelist. A device should always announce when it joins a network. If for whatever reason that LAN device sends packets before announcing, those do not get blocked. The Firewall only acts on traffic coming in from the WAN side

Next try then :) I can see that my last explanation was written too quickly and is hard to read actually.

1. You have a device somewhere in your lora network. The rtnode that is connected to the testnet has for whatever reason not yet received an announce from this device. For example a node in between was faulty and the device has not yet announced again. The rtnode would then block connection requests for this device coming from the testnet. (The destination was transmitted out of band here) Communication would still work with the reference implementation I think.

2. I cant seem to make sense out of it now to be honest. Ignore it.

1. That is correct
2. 👍
   Cheers!