Configuration Guide for Cisco NCS 1014, IOS XR Releases 26.x.x

PDF

OTNSec encryption key features

Updated: June 18, 2026

Want to summarize with AI?

Log in

This section explains the key features of OTNSec encryption on the NCS 1014 platform.

The OTNSec encryption feature in the NCS 1014 platform includes these key characteristics:

  • Layer 1 security: Encryption is applied at the OTN layer 1 level, specifically targeting the OPU client payload.

  • Encryption algorithm: The system uses the Galois-Counter-Mode (GCM) AES 256-bit cipher as the default method for encrypting and decrypting OPU payloads.

  • Independent encrypted channels: Each client operates with a separate encrypted channel for both transmission and reception.

  • Programmable key registers: Two banks of 256-bit programmable key registers are available:

    • Current key: Used for ongoing encryption.

    • Future key: Allows for seamless key updates via software without disrupting traffic.

    Each key is associated with an Association Number (AN[1:0]), supporting up to four distinct numbers.

  • Interhost key exchange: Key exchange between hosts is supported through communication over the GCC .

  • Headless mode support: The encryption functionality remains operational even in headless mode.However, headless mode support is timebound and depends on the rekey interval.The maximum supported duration in headless mode is 14 days.

Key concepts in OTNSec encryption and key management

These are the key concepts involved in the OTNSec encryption:

Key generation and function

The OTNSec control plane generates two different keys, one for the transmit (Tx) side and the other for the receive (Rx) side. These keys are used by the line card to program the encryptor and decryptor blocks. These blocks encrypt and decrypt the data packets between the trunk ports of the two nodes.

Key lifetime and rekeying

For security purposes, the keys have a lifetime. A key's lifetime specifies the time the key expires. The "time to expire" (SA lifetime) refers to the period during which a negotiated IKE SA remains valid. The key lifetime for the child SAs can be configured using the sak-rekey-interval which ranges from 30 seconds to 14 days. For example, if the sak-rekey-interval is configured for five minutes, a new key is generated by the OTNSec layer every five minutes. In the absence of a lifetime configuration, the default lifetime is 14.18 days. When the key reaches the maximum lifetime, it becomes invalid, and the CRYPTO-KEY-EXPIRED alarm is raised.

Volume-based rekeying

Volume-based rekeying is supported; the "time to rekey" is the interval before the SA expires, indicating when a new IKE SA must be established to ensure the connection continues without interruption.

it prevents the key from reaching the maximum lifetime. This allows the OTNSec layer to generate a new key when 70% of the lifetime ( approximately11 days) of the current key is over.

Key rollover and indexing

When the lifetime of the first key expires, it automatically rolls over to the next key. To achieve a hitless rollover, the lifetimes of the keys need to be overlapped so that for a certain period of time both keys are active. To maintain this seamless switchover, a key index table is maintained. Each key pair (Tx and Rx) is associated with an Association Number (AN). The index table allows up to four numbers (0, 1, 2, and 3).

Key association and alarms

When the keys are installed, the Rx AN number of node A must match the Tx AN number of node B. Also, the Tx AN number of node A must match the Rx AN number of node B. If there is a mismatch of the AN number between the peer nodes, the CRYPTO-INDEX-MISMATCH alarm is raised.