@@ -326,6 +326,65 @@ Telecom networks are modlled by division into northbound and southbound abstract
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.
#### 4.4.3 Alternative deployments
As the rise in popularity to utilise hyperscalers and software defined everything in networking services, how we understand network structures depends on how we model those.
The used protocols largely remains the same.
TCP and UDP dominates 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 pool builds the trust on top of DNS being correct.
Encryption can be applied to transport layer, but is rarely seen due to computational requirements and higher cost and more complex management reasons.
Even with the emerging private networks popularised by the 5G slicing features, the transport layer rarely is fully encrypted throughout the private intranet sold for the service requesting users.
If the application needs assunrance on integrity, it needs to be responsible on encrypting its own traffic.
If somebody elses provided locks and keys are used to protect the house, there can be no certainty who can open up the door.
Complex networks can be implemented and modeled through [how much RDPS](#4431-physical-network-deployment) is involved in the whole design or how everything can be [implemented in software](#4432-logical-network-deployment). These approaches are explained in the following use-cases.
#### 4.4.3.1 Physical network deployment
In fucntion of RDPS.
#### 4.4.3.2 Logical network deployment
Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts.
A SDN needed a IP subnetwork definition in order to hand out IP addresses with a DHCP from a switch.
The Virtual Machines uses Virtual Ethernet interface (veth) to transfer information like it would do 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.5 Risk Factors
To address the risks of an NMS product prior a manufacturer's placing it on the market this standard encourages the manufacturer to threat model and risk profile of the use of the product, including its foreseeable uses, and considering the interplay between:
