MSL-aaSMultiple Secure Link as a Service

MSL-aaS Multiple Secure Link as a Service

Shared infrastructure, separate networks: field devices reach the owners they serve, and only those that have authorized them.

Status A working core, self-tested in an emulated multi-owner environment. Independent testing is scheduled. Not yet in production.

§1 Overview

Many owners at once, kept apart by design

MSL-aaS is designed to give a mobile machine — a drone, a vehicle, a field workstation — independent, simultaneous connections to the private networks of several unrelated owners. Each application on the device connects to the service through its own tunnel. The service connects to each owner's VPN gateway through a separate tunnel, and can open a connection to another owner while the first is in use.

The service keeps its own private address realm, in which every address is unique within the service. As packets enter and leave, it translates source and destination addresses in both directions, giving each owner host a unique address as the host is first seen — or, if the owner prefers, only after approval or by static configuration. Applications on the device see only the service's addresses; hosts in an owner's network see only that owner's private addresses. Owners can therefore keep their ranges, even identical ones, with no changes inside their networks.

Each owner approves exactly which devices may enter its network. Inside an owner's network a device appears under an address from a pool the owner chose, not under its own identity or carrier address.

The link under the device may change; identity is bound to keys, not addresses. Data captured out of coverage is signed on the device at capture and delivered in order when a link returns (demonstrated in emulation only).

§2 Why

Overlapping address space is a documented problem

RFC 5684, Unintended Consequences of NAT Deployments with Overlapping Address Space (Informational, Independent Submission, February 2010), describes how the spread of private networks and remote access over VPNs has increasingly led to overlapping private address space between remote and corporate networks. It notes that such overlap can cause a remote user to lose connectivity to the enterprise entirely, or to an arbitrary block of its hosts.

MSL-aaS is designed for that condition: owners keep their private ranges, even identical ones, and a device can reach several of them at once.

Read RFC 5684 in full →

§3 How it works

Four parts of the design

  1. 01

    Enrol once

    Each application on the device is a client with its own cryptographic key and its own tunnel to the service (a per-application tunnel). Identity is the key. Addresses can change; identity does not.

  2. 02

    Owners decide

    Each owner's network is an owner address realm with its own isolated place inside the service. A tenant requests access for a client; the design allows only the owner to authorize it — the service operator cannot. The owner also sets the NAT binding policy for hosts on its side that the service has not seen before: dynamic, approval-gated, or static-only.

  3. 03

    Addresses stop colliding

    The service translates source and destination addresses in both directions. Each owner realm has its own place in the service's address realm and each host in it a unique address, so owner A's 192.168.1.10 and owner B's 192.168.1.10 are two different addresses inside the service. Owner hosts see only their own owner's addresses. On the owner's side the service connects to the owner's existing IPsec or WireGuard gateway as a standard peer.

  4. 04

    Links change; records keep their order

    The device's link policy fails over from cellular to satellite and back. Data captured out of coverage is hash-chained and signed on the device at capture, stored, and delivered in order; the service records the chain head as a checkpoint in its own append-only log, and the owner can verify the chain itself.

    Emulation only to date
MSL-aaS structure A field device with three clients, each with its own tunnel to its own isolated routing domain in the service. A separate flight controller has no path from the clients. Inside the service, routing domains connect to owner address realms only where the owner has authorized access. Each realm connects to an owner network through that owner's existing IPsec or WireGuard gateway. All three owner networks use the same address range, 192.168.1.0/24; the service translates addresses in both directions, so the identical ranges never meet. The three client tunnels share one radio link, cellular or satellite. Field device MSL-aaS service Owner networks Client 1 · own key Client 2 · own key Client 3 · own key Flight controller no path from clients Domain 1 Domain 2 Domain 3 Realm A Realm B Realm C One routing domain per client, one address realm per owner. Domain-to-realm lines exist only where an owner authorized. one radio link cellular or satellite Owner A · 192.168.1.0/24 IPsec or WireGuard gateway Owner B · 192.168.1.0/24 IPsec or WireGuard gateway Owner C · 192.168.1.0/24 IPsec or WireGuard gateway client tunnel authorization (owner-issued) owner's gateway peering isolated by on-board policy
By design, an owner's authorization is the only path between a client and that owner's network. The service translates addresses in both directions, so the three identical owner ranges never meet.

More on how it works →

§4 Scope

What it is not

  • It does not replace an owner's VPN gateway.
  • It is not a drone command-and-control link: it defines no command or control traffic class and is designed to give payload applications no path to the flight controller.
  • It is not a U-space or air-traffic service.
  • It contains no machine learning.

§5 Status

Current status

  • Not in production.
  • Not yet run over a real cellular or satellite link; handover, outage and delivery behaviour are shown in emulation only.
  • Results to date are self-run in emulation; independent testing is scheduled, not done.

§6 Deployment

Deployment

The lead offer is a licensed platform: the licensee runs the whole service in its own network, under its own identity, for its own customers. E^NAT IP licenses the software.

§7 Pilot

Apply for a pilot

Tell us which owners' networks your devices need to reach. Scope, timing and terms are agreed individually.

Tenancy is by enrolment only; there is no public sign-up. You can also write to Don@ENATIP.com.

How we handle what you send: privacy notice.