Configuration Guide for Cisco NCS 1004, IOS XR Release 25.x.x

PDF

Configuration Guide for Cisco NCS 1004, IOS XR Release 25.x.x

OTNSec encryption mechanisms in Cisco NCS 1004

Updated: July 31, 2026

Want to summarize with AI?

Log in

Explains how Cisco NCS 1004 uses AES256-based OTNSec encryption to protect 100GE client traffic, and covers prerequisites, IKEv2 protocol, certificate-based authentication, FIPS compliance, configuration tasks, verification, and troubleshooting.

A Cisco NCS 1004 OTNSec encryption mechanism is a data security solution that

  • uses AES256-based OTNSec encryption to secure 100GE and OTU4 client traffic,

  • negotiates secure sessions and device authentication through the IKEv2 protocol and certificate-based authentication, and

  • enables flexible configuration for multiple controller modes and includes features for verification and troubleshooting.

Encryption is supported on the 1.2T and 1.2TL cards.

From Release 7.8.1, layer 1 encryption is supported on the OTN-XP card. For OTN-XP card, different LC modes have different client-side controllers. Hence, encryption has to be enabled under the common ODUCn controller. In release 7.8.1, the OTNSec encryption is enabled under the ODUC4 controller for the following modes with a trunk rate of 400G and with CFP2 DCO Greylock 2 pluggable:

  • 4x100G-MXP of 4x100G-MX-400G-TXP LC mode

  • FC-MXP mode

From Release 7.91, in addition to 10G client support, the 40x10G-4x100G-MXP LC Mode in OTN-XP cards enables encryption on ODUC1, ODUC2, ODUC3, and ODUC4 controllers for trunk rates from 100G to 400G.

This encryption provides more flexibility across different LC modes and datapaths of the OTN-XP card.

OTNSec encryption uses the IKEv2 protocol to negotiate and establish the IKEv2 and OTNSec Security Associations (SA). IKEv2 is used for authentication of the devices in an encryption session, and the protocol provides pre-shared keys (PSK) or RSA certificate-based authentication. The IKEv2 datagrams are carried as payloads using the point-to-point protocol (PPP) over the GCC channel.

To implement this, an IKE session is established between the two endpoints, Site A and Site B, for overhead control plane communication between the two data centers. Data is then encrypted at Site A using OTNSec encryption and decrypted at Site B.

The recommended deployment is to have a single IKEv2 session running over a GCC2 channel per trunk port which creates the child SAs for each of the OTNSec controllers that are configured on the trunk port.

High-speed encryption requirement:

While most focus is on protecting data within data centers, connecting network infrastructure is equally vulnerable to attacks. As more sensitive information travels across fiber-optic networks, cybercriminals increasingly target in-transit data. For cloud operators, encrypting data leaving data centers is vital. Optical encryption secures all communication over the fiber link, making intercepted data unreadable. Protecting data at line rates is an essential requirement for modern data centers.

OTNSec site-to-site operation:

In a site-to-site OTNSec configuration, an IKE session is established between two sites to negotiate encryption parameters and Security Associations. All client data is encrypted at one site and decrypted at the other. Recommended deployment is a single IKEv2 session over a GCC2 channel per trunk port, generating child SAs for each OTNSec controller.

Figure 1. OTNSec site-to-site example and components

Layer 1 encryption prerequisites

Before you configure Layer 1 encryption, ensure the following prerequisites are met:

  • Ensure that the required k9sec.rpm package is installed.

  • Configure the line card in the muxponder or muxponder slice mode using the following commands:

    • 1.2T card:

      • muxponder mode:

        hw-module location location mxponder client-rate 100GE | OTU4

        hw-module location location mxponder trunk-rate {100G | 200G | 300G | 400G | 500G | 600G }

      • muxponder slice mode:

        hw-module location location mxponder-slice mxponder-slice-number client-rate 100GE | OTU4

        hw-module location location mxponder-slice trunk-rate {100G | 200G | 300G | 400G | 500G | 600G }

    • 1.2TL card:

      • muxponder mode:

        hw-module location location mxponder client-rate 100GE | OTU4

        hw-module location location mxponder trunk-rate {200G | 300G | 400G }

      • muxponder slice mode:

        hw-module location location mxponder-slice mxponder-slice-number client-rate 100GE | OTU4

        hw-module location location mxponder-slice trunk-rate {200G | 300G | 400G }

    • OTN-XP card:

      muxponder mode:

      hw-module location location mxponder-slice mxponder-slice-number trunk-rate 400G client-port-rate client-port-number lane lane-number client-type {10GE | 100GE | OTU2 | OTU2e | 400GE | FC16 | FC32 }

Layer 1 encryption limitations

Layer 1 encryption deployments are subject to the following limitations:

  • Traffic is disrupted for a few seconds if the RP fails or GCC2 control plane goes down during key rollover.

  • The sak-rekey-interval must be configured identically on both initiator and responder nodes to ensure proper operation.

IKEv2 protocol

A IKEv2 protocol is an encryption protocol that

  • establishes mutual authentication between peers,

  • negotiates and manages security associations (SAs) through request and response message exchanges, and

  • incorporates reliability, error handling, and peer detection mechanisms to ensure secure communication.

IKEv2 exchanges:

IKEv2 communication consists of pairs of messages called exchanges. The initial exchanges that establish a security association (SA) are the IKE_SA_INIT exchange and the IKE_AUTH exchange. Subsequent exchanges can be either CREATE_CHILD_SA or INFORMATIONAL exchanges.

