Commit d0a338ef authored by Santeri Toikka's avatar Santeri Toikka
Browse files

Added a section about RFC 1122 implementation

parent 32212a9b
Loading
Loading
Loading
Loading
+15 −2
Original line number Diff line number Diff line
@@ -398,9 +398,21 @@ Following list of essential functions keep the NMS self-secure and correct funct

The technical requirements of the present document apply under the environmental profile for operation of the product in accordance with its intended use.

### 4.8.x Applying encryption in OSI-model
### 4.8.x Applying encryption in RFC 1122

>This section should also have the OSI-model and TCP/IP model opened as a reference. Crypto doesn't fit everywhere.
![Figure 4.8.x-1: OSI-model and RFC 1122](./media/ops_env_OSI_model.drawio.png)

The Service Requesting Users are often identified from the ability to communicate with the managed device in the link layer.
Fixed access network protocols operating in lower levels of the networking stack do not often have encryption available.
The subscriber line traffic is forwarded as-is without modifying the content or wrapping the traffic into layers of encryption.

If the managed device is a router, it can be often configured to send and receive traffic from a configured Virtual Private Network.
Addressing the VPN security is outside of this document.

In the Radio Access Networking (RAN) the protocol family in use, like IEEE 802, defines what protocols are available and what chipher suites can be used to protect the traffic.
Through out the multiple possible links in the RAN backhaul, it is possible that the traffic traverses unencrypted.
For example, routing a remote site traffic through satelites can end up in a situation, where trunk traffic is broadcasted to the ground station and near areas of it.
Therefore 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.8.x System isolation

@@ -495,6 +507,7 @@ The following non-technical requirements shall be implemented by all products wi
-   **[REQ-GEN-1]:** The product shall have technical documentation a detailed enough systems architecture design description, that enables national bodies like MSA to evaluate and test the product design.
-   **[REQ-GEN-2]:** The product dependencies to Operating System essential security capabilities are documented.
-   **[REQ-GEN-3]:** The manufacturers technical documentation shall describe the external services and systems that are required for the product operation like mentioned in [4.10.1 External security functions, not in scope of the present document].
-   **[REQ-GEN-4]:** Traffic related to the product operation, inlucding but not limited to configuration, metrics and API access, is addressed as Application level traffic in the technical documentation as per RFC 1122.

System operation is always an interplay of multiple components. Modern software design can rarely ignore impact of the changes to other components.

+16 KiB
Loading image diff...