Skip to main content

7. Security Considerations

7. Security Considerations​

The YANG modules specified in this document define schema for data that is designed to be accessed via network management protocols such as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer is the secure transport layer, and the mandatory-to-implement secure transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer is HTTPS, and the mandatory-to-implement secure transport is TLS [RFC8446].

The Network Configuration Access Control Model (NACM) [RFC8341] provides the means to restrict access for particular NETCONF or RESTCONF users to a preconfigured subset of all available NETCONF or RESTCONF protocol operations and content.

There are a number of data nodes defined in these YANG modules that are writable/creatable/deletable (i.e., config true, which is the default). These data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. These are the subtrees and data nodes and their sensitivity/vulnerability:

  • /subservices/subservice : By modifying this subtree, one can modify the structure of the assurance graph, which could alter the status of the services reported by the assurance framework. On one hand, modifications can cause the assurance system to report a service as broken when it is actually healthy (false positive), resulting in engineers or automation software losing time and potentially causing real issues by doing unnecessary modifications on the network. On the other hand, modifications could prevent the assurance system from reporting actual issues (false negative), resulting in failures that could have been avoided. Depending on the service, the impact of these avoidable failures could be Service-Level Agreement (SLA) violations fees or disruption of emergency calls.

Some readable data nodes in these YANG modules may be considered sensitive or vulnerable in some network environments. It is thus important to control read access (e.g., via get, get-config, or notification) to these data nodes. These are the subtrees and data nodes and their sensitivity/vulnerability:

  • /subservices/subservice

  • /agents/agent

  • /assured-services/assured-service

Each of these subtrees contains information about services, subservices, or possible symptoms raised by the agents. The information contained in this subtree might give information about the underlying network as well as services deployed for the customers. For instance, a customer might be given access to monitor their services status (e.g., via model-driven telemetry). In that example, the customer access should be restricted to nodes representing their services so as not to divulge information about the underlying network structure or others customers services.

Last updated on