More use-cases added

1.  Establishes and maintains a trust-based relation between itself and the devices.

To initialize a trust-based relationship between this type of network managment system and connected devices, both store credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers. These credentials are used during initialisation to create the trusted relationship between the NMS, the devices and, if present, with the IoT device business logic. Credential or key initialisation, and key enrollement or establishment limit the NMS's ability to establish a trusted relationship to the intended devices, an ability further limnited as these methods require physical access or close proximity to the IoT device. For example, an IoT devicve user can pair the IoT device and establish a trust-based relationship with the NMS through Bluetooth (tm) mechanisms or with a physical cable connection.

To initialize a trust-based relationship between this type of network managment system and connected devices, both of which store credentials, usually in the form of pre-installed keys, identity confirming certificates, or unique serial numbers. These credentials are used during initialisation to create the trusted relationship between the NMS, the devices and, if present, with the IoT device business logic. Credential or key initialisation, and key enrollement or establishment limit the NMS's ability to establish a trusted relationship to the intended devices, an ability further limited as these methods require physical access or close proximity to the IoT device. For example, an IoT devicve user can pair the IoT device and establish a trust-based relationship with the NMS through Bluetooth (tm) mechanisms or with a physical cable connection.

Once the trust-based relationship has been established, the NMS can provide cryptographically protected configuration and update services to the devices at runtime. Depending on the initial NMS and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device. The trust-based relation can also provide for secured identification, authentication, and communication with other applications on a device.

Once the trust-based relationship has been established, the NMS can provide cryptographically protected configuration and update services to the devices at runtime. Depending on the initial NMS and managed element configurations, the device can either request its configuration from the NMS, or the NMS can push the configuration to the device. The trust-based relationship can also provide for secured identification, authentication, and communication with other applications on a device.

The IoT network NMS collects the meta traffic data and management related data from networked devices, or forwards it to other systems for data collection and storage. All data transmitted from the devices to the NMS and all data transmitted from the NMS to the devices is cryptographically protected with authentication of the endpoints, and with integrity and confidentiality protection. Independent of any of the host system's capabilities, the NMS can also be remotely accessible.

**Figure 4.4.1.2-1: Home network deployment**

In this use case, the network manangement system controls the user's home network of devices and an access point providing connectivity for the user's home to outside networks, usually public.  Access points are devices such as a router, switch, modem, or other wireless or wired device controlled and governed by the NMS and physically deployed to the user who requests service's home. An access point also make the upstream connection technology transparent to the user through the NMS.

In this use case, the network manangement system controls the user's home network of devices and often acts as a gateway or an access point providing connectivity for the user's home to outside networks, usually public.  Access points are devices such as a router, switch, modem, or other wireless or wired device controlled and governed by the NMS and physically deployed to the service requesting users home.

The NMS in this use case is most often locaslly installed on the access point device but may be running on a different device within the same network, or as a remote service, an RDPS.

The device can also make the upstream connection technology transparent to the user. Depending on the available infrastructure in the deployment location, connectivity can be through a variety of alternatives, including a mobile network or fiber optics network.

The access point devices actrively send metrics to the NMS and can serve multiple devices in the same network.  Acces point devices also provide supporting services like DHCP and DNS caching, but beyond such a minimum they can offer more extensive services such as remote connectivity options like VPN server depending on the product.

The NMS in this use case is most often locally installed on the device but may be running on a different device within the same network, or as a remote service, a RDPS.

Meterics from the access point and other deives within the home network are forwarded to the NMS, where the user can percieve these meterics and control the configuration of each networked device.  In many deployments actual configuration control and review of metrics collected by ther NMS is achieved with an additional service or alternate piece of software, most often a browser, but sometimes is other ways, such as through a command-line interface.

The devices can actively send metrics to the NMS and can serve multiple devices in the same network. The devices can also provide supporting services like DHCP and DNS caching, but beyond such a minimum they can offer more extensive services such as remote connectivity options like VPN server depending on the product.

Meterics from the devices and other elements within the home network can be forwarded to the NMS, where the user can percieve these meterics and control the configuration of each networked device. In many deployments actual configuration control and review of metrics collected by ther NMS is achieved with an additional service or alternate piece of software, most often a browser, but sometimes is other ways, such as through a command-line interface.

### 4.4.2 Multi-user deployment

Whyile it is possible to maintain the identities of all of available intranet services by hand, this is often impractical even with a moderate pool of users. A contemporary enterprise NMS deployment will instead rely on an Identity Provider (IdP) for most or all of its services. IdP's may be part of an NMS or seperate, decoupled from the NMS. Likewise IdP's can be implemented locally or as a remote service, including as an RDPS. In all varieties the nature of the IdP deplyed to the netowrk is relevant to this document as it is a major risk factor, especially if the NMS product does not support a relevant integration methods or IdP technique.

