Secure & Trusted Domain Management
To securely manage multiple geo-distributed domains, ETSI HypO employs a programmable network fabric as shown in Figure 1. The idea is based on the concept of software-defined perimeter (SDP), which builds a domain’s network perimeter in software, rather than hardware. The fabric's administrator can register and authenticate infrastructure owners and allow them to expose domain infrastructure resources and services through the fabric.
To materialize this service, ETSI HypO employs OpenZiti; an open-source secure networking platform that provides both zero-trust security and overlay networking as pure open source software. A dedicated service is used by ETSI HypO to interact with OpenZiti in a dynamic fashion. A detailed description of the OpenZiti security features is available here.
Fabric Service
The Fabric service establishes a programmable encrypted software-based overlay network backbone over the Internet, where various domain resources and services may register, thus rendering themselves accessible from other members of the fabric.
The Fabric is comprised of two core components that are exposed through a single domain name https://ztc.euprojects.net as follows:
- Fabric Portal:
https://ztc.euprojects.net:8443/login/ - Fabric Controller:
https://ztc.euprojects.net:8441
In addition to these two core components, a set of distributed Fabric Clients which act as edge routers that authenticate against the core Fabric and provide connectivity towards the Fabric. All of these components are described below.
Fabric Controller
The Fabric Controller acts as a configuration element of the fabric, allowing the fabric's owner to add/remove nodes and admit/discard services via APIs. A portal allows users to manage the Fabric Controller via user-friendly views.
Fabric Router
One or more Fabric routers act as forwarding elements of the Fabric network as shown in Figure 1.
Fabric Client Service
The Fabric Client service is a software package that new domain infrastructure owners obtain upon successful registration of their domain(s) to the ETSI HypO portal. This piece of software is deployed with a single command and uses an authentication token (also obtained during registration) to authenticate against the public Fabric Fabric service. At this point the new domain becomes part of the Fabric network (i.e., part of the ETSI HypO platform), however, no services of this domain are exposed through the fabric yet. To do so, the domain infrastructure owner needs to issue another call to the Fabric Fabric service, asking for specific services to be added into the fabric’s network. At that point, these services become accessible by other parties of the fabric (e.g., the remote ETSI HypO instance).
Three Fabric Client service flavours are available in Table 1, depending on the needs or technological preferences of the domain owner.
| Fabric Client Name | Fabric Client Software | Description |
|---|---|---|
| Host tunneller |  |
Exposes available resources of a physical and/or virtual host. |
| Edge router tunneller | |
Exposes available resources of multiple physical/virtual hosts in a Local Area Network (LAN). |
| K8s tunneller |  |
Exposes available resources (e.g., pods) within a Kubernetes cluster. Gets deployed as a pod. |
Central Fabric Domain
One or more core Fabric routers along with the Fabric controller are deployed on a public domain (e.g., the ztc.domain.io shown in Figure 1). This domain is the root of trust of the Fabric network, thus must be accessible from every managed domain.
Fabric Managed Domains
Every managed domain that wishes to join the Fabric network must employ one or more instances of the Fabric Client service. Figure 1 shows an example deployment with a central management domain (where ETSI HypO is deployed) and several underlying managed domains, where multiple OSS instances manage the domains' resources and expose them through the Fabric network. In this setup each of the domains use a Fabric client service to connect to the central Fabric service located in the trusted domain shown in gray.
Fabric Security
Ziti networks use robust modern cryptography and security mechanisms. Each component within an OpenZiti network uses security technology that fits its role and use-cases.
Here are the different types of connections:
control- connections between a controller and a router that manage network state. Secured via mTLS 1.2+link- connections between routers to form a mesh network. Secured via mTLS 1.2+edge- multiplexed connections between an SDK and an Edge Router that carries service connections. Secured via mTLS 1.2+controller APIs- connections between a controller and an SDK (or other software) via HTTPS and/or secure websockets. Secured via TLS, mTLS 1.2+service- connections carried by an edge connection and establish communication between a client and host. Application data is end-to-end encrypted via libsodium public private key cryptography.
Figure 2 shows the control, link, edge, and controller API connections. The service connections exist within an edge connection and are pictured in more detail in Figure 3.
Connections between SDKs and Edge Routers are called edge connections.
edge connections are multiplexed and carry multiple service connections.
Each connection is for a specific service and secured with end-to-end encryption in order to transport application/service data securely between the two intended parties only.
More details about Fabric connections and Fabric in general can be found online.