Atsign’s Zero Trust Planes

How Data is Transmitted with the atProtocol in NoPorts

In “100 Times Faster Internet,” our co-founder and CTO, Colin, introduces the concept of control and data planes, along with a novel addition, the policy plane. Over the next few weeks, we’ll explore how Atsign leverages these three planes to enhance internet and networking capabilities. 

Data Transmission

The process of data transmission in NoPorts involves three atSigns, each associated with specific components: the NoPorts daemon program (sshnpd) running on the device intended for SSH access, the NoPorts client program (sshnp) used on the device initiating the SSH connection, and the noports TCP rendezvous program (RVD). These programs communicate through the atProtocol and the atClient SDKs, ensuring that their exchanged messages are end-to-end encrypted.

The above image is an overview of how data is transmitted in our remote access tool, NoPorts. We read this diagram starting at the bottom left, the client.

The client creates a GUID (globally unique identifier) for the session. The client sends a request notification to the socket relay host (labeled above as @rendezvous here) for a port1/port2 pair for this sessionID.

@rendezvous’ job (as an actor, specifically as the socket relay host) is to receive requests from atSigns, find a pair of available ports (networking technology provided by the machine’s operating system), and open server sockets for both ports. Once this bridge is established, the socket relay host will send a response to the client. 

After the client receives this response, it will send a request notification to the sshnpd including the session ID and the socket relay host of rvd port 1. 

An srv process will open a socket to the socket relay host of rvd port 1 and open a socket to its local sshd port, rather than the sshnp/sshnpd doing this part of the connection. This allows the sshnpd to be restarted without effecting existing sessions. When both have been opened successfully, it is bridged by the socket relay client and sends a response notification to the client.

The client will issue an SSH command to set up the SSH tunnel and do a local port forwarding. The client will display a message to the owner of the machine that they may now SSH to the device’s local host (labeled above as @linux_mc). 

In the next post, we’ll explain more about the policy plane.

In the meantime, check out our YouTube channel. It’s full of helpful content like remote access tutorials as well as our newest Atsign Engineering Podcast.