Network and mediation

Network separation

Nokia recommends configuring multiple NSP network interfaces to segregate different types of NSP traffic. You can segregate NSP client, mediation, and internal traffic by configuring the NSP to use interfaces in separate networks for each traffic type.

The multi-interface implementation isolates different traffic types to one or more of the following networks:

• client—for GUI, OSS, REST, and browser clients, and clients such as Kafka subscribers

• mediation—for direct communication with managed NEs

• internal—for communication such as the following:

  • traffic within an NSP cluster

  • communication with NSP components and other systems for example, the VSR-NRC, NFM-P, and NSP auxiliary databases

  • traffic related to NSP DR functions such as data replication and keep-alive messaging between data centers

Using separate networks allows for additional security policies. For example, the NSP PostgreSQL service is an internal service with NSP components as the only legitimate clients; northbound browser or API clients are not applicable to this service. To help secure the PostgreSQL service from unintended access, you could apply a firewall rule to block the PostgreSQL port on the northbound client interface.

To accommodate a deployment environment that hosts only one network, the use of multiple NSP network interfaces is optional. When the NSP uses only one network for all communication, the NSP client traffic shares the same network as the NE management traffic and the communication between NSP components. This type of configuration can pose a considerable security risk.

Firewall configuration

An NSP deployment has no ingress or egress requirement for access to the public Internet; each NSP host must be isolated using a properly configured firewall.

The NSP supports firewall deployment on all NSP host interfaces, however, firewall support among system components may vary. Components such as the NFM-P or WS-NOC that have multiple system elements may have additional firewall requirements. See the NSP Planning Guide and any specific component planning documentation, as required, for firewall port requirements and restrictions.

Note: Firewall deployment between the members of an NSP cluster is not supported.

Mediation

The following is a summary of recommendations for mediation security:

• Enable secure transport protocols with CLI, NETCONF, and gRPC mediation. Similarly, use SCP or SFTP instead of clear file transfer equivalents such as TFTP and FTP.

• SNMPv3 supports authentication and encryption and is recommended for security reasons over SNMPv1/v2. SNMPv1/v2 provides no confidentiality and must be avoided.

• The mandatory RHEL chronyd service ensures that timestamps of logged activity are synchronized with other network elements. This is especially useful for precisely identifying timelines when troubleshooting an event or issue.

• Segregate the traffic between the NSP and managed NEs in a separate network.

SSH

The NSP supports strong SSH cryptographic algorithms by default, The default algorithms are updated as required to account for changes in the security level of specific algorithms.

SNMP

When SNMP mediation is required, SNMPv3, which supports authentication and encryption, is strongly recommended over SNMPv1/v2.

The SNMP recommendations are:

• Configure SNMPv3 to use both authentication and privacy protocols. This enables authentication and encryption features. and enhances overall network security.

• Ensure that administrative credentials are properly configured with different passwords for authentication and encryption.

Lawful Intercept and data privacy

An NSP system that includes classic management can act as an optional remote controller for Lawful Intercept (LI) functions on SNMP devices that have native LI support. LI is a highly secure function that is built into the device hardware; the NSP LI capabilities are limited to LI target specification, and enabling or disabling LI on a target.

As a remote controller, the NSP has no visibility of intercepted traffic; see “Lawful Intercept concepts” in the NSP NFM-P Classic Management User Guide for more information.

gRPC

When gRPC mediation is required, the NSP gRPC client can be configured to use two-way TLS to protect communication between NSP and the NEs; see the NSP System Administrator Guide for configuration information.

The gPRC recommendations are:

• Ensure that the "Secure" attribute slider is enabled when the gRPC mediation policy is created.

• Enable TLS communication between MDM and managed NEs by importing the NEs self-signed TLS certificate into each MDM truststore. The NE certificate files must be transferred to the NSP over a secure connection.

NETCONF or CLI

When NETCONF or CLI mediation is required, Telnet or SSH may be used as the transport protocol.

The NETCONF an d CLI recommendations are:

• Telnet is unsecure and must be avoided. Enable SSH2 transport protocol when the NETCONF or CLI mediation policy is created.

VSR-NRC communication to the network

See the following documentation references for information about VSR-NRC communication to the network.

IP Routing Protocols

See “Unicast routing and MPLS” in the VSR-NRC Security Best Practices and Hardening Guide.

PCEP

See “PCEP over TLS” in the Segment Routing and PCE User Guide.