NAT puncturing?

[ichorid]

Hi!
If we are to create a true p2p network using Ockam, we'll have to do NAT puncturing, and that means UDP transport. A p2p layer would then require a bootstrap (introduction point) service.
How would the p2p transport + NAT puncturing + bootstrap fit into the Ockam framework from the architectural standpoint?

[mrinalwadhwa]

@ichorid 👋 great question!
NAT puncturing has been on our roadmap, as a topology we want to support, since the beginning, so Ockam's architecture can easily support it even though we haven't done much work towards it yet.

1. In Ockam, we would implement this by implementing a Channel. A channel is a pair of workers (one on each end) that can arrive at some coordinated state by running a bootstrap protocol. After this bootstrap, a channel provides bi-directional communication. Ockam Secure Channels, Forwarding, Inlets/Outlets etc. all work like this. For a NAT Puncturing Channel we would similarly have a bootstrap phase to communicate with the introduction point and then a data phase for the peer to peer messages.

2. Once a NAT Puncturing Channel is established. All higher level protocols will simply work, without any change to them, by sending messages to the channel workers. This includes protocols for end-to-end encrypted Secure Channels, Authentication, Authorization, Credentials, Message Delivery properties etc.

3. Naive UDP Transport implementations exist for both Rust and Elixir
   https://github.com/build-trust/ockam/tree/develop/implementations/rust/ockam/ockam_transport_udp
   https://github.com/build-trust/ockam/tree/develop/implementations/elixir/ockam/ockam/lib/ockam/transport
   These work within a local network and we can have multi-hop end-to-end secure channels over them. But as you mentioned these won't work when NAT is involved.

4. A piece that is somewhat similar is the Forwarding Service and Remote Forwarders. They allow someone behind a NAT to make an outgoing TCP connection with an Ockam node that is reachable on the Internet and register a forwarding address with this node. Other nodes can then reach the node behind the NAT using this forwarding address. We can then establish end-to-end encrypted channels over this forwarding topology. This of course moves all messages through a central node unlike a UDP NAT puncturing based design.
   Here's the code for forwarding in Rust and Elixir

• https://github.com/build-trust/ockam/blob/develop/implementations/rust/ockam/ockam/src/forwarder.rs
• https://github.com/build-trust/ockam/blob/develop/implementations/rust/ockam/ockam/src/remote.rs
• https://github.com/build-trust/ockam/blob/develop/implementations/elixir/ockam/ockam_services/lib/services/forwarding.ex
• https://github.com/build-trust/ockam/blob/develop/implementations/elixir/ockam/ockam/lib/ockam/workers/remote_forwarder.ex

If you would like to work on implementing such a NAT puncturing channel in a PR, we would love to help along the way!!

Welcome to our community 🥳

[ichorid]

Thanks for the excellent answer! 👏 Our team will definitely consider contributing to Ockam!

[mrinalwadhwa]

Glad it helped. If you're open to it, I would love to learn more about what you / your team is building. My email is [email protected]