Nokia strongly recommends configuring multiple NSP network interfaces to segregate different types of NSP traffic. You can segregate NSP client, mediation, and internal traffic by configuring 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. To help secure internal services from unintended access, Nokia strongly recommends applying firewall rules to block ports reserved for internal NSP services from all traffic other than legitimate NSP clients on the internal network. For example, the NSP PostgreSQL database is an internal service between NSP components—northbound browser or API clients have no requirement to access the NSP PostgresSQL database. Implement firewall rules to block the PostgreSQL port from all traffic other than legitimate NSP clients on the internal network to help secure the PostgreSQL database from unintended access.

To accommodate a deployment environment that hosts only one network, the use of multiple NSP network interfaces is optional. When NSP uses only one network for all communication, 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.

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. Calico network policies are the recommended method for controlling traffic to an NSP cluster deployment.

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.

Calico network policies for NSP

The NSP Kubernetes Platform uses Calico network policies to shield the NSP Kubernetes Platform from malicious attack. Calico network policies are created using the calicoctl command line interface, which is available on the master node of the NSP Kubernetes Platform. Due to the fact that the NSP Kubernetes platform is a closed system, Nokia recommends that network policies be configured at the interface level rather than the pod level.

Configuring Calico network policies requires the creation of "host endpoints", resource definitions that identify the IP interfaces of VMs that host Kubernetes nodes, and "global network policies" (GNPs), which define the traffic filtering rules for a host endpoint. Calico resource definitions are configured using YAML files.

Typically, one host endpoint per cluster node and one GNP are created per network interface in the NSP cluster. In a single network interface deployment, only one host endpoint and one GNP need to be defined. In a 3 network interface deployment, a host endpoint and corresponding GNP must be defined for each of the following:

• the client network interface (for client and OSS systems)

• the internal network interface (traffic between NSP systems)

• the mediation network interface (communication to network elements)

See the calicoctl documentation for more information about managing Calico policies.

In the following example use-case for a single interface deployment, the network operator wants to block all traffic coming to port 8566 of the cluster, with the exception of traffic coming from the redundant DR site. To set this configuration, the following steps are performed on both the active and standby clusters.

1. Create a host endpoint for each interface in the cluster. In Calico host endpoint example, a single host endpoint is created.

2. Create a GNP for each interface in the cluster, adding all IP addresses of other clusters to the "notNets" section. See Calico GNP example for a single-interface sample configuration.

3. Apply the host endpoint and GNP. The following commands are an example:

   calicoctl apply -f a1_endpoint.yaml

   calicoctl apply -f a1_gnp.yaml

4. Verify that the policies have been applied by running the following commands:

   calicoctl get gnp -owide

   calicoctl get heps -owide

Calico host endpoint example

a1_endpoint.yaml

apiVersion: projectcalico.org/v3

kind: HostEndpoint

metadata:

 name: node1-intf

 labels:

   interface: enp1s0

spec:

 interfaceName: enp1s0

 node: cluster-a1

where

name is the name of the host endpoint

interface is the interface label

interfaceName is the interface name (will be referenced by the GNP)

node is the node name, taken from "NAME" as shown by the kubectl get nodes -A command

Calico GNP example

a1_gnp.yaml

apiVersion: projectcalico.org/v3

kind: GlobalNetworkPolicy

metadata:

  name: restrict-ssh

spec:

  selector: interface == 'enp1s0' 

  applyOnForward: true

  types:

  - Ingress

  - Egress

  ingress:

  - action: Deny

    protocol: TCP

    source:

      notNets:

        - "fd11:0100:0127:0178:0000:0000:0179:0005/128"

        - "fd11:0100:0127:0178:0000:0000:0179:0003/128"

    destination:

      ports:

      - 8566 

  - action: Allow

    protocol: TCP

  egress:

  - action: Allow

where

selector: interface matches the interface you configured in the HostEndpoint above

notNets specifies the IP addresses from the standby cluster

ports specifies the ports that allow traffic from the IP addresses specified in notNets (in this case, the standby cluster)

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 NSP and managed NEs in a separate network.

SSH

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, 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 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.