> NOTE: Again this use case seems to focus on one function (IdP) rather then on the operational environment and users. It is also not strcutured like the above use cases and finally, migh tbenefit from being broken down into higher and lower risk (smaller/larger or low security data/high security data) use cases.

As the importaqace of the operational context rises, so does the level of accuracy needed to securely manage identity.

A larger enterprise has more staff, roles, job, and responsibility rotation, required services, data classes, levels of classified information, and working sites.

The increase in size and complexity contribute to increasing multiple risks that requires more elaborate management structures.

While many small businesses can perform the credential cleanup on former employees by hand, a large enterprise is likely to find this difficult, and see the value of deploying an administrator credential management service.

Additionally, entities within this context may store and work with extremely personal and sensitive data, such as a medical facility's patient records or a bank that needs to secure financial data. The type of deployment and actions of the service requesting users are not important to the NMS, except to the degree that the NMS must ensure that the system has the features, hardware, and security to match operational needs.

#### 4.4.2.2 Telecom network

Telecom networks are modlled by division into northbound and southbound abstraction levels or descriptors, where southbound describes traffic from the NMS and hardware controlled by the network. Northbound traffice comes from lower layers of the network such as routers and switches and from the applications and users. Services supporting and the telecom network, both internal and third party, are described has being eastbound or westbound, depending on the objectives of the modelled architecture. In the above figure, SIEM is an example service that is adjacent to the NMS, and is often used in modern deployments.

In telecom deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares it's own certificate authority (CA) or authorities deployed to the managed machines within the network. The number of these managed machines, number of CA's and how the CA's are used is dependent on design of the network Alternatively, even at telecom scale, and NMS can even provide its own certifactes and form an independent and segregated trust ring.

In telecom deployments of NMS it is common to provide an in-house Public Key Infrastructure (PKI), that declares it's own certificate authority (CA) or authorities deployed to the managed machines within the network. The number of these managed machines, number of CA's, and how the CA's are used is dependent on design of the network. Alternatively, even at telecom scale, and NMS can even provide its own certificates and form an independent and segregated trust domain.

#### 4.4.3 Alternative deployments