Figure 2. IKEv2 exchanges

Reliability and security features:

  • Sequence numbers and acknowledgments provide reliability for message delivery.

  • IKEv2 requires error-processing logistics and shared state management (windowing).

  • The protocol delays processing requests until the requester is determined, helping to mitigate denial-of-service (DoS) attacks.

  • Dead Peer Detection (DPD) enables periodic confirmation of peer availability. When no response is received from the peer, the system attempts to reestablish the session automatically.

IKEv2 constructs

IKEv2 is defined in RFC 7296 and consists of the following constructs:

  • Keyring: A keyring is a repository of symmetric and asymmetric pre-shared keys that is configured for a peer and identified using the IP address of the peer. The keyring is associated with an IKEv2 profile and therefore, caters to a set of peers that match the IKEv2 profile. This is a required configuration for the pre-shared keys authentication method that is used for NCS 1004.

    Note

    The certificate-based authentication that uses RSA signatures can be used instead of the keyring. If both methods of authentication are configured, the certificate-based authentication takes precedence. For details about IKEv2 certificate-based authentication, see IKEv2 certificate-based authentication methods.

  • IKEv2 profile: An IKEv2 profile is a repository of nonnegotiable parameters of the IKE SA, such as authentication method and services that are available to the authenticated peers that match the profile. The profile match lookup is done based on the IP address of the remote identity. For security purposes, the IKE SAs have a lifetime that is defined in the IKEv2 profile. The lifetime range, in seconds, is from 120 to 86400. The SAs are rekeyed proactively before the expiry of the lifetime. The default lifetime is 86400. An IKEv2 profile must be attached to an OTNSec configuration on the ODU4 controllers or ODUC4 controllers on both the IKEv2 initiator and responder. This is a required configuration.

    Note

    Only one authentication method is supported for the local peer but multiple authentication methods can be configured for the remote peer.

    If both methods of authentication are configured , keyring and certificate trustpoint (see IKEv2 certificate-based authentication methods) in the profile, the remote peer can authenticate itself using either method. authentication remote [pre-shared| rsa-signature] can be used to exclusively control the remote authentication method. Similarly, authentication local [pre-shared | rsa-signature] can be used to exclusively configure local authentication method. If it is not configured, the certificate-based authentication takes precedence.

  • IKEv2 proposal: An IKEv2 proposal is a collection of transforms that are used in the negotiation of IKE SAs as part of the IKE_SA_INIT exchange. The IKE2 proposal must be attached to an IKEv2 policy. This is an optional configuration. The transform types used in the negotiation are as follows:

    • Encryption algorithm

    • Integrity algorithm

    • Pseudo-Random Function (PRF) algorithm

    • Diffie-Hellman (DH) group

    Note

    The IKEv2 proposal must have at least one algorithm of each type. It is possible to specify multiple algorithms for each type; the order in which the algorithms are specified determines the precedence.

  • IKEv2 policy: IKEv2 employs policies that are configured on each peer to negotiate handshakes between the two peers. An IKEv2 policy contains proposals that are used to negotiate the encryption, integrity, PRF algorithms, and DH group in the SA_INIT exchange. An IKEv2 policy is selected based on the local IP address. This is an optional configuration.

    Note

    The default IKEv2 proposal is used with default IKEv2 policy in the absence of any user-defined policy.

OTNSec encryption features

A OTNSec encryption feature is a data security function that

  • provides layer 1 OTN encryption for the OPU client payload using Galois-Counter-Mode (GCM) AES 256-bit cipher,

  • enables independent encrypted channels for each client in both directions, and

  • supports programmable key management, allowing software-based key updates and seamless rollover without traffic interruption.

OTNSec characteristics

  • OTN layer 1 security operates over the OPU client payload.

  • Galois-Counter-Mode (GCM) AES 256-bit is the default cipher used for encrypting and decrypting OPU payloads.

  • Two banks of 256-bit programmable key registers (current key and future key) allow key updates via software without interrupting traffic.

  • Each key is associated with an Association Number (AN), supporting up to four distinct numbers. Interhost key exchange is supported through communication over GCC.

  • Encryption is available in headless mode.

  • The OTNSec control plane generates separate keys for the transmit (Tx) and receive (Rx) sides. These keys are used by the line card to program encryptor and decryptor blocks, securing data packets between trunk ports of two nodes.

  • Each Tx/Rx key pair is associated with an Association Number (AN). Correct operation requires the Rx AN number of node A to match the Tx AN number of node B and vice versa. Any mismatch between AN numbers triggers a CRYPTO-INDEX-MISMATCH alarm.

Key management details

  • Key lifetimes for child Security Associations (SAs) can be configured using the sak-rekey-interval setting, which ranges from 30 seconds to 14 days. If the sak-rekey-interval is set to five minutes, a new key is generated every five minutes. By default, the key lifetime is 14.18 days if not explicitly configured.

  • When a key reaches its maximum lifetime, it becomes invalid and the system raises a CRYPTO-KEY-EXPIRED alarm.

    Volume-based rekeying generates a new key automatically when 70% of the current key's lifetime has passed (approximately 11 days).

  • When the first key’s lifetime expires, the system rolls over to the next key automatically.

  • For a hitless rollover, key lifetimes are overlapped to ensure both keys remain active during the transition.

  • A key index table maintains the active key pairs, allowing up to four Association Numbers (0, 1, 2, and 3).