@@ -436,7 +436,85 @@ Depending on the design, the local network can have a local controller complimen
When evaluating the product deployment operational environment risks, the network architecture, the product design and the product functionality needs to be understood.
Physicality of the product deployment is adressed later in [4.3 Operational environment](#43-operational-environment).
#### 4.2.1.x Controller design
#### 4.2.1.1 Software Defined Network
Early versions of Software Defined Networking (SDN) imitated the physical network structure by replacing the real-world devices with digital counterparts.
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 mediation duties, and relies the DHCP queries for IP assignment.
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.
This virtual infrastructure has been a digital copy of the physical world.
All of these virtual devices can be independent instances of virtual machines running OS with a linux kernel because over the years, linux kernel modules has grown to support even the niche use-cases.
Only after a few iterations of cluster based application development in scale, the network requirements and how the virtual environment is implemented 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 un-announced, the application execution 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 when it is relaunched elsewhere.
This elsewhere can be a new node added into the pool, or the old one rejoining to the cluster after a forced reboot.
With this robust foundation, where application state can be preserved over interruptions, where the state can be shared between atomical execution instances, containers, and these instances can write changes back to the state, protocol like DHCP is not needed anymore.
The container does not nesessarily request an IP for the OS running as the container, but is launched with preconfigured veth-interface where the connectivity is already available.
##### Application in a SDN
These application network design parameters are in form of a configuration, and are presented as a request towards the runtime environment.
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.
When the application changes, the configuration request changes, and the network changes with it.
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.
Decission, what was previously segregated to different OSI-model or TCP/IP-stack layers, is now solved in a single process.
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 can mean, that the virtual or physical port definition is made available only in the machine where the corresponding workload is located at.
The implementation vary.
Some accept all node facing traffic to all workloads that have requested outside connectivity routing the traffic through own backend, while some perform a hot-potato routing directing the incoming connection directly to the machine that has the corresponding workload.
In an optimal case, there is no need for additional firewall configuration, as the node does not accept traffic in for the services it is not hosting.
This might be difficult to enforce if the cluster network controller is not the only one changing the routing table and the node configuration.
In reality, multiple layers of firewalling is still used to limit accidental configurations exposing services undesireably.
One in the outer perimeter of the infrastructure provider, one in the OS level accepting maintenance traffic to SSH server, one in the cluster level implementing the dynamic control.
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 the application does not know how the subnet 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.2.1.x Pocket deployment
A pocket deployment is a special combination of design criteria, where the product serves single product user and the interconnectivity of the network is minimal.
Connected network requires always at least one upstream gateway where to send packets to.
Without that at least one upstream connection in the network, it is an air-gabbed network.
The managed device functionality does not degrade, if the connectivity to the centralised command is lost.
The device is placed in a network, that is independent and self sufficient.
The local network devices using the connectivity are not affected by outages and the product's role is more like a convinience for the product user, rather than operational nessecity.
The local network does not expect to be connected to other similar remote sites.
It's inter-connectivy requirements are low.
The network user might have VPN services enabled, but expectation is to be connected only to the isolated environment of own home for example.
When a single device is compromised, the exposure is limited to the devices in that same network.
#### 4.2.1.x Devices using provided connectivity
Relying on provided connectivity is more common for devices that are part of some [ecosystem](#413-ecosystem-management) where the main function of the device is not to serve Service Requesting Users with connectivity, but to provide the user higher level application features.
The product control therefore does not extent to the surrounding network.
Part of the initialisation of the device is to configure local network access for example when wireless access is used.
2. Commercial system monitors (fridge temperature)
3. Entertainment devices (streaming devices, game consoles)
#### 4.2.2 Controller design
The product is a network controller.
The different user roles are defined later in [4.5 Users](#45-users).
@@ -464,36 +542,7 @@ All of the following affects the risk likeliness and impact:
* Is the managed device control complete or partial?
* What is the role of services that are [implemented as RDPS](#) and therefore partially external to this document?
#### 4.2.1.x Devices using provided connectivity
Relying on provided connectivity is more common for devices that are part of some [ecosystem](#413-ecosystem-management) where the main function of the device is not to serve Service Requesting Users with connectivity, but to provide the user higher level application features.
The product control therefore does not extent to the surrounding network.
Part of the initialisation of the device is to configure local network access for example when wireless access is used.
2. Commercial system monitors (fridge temperature)
3. Entertainment devices (streaming devices, game consoles)
#### 4.2.1.x Pocket deployment
A pocket deployment is a special combination of design criteria, where the product serves single product user and the interconnectivity of the network is minimal.
Connected network requires always at least one upstream gateway where to send packets to.
Without that at least one upstream connection in the network, it is an air-gabbed network.
The managed device functionality does not degrade, if the connectivity to the centralised command is lost.
The device is placed in a network, that is independent and self sufficient.
The local network devices using the connectivity are not affected by outages and the product's role is more like a convinience for the product user, rather than operational nessecity.
The local network does not expect to be connected to other similar remote sites.
It's inter-connectivy requirements are low.
The network user might have VPN services enabled, but expectation is to be connected only to the isolated environment of own home for example.
When a single device is compromised, the exposure is limited to the devices in that same network.
### 4.2.2 Applying encryption in RFC 1122
### 4.2.3 Applying encryption in RFC 1122
@@ -511,7 +560,9 @@ For example, routing a remote site traffic through satelites can end up in a sit
Considering these and similar scenartios, it is next to impossible to verify how the underlying network is configured when the traffic exits the control region of the product. This is noted later in [REQ-GEN-4] under [General requirements](#51-general).
### 4.2.x Identifying privileged subjects
### 4.2.4 Inventory, device and subjects management
#### 4.2.4.1 Identifying privileged subjects
As necessary functions as identification and authorisation are, a NMS can still serve traffic without perfroming an identification routine as long as that traffic is authorised in another way.
For example, residential routers are often configured in a way that physical access to a local port is sufficient to identify a Service Requesting User (SRU).
@@ -520,11 +571,16 @@ Authorisation is provided by proximity and a user with physical access becomes t
This does not mean that every access channel should provide authorisation with physical access.
A managed device can have a configuration port, a management API, a firmware update channel, and even a debugging interface, all of them classified as privileged and requiring complex authorisation depending on the device, and its use.
### 4.2.x Inventory and device management
#### 4.2.4.3 Device management
The connected device design can be very simplistic, where the device relies on the system the push for configurations and even update the device firmware.
In the other end of the spectrum, the device can be designed to operate as autonomous agent that requires little or no input from the NMS to manage its functions to run the workload.
NMS is defined through the need need to manage the device.
The devices themeselves are outside the scope of this document when the device facing API's are not.
How the trust is established in the connected network operative security can be evaluated with the product is core components of this document.
#### 4.2.x.1 Inventory management
#### 4.2.4.2 Inventory management
The a function of a NMS can be to generate, keep, and maintain the inventory of the network.
This inventory holds information about the connectivity, capabilities, and some form of mutual authentication for each networked device.
@@ -536,15 +592,6 @@ Depending on the business logic, and the purpose of the network, the inventory c
Even such a simple list requires that the NMS exercise care when devices are removed from the network.
When a rogue device is identified, it is important to be able to isolate the device, and mitigate the potential impact of its actions.
#### 4.2.x.2 Device management
The connected device design can be very simplistic, where the device relies on the system the push for configurations and even update the device firmware.
In the other end of the spectrum, the device can be designed to operate as autonomous agent that requires little or no input from the NMS to manage its functions to run the workload.
NMS is defined through the need need to manage the device.
The devices themeselves are outside the scope of this document when the device facing API's are not.
How the trust is established in the connected network operative security can be evaluated with the product is core components of this document.
## 4.3 Operational Environment
<mark>Editor’s Note: This clause should describe the conditions under which products of a particular type in the category are used as well as detailing possible systems in which they are integrated, including network context, integration environment, and physical surroundings, including the external conditions affecting RDPS.</mark>
@@ -615,8 +662,6 @@ Therfore the operational environement requirements are redused to a single item
### 4.3.3 Logical/Software environment
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
### 4.3.4 Connectivity aspects
<mark>Leave the choice of the most appropriate header language to the rapporteur for each vertical.</mark>
@@ -837,43 +882,6 @@ Encryption can be applied to the transport layer, but is rarely seen as it impos
#### 4.6.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 un-announced, the application execution 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 when it is relaunched elsewhere.
This elsewhere can be a new node added into the pool, or the old one 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.6.3.2 Physical network deployment with RDPS
@@ -881,6 +889,8 @@ When almost everything can be software, the minimum sill remains: the user needs
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.
Inter-networking architecture with RDPS participating in the routing transforms a physical deployment into a logical deployment in the convergence point, which is the device installed into the site.