As the use of extremely large scale network services, or hyperscalers, becomes increasingly popular and the networked services perform an ever greater number of software functions, how we understand network structures depends on how we model their connectivity. The following two use cases in sub chapters consider such deployment and other complex deployments primarily by focusing two approaches. These complex networks can be modeled by how the functions are virtualised in the network [4.4.3.1 Logical network deployment](#4431-logical-network-deployment) or examining how much RDPS is involved in the design [4.4.3.2 Physical network deployment with RDPS](#4432-physical-network-deployment-with-rdps).

Yet, the protocols used for all network deployments remain consistent. TCP and UDP dominate the network and trasport layers in the OSI-model. DNS root servers are still trusted to point to the desired IP address and browser maintained TLS CA pools builds trust beyond that provided by the DNS.

Encryption can be applied to the transport layer, but is rarely seen as it imposes increased computational requirements, higher cost, and more complex management. Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout a private intranet. Only in networks that need greater intergrity assurance, does the network need to be responsible for encrypting its own traffic.

#### 4.4.3.1 Logical network deployment

Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts. Such SDNs needed an IP subnetwork definition to provide IP addresses with a DHCP from a switch.

The Virtual Machines uses Virtual Ethernet interface (veth) to transfer information in the same way that other networks would with a physical card. The veth is connected to virtual switch, that handles ARP protocol duties, and relies the DHCP queries to the control layer.

The subnet virtual switch is connected to a virtual router acting as a gateway, enabling the virtual machine to communicate with rest of the connected infrastructure.

All of these virtual devices can be independent instances of virtual machines running OS with a linux kernel.

The virtual imitation of real world devices copies over the same design flaws that we have had for years.

Only after a few iterations of cluster based application development in scale, the network requirements have started to evolve.

The paradigm shift happens, when the application design takes more responsibility from the High-Availability and the application is already expecting faults to happen.

In a fluid, often container based, environment where computational nodes can be dropped unannounced, the application excution context vanishes without warning.

It is often expected, when cluster changes are made, the application can resume it's task only with minimal overhead and loss of progress whe it is relaunched elsewhere.

This elsewhere can be a new node added into the pool, or the old one when it rejoines the cluster after a forced reboot.

When the application changes, the network changes with it, thanks to the flexibility of SDN.

The latest network control structures are utilising low level kernel features.

While the Berkeley Packet Filter has been the stable base for linux Netfilter stack, the extended version of it(eBPF) moves the computational decission making to the kernel.

While the previous OS user level tools are now rendered useless, and the packet routing decision is done before the packet is introduced to the host OS, the eBPF implementations are often built for the cluster use.

Decission, what was previously segregated to different OSI-model layers, is now solved in a single process.

Combining eBPF and cluster application knowledge and control, the cluster becomes the NMS.

The application desribes it's needs as how much distribution it requires, what parts of the different processes can be in the same or different computational context, and even how much capasity it expects from the backend.

The eBPF can provide answer to all of the requests by partially resolving the Session layer and fully implementing the control of Transport-, Network-, Data link- and Physical-layers.

In highly interconnected cluster, where multiple sites are used to host the workloads, this means, that the virtual or physical port definition is made available only in the machine where the corresponding workload is located to.

In an optimal case, there is no need for additional firewall configuration, as the node does not simply accept traffic in for the services it is not hosting.

In reality, multiple layers of firewalling is still used to limit accidental configurations exposing services undesireably.

In theory, the database can be in Portugal, when the business logic is driven in Singaporean datacenter.

These two services are often placed into a single namespace, that often translates direclty to a IP subnet that stays fixed within the cluster.

This subnet is used in the application internal routing and communication, and does not nessearily mind where it is implemented.

The namespace and IP subnet follows seamlesly to the new datacenter location, if the application failover tolerates it and the cluster design makes it possible.

This highly abstract and fluid control scheme can host emergency services critical information, nations polling results or a non-profit organisations read-only website.

Only the implementing entitys risk apetite sets the upper limit on what this structure can be used for.

#### 4.4.3.2 Physical network deployment with RDPS

When almost everything can be software, the minimum sill remains: the user needs to have some form of User Equipment to be able to connect.

This Network Interface can be a radio in the cellphone, a WiFi Access Point in the living room, or router with SFP+ ports serving the local datacenter.

How much the network strcutrue has autonomy on control and local network routing the device has can be modeled in function of how much RDPS is involved in the design.

![Figure 4.4.3.2-1: Maximum RDPS involvement](./media/2026-04-14_rdps_max.drawio.png)

**Figure 4.4.3.2-1: Maximum RDPS involvement**

In figure the maximum RDPS involvement, the network design follows the hot potato design rule.

The connection is handed over for RDPS as soon as possible.

The local network is used as little as possible, and even the home office routing can take a detour through RDPS in order to provide auditable trail of how the remote working employee is using the network.

With technologies like 5G slicing, the closest point of return in respect to re-routing back to your network could be the nearest basestation or it could be the squid proxy in other side of the world.

These two scenarios results to different user experience where the latter would most likely show as slow and unresponsive service, but both are valid designs that can be deployed.

![Figure 4.4.3.2-2: Medium RDPS involvement](./media/2026-04-14_rdps_mid.drawio.png)

**Figure 4.4.3.2-2: Medium RDPS involvement**

Medium RDPS involvement is a common hybrid setup, where the company alrady has older assets, that are grown into the enterprise, and are kept around as there is little or no need to change the infrastructure.

Part of the network design is created with virtual assets, that could be the new IT infrastructure for the latest accuired comapany, while the still significant portion of networking assets are tied to the headquarters datacenter.

Control strucures are different, device management strategies are varying, and even the physicality can extend to multiple nations.

The balance of owned assets and bought services is often selected due to ease of deployment, while the partial reliance on headquarters datacenter offers resilience towards major outages in the connectivity.

End result might not be optimal, but often acceptable in the eyes of company risk management.

![Figure 4.4.3.2-3: Minimal RDPS involvement](./media/2026-04-14_rdps_min.drawio.png)

**Figure 4.4.3.2-3: Minimal RDPS involvement**

In a minimal RDPS involvement, all of the relevant infrastructure is not fulfilling the RDPS definition, and can be deployed to an underground infrastructure spannign multiple locations for example.

Interconnection between the sites is either owned, or leased from a provider.

Some links can be through dedicated IP/MPLS tunnels, while some could be implemented through public connectivity with VPN tunnels. The RDPS mainly serves only update packages to the NMS, validates licensing if needed and can collect usage statistics for product development purposes.

While system updates are critical for the product, the installation is fully idenpendent and no functionality is relying on the RDPS connectivity. The system updates can be delivered with a removable medium, if no connectivity to software repositories is available.

## 4.5 Risk Factors

<mark>TODO: define usage of machine credentials better, consider the cli over ssh controlled scenario</mark>

<mark>TODO: evaluate if a large enterprise needs to have 3rd. party IdP as an integrateable option</mark>

### 5.2.7 Remote Data Processing Systems

<mark>AMS: August and Daniel are working on this. Skip for now.</mark>