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 application 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, and other northbound clients (such as browser-based applications, REST clients, and Kafka subscribers)
mediation—for direct communication with managed NEs
internal—for communication such as the following:
- application traffic within an NSP cluster
- communication with other NSP components or systems such as the VSR-NRC, NFM-P, and NSP analytics servers
- traffic related to NSP DR functions such as data replication and keepalive 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 application communication between NSP components. This type of configuration can pose a considerable security risk.

Firewall configuration

NSP/NFM-P systems have absolutely no ingress or egress requirements for access to the public Internet. Hosts must be isolated with 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.
Use the RHEL chronyd service to ensure 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 traffic between NSP/NFM-P and NEs onto a separate management 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 administrative credentials are properly configured with different passwords for authentication and encryption.

gPRC

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/CLI

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

The NETCONF/CLI recommendations are:

Telnet is insecure and must be avoided. Enable SSH2 transport protocol when the NETCONF and/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 (OSPF, ISIS, BGP)

Refer to the Security Best Practices and Hardening Guide for the VSR, section “Unicast routing and MPLS”.

PCEP

Refer to the Segment Routing and PCE User Guide, section “PCEP over TLS”.

Use subject to agreed restrictions on disclosure and use.