Private networking

What UNP is

UNP is UniNet's addressing and routing layer. A service is reachable at an address that is not derived from the machine hosting it, and a request reaches that service through a chain of relays arranged so that no single relay holds the complete mapping between a user, a service and the infrastructure running it.

The problem it addresses is that in a conventional deployment the address is the topology. A name resolves to a host address, the host address belongs to a machine, the machine belongs to a provider in a region. Anyone who can reach the service can also enumerate what sits behind it, because reachability and disclosure are performed by the same record.

Addressing

A UNP address is a binding, not a derivation. It identifies a service; it is not computed from, and does not encode, the location of the machine currently serving that service. Resolution happens inside the network rather than by handing a client a host address to connect to directly.

| | Conventional record | UNP address | | --- | --- | --- | | What a client obtains | the host address to connect to | a service address | | What that discloses | provider, region, machine | that the service exists and is reachable | | Moving the workload | the record is re-pointed at a new host, which is disclosed in turn | the binding changes; the address a client holds does not | | Who needs the host address | every client | the relay that delivers the last hop |

The practical consequence is that the set of parties who learn where a workload runs is a design decision rather than a side effect of being reachable.

Routing, and what each hop learns

Requests traverse relays. Each relay is given what it needs to forward the request and nothing beyond that, so knowledge of the full relationship is partitioned across the path rather than concentrated at any one point.

   User ──▶ Relay 1 ──▶ Relay 2 ──▶ Relay 3 ──▶ Service
                                                   │
                                          runs on a host whose
                                          operator can see it

| Hop | Learns | Does not learn | | --- | --- | --- | | User | a service address | the machine serving it | | Relay 1 | the user it received from, and the next hop | which service is being addressed | | Relay 2 | its predecessor and its successor | either end of the path | | Relay 3 | the service it delivers to, and the hop it received from | the user | | Host operator | the workload on the machine, and its traffic at the endpoint | — |

The middle relay is what makes the split hold. Remove it and the first and last hops become adjacent, at which point one participant sees both the user and the service and the partition collapses. The last row is not an omission: it is the part of the design a reader is most likely to assume away, and it is stated below.

Threat model

This is a routing architecture. It is not an anonymity system, and UniNet does not claim to make a user, a service or an operator anonymous.

What the design addresses:

• A client that needs to consume a service without learning which machine, provider or region runs it.
• A single relay operator attempting to reconstruct who is talking to what. One relay holds one hop.
• Enumeration from outside. The serving machine carries no published record identifying it as the host of a given service.
• Relocation. A workload can move between machines without redistributing an address or coordinating with clients.

What the design does not address:

• The host operator. Isolation at the endpoint is container-level. An operator with root on the machine is inside the trust boundary, not outside it. If the party you are defending against is the party running your workload, this layer is the wrong tool.
• An adversary with many vantage points. Partitioning knowledge raises the number of positions an observer must hold. It does not defeat one who holds enough of them, and it does not by itself defeat timing or volume correlation across a path.
• Path capture. A party operating every relay on a given path observes that path.
• The application layer. A service that publishes its own location, or a payload carrying identifying data, defeats the property the routing layer provides beneath it. UNP addresses routing metadata, not what your protocol chooses to say.
• Compulsion. An operator who can be required to disclose what they hold will disclose what they hold. The design limits what any one of them holds; it does not change the legal question.

Treat the properties above as design intent to read and test rather than as controls to cite.

How it composes

A UNP address binds to an identity that controls a key, so the entity reachable at an address is the entity holding that key, and relays forward without resolving it.

Reachability is not permission. A request that arrives over UNP is still authorized against delegated authority, which is carried with the request rather than inferred from network position. Having a route to a service confers nothing.

The service at the far end runs as a bounded workload — see execution — on capacity reserved from an operator. UNP is what makes the placement of that workload an internal detail of the network rather than a published fact about it.